justdave at bugzilla.org
Thu Nov 10 18:16:23 UTC 2005
The last three or four releases, every time we're preparing to branch, a
whole mess of bugs wind up getting retargeted to the next release
because they don't make the cut to get into the current one. As it
currently stands, we have around 300 bugs that fit this criteria to get
pushed out of the 2.22 release. Quite a few of these bugs have been
getting pushed along every release since the 2.14 days, and the comments
on the bugs show it. This really isn't an idea solution, especially
with enhancement requests.
I'd like to come up with a way to deal with enhancement requests which
avoids targeting them at a specific release until they have an owner
actually working on them that can tell us they think it'll make it by
then... in other words, if it still has the default assignee, it
shouldn't be targeted to a release.
The question, then, is what do we target them to? There's some value to
having something other than --- as a target... to show that we've
actually looked at it and decided it's not a dupe. On the other hand, I
suppose that's what UNCONFIRMED is for. Future is the next best option
that we currently have, but that sounds a lot like "we never plan on
doing this" to most folks.
I'm leaning at this point to just going with --- since we have the
UNCONFIRMED distinction right now. Perhaps go to Future for things that
need architectural changes before they can be implemented? Do we have
someone willing to triage the "Future" stuff periodically and "defuture"
things that required architectural changes that have been made since
they were filed?
Dave Miller http://www.justdave.net/
System Administrator, Mozilla Corporation http://www.mozilla.com/
Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/
More information about the developers