openmw.org

Is it possible to change the "new issue" page so a default target version is always set? Preferably to the next version, right now that would be 0.31. The problem is that they don't show up on the roadmap otherwise and are forgotten about.

Someone should also update those on this list and remove those that have been fixed.

An additional suggestion is to add the "bug reporting guidelines" link on the "new issue" page as well.

I don't know if it is possible to set a default target version. I am not opposed to the idea, but I also think it isn't needed very much. Between scrawl and I we manage very well to handle incoming issues. Only a few fall through the cracks and that is mostly obscure stuff.

While we're at suggestions for the bug tracker, why aren't openCS bugs/features on a different project then the main openMW project?

Zini wrote:I don't know if it is possible to set a default target version.

I don't know how the back end looks, but my thought, since there always are going to be a target version, is to just remove the first (empty) option in the <select>. That way, the only possible issues would be when it's near a new release (as now, since there is both a 0.30 and 0.31), but that one is easy to correct since it's always visible, while currently there are 44 that has 'slipped through the cracks'.

@Digmaster Because OpenMW and OpenCS are closely integrated. They even share a significant amount of of code.

@Lazaroth I guess lgro is the person to talk to about this topic.

Hi,
thanks for suggestions! I will add default version to the Redmine (I found some plugin which do exactly what we need) but unfortunately it will take few days, because I'm in the middle of preparation to my wedding.

Hey! Great news, congrats.

Actually, I would like to interject here. I don't think that is a good idea.

A large number of new reports are duplicates or invalid, so removing the target version from those if it was already automatically added is extra work.
Likewise, regressions should not have a target number. If the issue was not present in any released version, then it should not be included in the changelog.

But most importantly: imo milestones should be used to organize development, not to "keep track of issues".
Here's my take on how it should be done (for reference, see also how the Redmine folks are doing it)

- openmw version XYZ milestone: issues are added as soon as someone started to work on it, and wants to ship it in time for the release.
- special "Candidates for next version" milestone (not specific to any version): Issues that contributors can pick from
- Other milestones (versions far off in the future, e.g. currently 1.0 or 1.1)

Doing it this way would also fix the email notification spam that happens whenever Zini tags the release and all the not-done-for-the-current-release issues (>100 typically) get their milestone changed to the next release. Yes, I get > 100 emails whenever this happens.

I don't know what makes you think that issues without a target version would be forgotten about. That's not true. I often browse the All issues list.
There are much better fields for keeping track of important issues, such as Priority.

Valid points, that I agree with. Mostly.

Likewise, regressions should not have a target number. If the issue was not present in any released version, then it should not be included in the changelog.

I usually manage to remove same-release regressions when creating the changelog from the tracker. These regressions should still be tracked somewhere.

- openmw version XYZ milestone: issues are added as soon as someone started to work on it, and wants to ship it in time for the release.
- special "Candidates for next version" milestone (not specific to any version): Issues that contributors can pick from
- Other milestones (versions far off in the future, e.g. currently 1.0 or 1.1)

That is more or less what we did before we changed trackers. To be honest I am not keen any any larger changes. The current system works decently well (despite a few hickups) and I think we have better things to do than to optimise working procedures.

Just a few notes from my pov;

It comes down to this:

scrawl wrote:I don't know what makes you think that issues without a target version would be forgotten about.

Since they don't show up on the roadmap they are very much hidden and therefore often forgotten about. Not by the core development team, but by the people who are reporting bugs and aren't experienced with OpenMW development. I would argue that many duplicates get posted because of this. I've even seen people ask "why can't I see my issue?" or of the sorts. I would also not be surprised if some developers have similar problems.

scrawl wrote:A large number of new reports are duplicates or invalid, so removing the target version from those if it was already automatically added is extra work.
Likewise, regressions should not have a target number. If the issue was not present in any released version, then it should not be included in the changelog.

My suggestion was not to remove the "no target version" option internally, but just hiding it in the "new issue" page. If for some reason a no target is the correct one, it would still be able to be chosen in the list when updating an issue. It's also far less obtrusive change than what you proposed, although I see the appeal.

Regarding extra work; you or Zini usually update 90% of all new issues anyway, so I don't see how this would add any time.