Brainstorming on milestones



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



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]