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

[Andrew Bartlett]

On Tue, 2012-06-05 at 14:06 +0200, Michael Adam wrote:
> Hi List / Team,

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

I strongly agree.  This will help us move to the next release, where the
bug can be fixed.  Important bugs might even speed up the next release. 

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

You have my full support on this important clarification. 

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org