Re: Getting serious about releasing



On Tue, 2002-04-23 at 16:58, Havoc Pennington wrote:
> So, if you think a bug I listed should really not be punted, either a)
> fix it right away b) suggest a bug that I have as not puntable that
> you'd punt instead or c) have the guts to go ahead and argue for a
> September or later release. Please don't do c). ;-)

I've done (c) in a letter to gnome-hackers; please respond to that if
you're interested.

> Luis I think we really need this reflected in bugzilla; whatever
> criteria we currently have for the must-fix list is too loose. We need
> a way to mark genuine showstoppers. Suggestions?

Whatever the response to my letter to gnome-hackers is, at some point we
need to punt things. I suggest that the solution needs to be (1) global
(2) easy to remember/use and (3) extremely specific.

So... I suggest basically simply having GNOME2.0.0, GNOME2.0.1,
GNOME2.0.2 keywords, etc. They aren't milestones (which I think are the
ideal solution, but are impractical) but they would be pseudo
milestones, and for all intents and purposes be treated just like
milestones. 

These would be (1) trivially global (they don't conflict with anyone
else's milestones or keywords) (2) fairly straightforward and mapping
easily to regular milestones and (3) map very directly to /exact/
milestones, not vagueness like 'shouldfix'/'wontfix' etc., which can be
interpreted to mean any number of things and are hard to precisely
re-map when things get pushed. (If it is 'should fix' but we can't do it
for 2.0.0, how do we then indicate it is should fix for 2.0.1? Hope that
example makes the problem with those style of milestones clear.)

Hope that answers the question- I'm of course open to suggestion and
correction, but I really honestly feel this is the best solution for the
reasons I've laid out.

Luis

P.S. WRT patch->high, those are definitely not showstopper- but I want
them to be 2.0.0 and force developers to at least look at them before
punting. That's /definitely/ up for debate, but I really think we need
to do everything we can to encourage new blood and 'encouraging'
developers to look at patches in this way falls into that category.





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