Re: What if "blocker" meant "blocker"?

[Vincent Untz <vuntz gnome org>]

Hi Ryan,

Le vendredi 06 janvier 2006 �3:28 -0500, Ryan Lortie a �it :
> Hello Release Team.
> 
> For next release cycle, I have a simple suggestion to improve the
> release process:
> 
> Don't release software with major bugs in it.
> 
> It might make sense for the next release cycle to have a longer hard
> code freeze (2, maybe even 3 weeks) during which developers are
> encouraged to work on bugs on the blocker list.
> 
> The 'encouragement' would come in the following form:  if there is a
> non-zero number of bugs on the blocker list then GNOME does not release.
> I think under this kind of pressure the few bugs that are on the blocker
> list every cycle would have the attention of the entire project focused
> on them and would be fixed quite rapidly.

So, IMHO, our problem here is that we don't send enough mails nagging
maintainers. We should start sending nag mails at the start of the
feature freeze, really.

Hopefully, the new bugzilla will help with its nice product page.

> So although it might result in delays in the release (every six months
> is nice but does it have to be *exactly* six months?) the delay probably
> would not be very long.  The delay is merely following the natural
> definition of "blocker".

Well, sometimes, a blocker is not easy to fix ;-)

> I think we're so caught up in releasing every six months that we've
> developed the mentality that we dare not deviate from the schedule at
> all (even in the presence of blocker bugs).  This hurts our users who
> are given "stable" versions of GNOME which are known to contain major
> bugs.  When you can go on Bugzilla right now and see "Blocker bugs:
> GNOME 2.12.x (these must be fixed before/in the specified GNOME
> version)" with a list of open bugs under it something is wrong.
> 
> The primary benefits of a regular release schedule are not compromised
> by taking an extra week or two if necessary to make sure we're not
> releasing software with major bugs and I don't think this is a slippery
> precedent.

So, before starting delaying the big release, I'd very much prefer to
try another solution. Releasing the day we said we would release is a
good thing: it's a strong signal we send to people showing that we can
do what we want to do. As I said above, I'd prefer if maintainers look
at blockers before the hard code freeze. We can do it for 2.14: it's not
too late.

Now, we just need a volunteer to send nag mails ;-)

Vincent

-- 
Les gens heureux ne sont pas press�