For the GTK+ stack, we make extensive use of the milestone; typically we have 4 relevant milestones: Next stable release (GTK+-2.4.14) Bugs that *could* be fixed in the stable branch get put here. Next API freeze: (GTK+ 2.6 API freeze) Bugs that require API changes that we'd like to fix in the next release go here. End point of unstable branch: (GTK+-2.6.0) More major bugs requiring extensive code changes that we consider possible to fix in the near term go here. Sometime after that: (Future) Wishlist items, incompatible API changes, non-urgent bugs that take significant changes This system is however dying under the "bump-along" problem. GTK+-2.4.14 has 133 bugs on it. Every time we make a minor release we have to move all those bugs. GTK+-2.6 API Freeze has has 115 bugs on it. Every time we make a major release we have to move all those bugs. GTK+-2.6.0 has 135 bugs on it. Every time we make a major release we have to move all those bugs. While moving all the bugs isn't very hard with "change multiple bugs at once", there are plenty of bugs on the next-stable-release rolling milestone that have been bumped 20-30 times. A lot of spam for the poor bug reporter, and it doesn't look very good for the project. One solution would be to just have fixed milestones for the four categories; say: Stable release API freeze Devel release Future Which solves the bug spam problem. But I don't really like it as a solution because it doesn't really help with release planning. It doesn't tell us what bugs *have* to get fixed for a particular release. It also doesn't give give bug reporters any reasonable expectation for when their bug will be fixed. So, here's my idea - we keep the idea of the 3 "current work" milestones, maybe retitle them a little: 2.4.14 2.5 API Freeze 2.5 Freeze But we get *much* stricter about what goes onto them. A bug goes goes onto a milestone if one of: A) we couldn't ship the milestone without fixing it B) someone has signed up to fix the bug before that milestone All other bugs are assigned to a set of "pool milestones". These are groups of bugs that are intended to help people figure out what bugs they should sign up to fix for a milestone. Pools I'm thinking of: Need diagnosis A reported bug that the maintainers of GTK+ can't commit to fixing because they don't know what is going: there are no reproduction instructions or it occurs on a platform that they don't have acess to. This is different from NEEDINFO because NEEDINFO should mean that the bug is waiting for specific information from the reporter. Small fix A small bug with a diagnosis that needs code written to fix the bug (few minutes to a few hours) Medium fix A reported bug with a diagnosis that needs code written to fix the bug (few hours to a week) Small Feature/API Small Feature/API additions (few minutes to a few hours) Medium Feature/API Big Feature/API additions (few hours to a week) Big Feature/API Big Feature/API additions (1 week to 1 year) I've not included Big Fix above because I'm hoping the set of bugs that take more than a week to fix is very small.... Downsides: - Complex: 12 standard milestones - Even with the 12 milestones, we don't convey all the interesting distinctions. "Medium API" would contain both stuff we really want to do, and "I guess that might be OK" stuff. Same with Med Fix. Priority/Severity could of course be used to sort stuff within each milestone. - These won't look like "milestones" to a bug reporter. What does it mean to the bug reporter when there bug report is milestoned as "Medium Fix" - it doesn't immediately tell them: "This is a real bug, and we understand what is going on, but it's a reasonable amount of work. We'll fix it as soon as someone has a few hours to fix it" - Doesn't really handle the class of bugs "API feature request with a patch, the patch isn't really right, and it's not entirely clear if we want to do this or not." But then again, we really shouldn't leave bugs in that sort sort of indeterminate state. Upsides: - No bump-along bug spam - Clear procedure for figuring out what goes into each release - Clear way of handling release blockers and making sure they get fixed.
Attachment:
signature.asc
Description: This is a digitally signed message part