Blockers in Bugfix-Releases (Re: [Release Planning 3.6] Samba 3.6.6 on May 31 (was May 24)?)

[Michael Adam]

Hi List / Team,

Jeremy Allison wrote:
> On Wed, May 23, 2012 at 12:10:05PM -0700, Jeremy Allison wrote:
> > 
> > Updates - I've now added the test case for #8910, so it should be easy
> > now for Metze, Michael or Volker to approve (hint hint :-).
> > 
> > I've also added 8953 - winbind can hang as nbt_getdc() has no timeout.
> > 
> > But there's a patch available and Herb (the submitter) has tested it
> > and so I'll get him to approve.
> > 
> > I'll work on reviewing #8373 and #8943 to get all these bugs addressed
> > before release.
> 
> I'd also like to get #8882 in :
> 
> https://bugzilla.samba.org/show_bug.cgi?id=8882
> 
> There's a patch there that just needs review. But this one
> isn't a blocker.

We have been there a couple of times, but we never reached
a proper decision:

I have frequently announced my opinion that there can not be
blocker bugs for bufix releases (i.e. version Samba X.Y.Z with Z > 0).
The only exception for this might be the case of a regression
that was introduced in version X.Z.(Z-1).
(I might be convinced to accept "introduced X.Y.Z' with 0 <= Z' < Z",
 but it might be hard.)
In all other cases we have lived with the bug for some releases
anyways, so why should it be a blocker now?

The background for re-raising the issue is that bugs marked as
blockers for 3.6.6 (e.g., others as well) have managed to move
the release date again and again.

Proposal:

So I am proposing to not accept bugs as blockers for a bugfix
release, with the exception of a bug introduced in the previous
bugfix release. If the bug is not fixed by the proposed release
date then it will get into the next bugfix release afterwards
(or the second next, ...)

Opinions?


Stated differently, the question is:
Do we want to do bugfix releases with proposed dates at all?
Or do we want to make bugfix releases on a set-of-bugs-to-fix
basis rather? I think the current mode needs re-thinking
at least. Two modes seem viable to me:

1. Time based releases:
   We announce a proposed release date, maybe when at least
   one bug has been reported (or fixed.)
   The bugs that have been fixed by the freeze date get in.
   The ones that hav not, go into a later release.
   Possible exception: regression introduced in last
   bugfix release blocks release.

2. Feature based releases:
   We state a deadline for collecting bugs that need
   to be fixed for the next release. At the deadline
   date, this list of bugs effectively blocking the
   release is closed. (a collection for the next release
   will be opened at this date.) Then the release is
   frozen once all bugs in the list are fixed.
   It should be possible to move bugs from the current
   list to the next list if it turns out to be too
   difficult / long running, but generally not possible
   to move bugs into the list.

So basically my proposal above is mode #1.
I personally don't like #2 very much, although it might have its
advantages. But I think it will create too much administrative
overhead.

Currently we are using a rather arbitrary combination of
proposed release dates and free addition of blocker bugs
that keeps us from releasing frequently. I think we need
to improve this situation.

Cheers - Michael


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 206 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20120605/5afdb51f/attachment.pgp>