Retargeting enhancements

[David Miller]

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/