Work out new bug protocol about wesnoth HOT 10 CLOSED

afaik the main reason why made a difference between fixed and closed is that we could have an overwiew of the fixed bugs when the bugs are closed (when the new version is released) so that we don't forget things in the releasenotes/changelog so if github gives us an easy way to get an overview of the bugs fixed since the last release i dont see a reason to keep it.

Also i think we really need labls that indicate which versions are effected (stable or development branch). If we want to keep the 'fixed' lawls it probably makes sense to have seperate 'fixed in stable' and 'fixed in master' labels.

from wesnoth.

That seems like a really good reason to have a "fixed" label, but... it really needs to be enforced then that any issue that's closed is also marked fixed. I wonder if that can work with issue auto-closing...

from wesnoth.

Ok, this is what I propose for a new protocol:

• All new issues are opened with no milestone (easiest since only members can set them).
• When a bug is fixed, immediately close it (either manually or via commit message). If no milestone is set, do nothing, else update the milestone to the next release that will include the fix. Ie, a fix for a long-standing bug in 1.13.7+dev should be marked 1.13.8. When a release happens, we can review all bugs marked with the relevant milestone, if necessary.
• When a bug is fixed, immediately close it (either manually or via commit message), and set its milestone to the next release which will contain the fix. Ie, a fix for a bug committed in the 1.13.7+dev cycle should be marked 1.13.8. When a release happens, we can review all bugs marked with the relevant milestone.
  An exception to the above would be if the bug is known to be a temporary master-only bug, in which case no milestone need be set.
• Any open bugs without milestones when a release happens should be marked with the number of the release. This indicates it's present as of that version. The milestone should not be subsequently updated until the bug is fixed.

Thoughts? Too complicated?

from wesnoth.

• I don't think we should have +dev milestones. Maybe you didn't intend to imply that though.
• I don't really understand your third point. Are you saying open bugs in a release should be put in that release's milestone? That doesn't make any sense.
• I assume this still means we can assign a milestone to say "this is scheduled for X release".

from wesnoth.

• I did not mean we should have +dev milestones. I meant if we fix a bug in 1.13.7+dev we set its milestone to 1.13.8.

• Eh... ya know what, you're right. Let's nix point 3. Then it's simple - any non-fixed bug will have no milestone, and milestones indicate when a bug is fixed. If a reporter needs to report version info they can do it in the report itself.

from wesnoth.

So if this has been decided, it can be put on the wiki and then we can close this.

from wesnoth.

it hasn't realyl beed decided yet, we still haven't deciden how we are goin to difference betwwen bugs that effect master or stable or bugs that are only fixed on master or only on stable.

from wesnoth.

My opinion:

• Bugs fixed only on stable should probably be left open. Maybe we can use the "fixed" label (or a "fixed on stable branch" label) to indicate that they were fixed on stable. I think there shouldn't be many cases where a bug that applies to both stable and master is fixed on stable but not master, though.
• Bugs fixed on stable that don't exist on master should be closed and assigned the stable release containing the fix as their milestone.
• Bugs that exist on both master and stable but are only fixed on master should be labelled "backport", assigned the next dev release as their milestone, and left open until they are backported to stable.
• Bugs that exist only on master can be close and assigned the next dev release when fixed.
• To differentiate between bugs affecting stable vs master, we can apply a special label to those that affect stable.

from wesnoth.

I've added a new "stable" label which can be used for bugs that only affect the stable version. Here's my proposed protocol for dealing with issues in the stable version.

First of all, bugs that affect the stable version should have the "stable" label added as soon as they are submitted.

If it also affects the master version, then add the "backport" label once it is fixed on master, but don't close it. Set the milestone to the dev version that contains the fix. Once it's also fixed on stable, close it and leave the "stable" and "backport" labels on it.

If it doesn't affect the master version, simply close it once fixed and assign it the next stable release as the milestone.

from wesnoth.

I guess this can be marked resolved by now.

from wesnoth.