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

[Karolin Seeger]

On Mon, Jun 18, 2012 at 12:55:02PM +0200, Stefan (metze) Metzmacher wrote:
> Am 18.06.2012 12:49, schrieb 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?
> 
> Sounds like a good plan!
 
Okay, if that is the consensus, we will ship bugfix releases for each
branch every 6 weeks.

> We should add that we add the known bugs to the release notes,
> that might be also very useful for admins.

I don't think that this is neccessary, because
a) nobody is reading release notes and
b) that is what bugzilla is for.
I have no idea how long the release notes will be if I have to add each
existing bug. But if all of you agree, I will have to.

Karolin

-- 
Samba			http://www.samba.org
SerNet			http://www.sernet.de
sambaXP			http://www.sambaxp.org