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

[Michael Adam]

Hi Karo,

Karolin Seeger wrote:
> On Sun, Jun 10, 2012 at 10:39:00AM +0200, Michael Adam wrote:
> > Karolin Seeger wrote:
> > > 
> > > So you guys want to ship bugfix releases with severe known issues?
> > > That might work with more developers working on bugs on a regular basis.
> > > Currently, it does not. There are severe bugs that need to be addressed
> > > before the next bugfix release.
> > 
> > I don't get it. The bugs we are talking about have been there
> > since some time. We have shipped major and/or bugfix releases
> > with them. So how can the bug be suddenly so severe that we
> > should hold back existing fixes for other bugs from our users
> > until the fix for this bug is available, i.e. for an uncertain
> > amount of time?
> 
> Many people hit the issue, so it was kind of approved. Then Jeremy started
> to investigate and it was pretty soon clear that it's really an issue.
> But you could have lower the severity youself. Feel free to do that next
> time. I think this was a bad one and I am glad that it is fixed now.

I don't want to challenge the importance and severity of some
bugs. Actually, every bug can be severe. And I don't think
severity should or can be a lever to block releases: I don't see
any reason why missing fix for a severe bug overrules an existing
fix for another possibly severe bug (or several ones).


Proof of the inconsistence of blockers for bugfix releases (again):
==========================================================

Assume:

* We have an open bug #X, that was already present in the
  previous release.
* We have a fix for at least one different bug #Y.

Then:

* The next release will be more useful than the previous
  release in that it contains the fix for bug #Y,
  so it will help some users.
* The next release will be as bad as the previous one
  with respect to bug #X.
* The next release will _not_ be worse with respect to the
  known open bugs than the previous one, since bug #X
  was already open in the previous release.

Hence:

=> It will be useful/helpful for our users to release without the fix for bug #X.

Furthermore:

* It is not clear that the users will get the fix for bug #X
  if we block the relasese for bug #X.

q.e.d. :-)


(The axiom I use here is that the main purpose of a bugfix
release is to be useful for our users.)


Note that the above even applies to #X if #X is a security issue,
if (and only if) the issue is not public yet or the issue has
not been detected to be security relevant.


Proposal (again): time-based releases:
======================================

I propose that we agree on a time-based schedule for bugfix
releases. E.g. a bugfix release every 4 or 6 weeks
(whatever works for you, maybe even 8 weeks) for the current
stable release branch. Then we have a list of bugs that we
would like to fix for that release (basically any bug open
against the major version). If at freezing time, at least
one bug is fixed, the list ist closed and the release is done
as scheduled no matter which other bugs are still open.

In this mode, the users will get _each_ bugfix in a relase
as soon as possible after it becomes available. And the users
are not deprived of important bugfixes because other bugfixes
are not available yet.

Handling security issues:
=========================

When a security issue is reported non-publically, and a
bugfix release is imminent, (within a couple of days, say),
we should do the bugfix release on schedule and release
the security release afterwards as soon as we have a fix.

If we have a fix for the security issue before the freezing
period for the bugfix release starts, we should release the
security fix before the scheduled release and see whether
the original date for the bugfix release can be kept or
needs to be deferred by some days.

If there is a bug report that is public but there is a suspicion
that it might be security relevant, I have not recipe yet. But I
am inclined to treat it as any other bug until there is proof.


Votes?
Opinions?

Cheers - Michael



> And as I already wrote in my mail to Andrew, the real reason for the last
> delay was the assumed security release.
>  
> > Just the fact that we are now aware of the bug does not change
> > the severity per se. The only exception I can imagine being
> > security issues - here then the situation is different.
> > 
> > But for issues that are not security relevant, shipping without
> > the fix does not render the next release less useful or less secure
> > than the previous one.
> > 
> > IMHO, a non-security issue that is so severe that we can not
> > ship another release with it, must have hit our users so badly
> > that we have noticed in the first release that shipped it.
> 
> That happened. It's known since pre3. But it took a while since it was
> approved and the cause was found. See
> https://bugzilla.samba.org/show_bug.cgi?id=8373 for the history.
> 
> > And this is exactly the exception I described from the start.
> > 
> > I'd really like to understand the thinking, so please elaborate.
> > 
> > > Otherwise, they would never be addressed.
> > > IMHO blockers are needed to create a certain pressure.
> > 
> > I don't think so. This only increases pressure on our users
> > since we deprive them of bugfixes that are already available.
> 
> I am still thinking that there are basic features that must work and can
> cause a delay. But when I am the only one, please just change the severity
> next time and I will ship the release.
>  
> > I just think that we need to close the door for releases:
> > Either by specifying a date for the release and just taking
> > those bugfixes that are available at the time (if there are
> > any) or by maintaining a list of bugs that we want fixed.
> > (These would then legitimately be chosen blockers for the
> > release. But that list should be closed at some point, so
> > no new blockes can be added. In both cases, security issues
> > interrupt the process and can lead to a delay.
> 
> Karo
> 
> -- 
> Samba			http://www.samba.org
> SerNet			http://www.sernet.de
> sambaXP			http://www.sambaxp.org

-------------- 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/20120618/dd83cbde/attachment.pgp>