Re: Getting serious about releasing

[Sander Vesik <Sander Vesik Sun COM>]

On 24 Apr 2002, Luis Villa wrote:

> On Tue, 2002-04-23 at 16:58, Havoc Pennington wrote:
> > 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.)
> 

Why is it easier to remap the numerical ones? the non-numerical ones, at
least if used strictly for release time purposes would just get unset
(well, really, if a shouldfix doesn't become a mustfix it pretty much has
no further purpose). Same for mustfix-es that got punted.

> 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.
> 

I think it is sort of unrelastic to expect to be able to pick bugs for N+1
release at or near release N, at least if these have to make up the
majority of bugs that will need to get fixed by N+1. 

Bugs labeled as 2.0.1 will probably act as a promise "this will get
fixed", which need not be true - it can very easily happen that none of
the 2.0.0 bugs bumped to 2.0.1 ones get fixed within a component, if the
maintainer instead spends all the time fixing security issues and other
high priority issues that cae up in the mean while.

It might be different if we controlled (via extensive hostage-taking or
similar) on what developers worked on in which order, but we don't.

> 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.
> 

	Sander

	I see a dark sail on the horizon
	Set under a dark cloud that hides the sun
	Bring me my Broadsword and clear understanding