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

[Michael Adam]

Jeremy,

Jeremy Allison wrote:
> On Tue, Jun 05, 2012 at 02:06:49PM +0200, Michael Adam wrote:
> > 
> > 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?
> 
> -1. There are some bugs that are just so nasty I don't
> want to have them even in a x.y.z release.

This argument makes no sense at all to me:

My point is that we did already have that bug in x.y.(z-1),
but not introduced by x.y.(z-1).

So it is too late already for the thing you are trying
to achieve! QED :-)

> We just have to use judgement on them.

The reason for me to bring this up again is that precisely this
judgement has failed again and again in the past, delaying our
releases unnecessarily.


Typically, we have a couple of bugs, and want to release.
Assume all of them are fixed but one. That bug has been there
since a couple of releases.

So the choice is this:

(1) Release as scheduled, containing the fixes for all the bugs
    in the list but that one bug. Keep the bug open for the
    next release.

(2) Delay the release for and uncertain time until that bug
    is fixed.

The first choice will result in a release that will be useful
and better than the previous release in that it will contain
some bug fixes. It will not be worse than the previous release
at least as regards the bug in question.

The second choice will result in no release at all for an
uncertain timeframe. We will deprive our users of the possibly
very important bugfixes that have piled up apart from that
one bug in question. And it is by no means certain that
the users will get a release containing the fix for the bug
in question any earlier than if we had chosen the other path!
But with the other mode, our users will have gotten useful
releases in between.

QED again. ;)


The only situations which imho justify a change in the
release schedule are these two:

1) There are no bugfixes available at all.
   In that case it does of course not makes sense to do a
   release.

2) There is a security bug.
   In that case we do a release with only the security fix
   not containing any of the piled up bug fixes.
   If the security release date is too close to the scheduled
   regular release date, so that it can't be done so soon
   afterwards, we can defer the regular release for some time.


Does this make my point of view more clear?

I think that it is utterly unfair to our users to hold back
useful bugfixes because there is some other severe bug
that popped up. I propose that it should be our rule
to not let bugs defer scheduled releases usually.
There can be always exceptions of a rule. But for this,
the only reasonable exceptions I can imaigne are
security bugs (which we do handle approrialtely already) and
possibly severe regressions introduces in the previous release,
but even for these I would usually not block a release.


Jeremy, as you can tell, I am pretty dermined in this matter,
so you will need to elaborate a little more than just giving
FUD arguments ("there are bugs so nasty...") in order to
convince me... ;-)

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/5cac8148/attachment.pgp>