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

Volker Lendecke Volker.Lendecke at SerNet.DE
Mon Jun 18 04:23:02 MDT 2012

On Fri, Jun 15, 2012 at 09:03:21PM +0200, Karolin Seeger wrote:
> On Thu, Jun 14, 2012 at 10:06:50AM +1000, Andrew Bartlett wrote:
> > The problem is, for each of us our pet feature is that certain key
> > feature :-).  I still hold that 'regression' is the only standard we can
> > all agree on. 
> I don't agree. I agree that your statement is valid in most cases, but
> there are some key features that must work IMHO. Maybe we need to write down
> these functionalities. Btw, when XP clients cannot be joined, it's a
> regression. 
> I would really like to hear Volker's and Jeremy's point of view regarding
> the regressions. In the past, I had several times the impression that we
> do need blocker bugs (and that the use of them was not abused).
> Maybe you guys would like to comment.

While I haven't read this whole thread in entirety, Michael
has asked me to respond to this mail.

I am a big fan of schedule-based releases. Every x weeks we
ship a new minor release. Period. No exceptions. What is
ready at week x-1 goes in, what is not ready does not. Even
if we ship with known bugs, this is better than not shipping
at all for months. This completely removes the burden to
make a bug a blocker or not. If we ship with known problems
it is not *that* bad because we know we will ship in a
timely fashion later. If a known problem is considered
severe and is fixed significantly before the next scheduled
release, we could consider doing a release in between.

Security releases are different. I would say that we can
ship a release with a known security problem as long as it
is not public yet. When we go public, it is the #1 reason to
do an immediate intermediate release.

Just my 2ct,


SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
phone: +49-551-370000-0, fax: +49-551-370000-9
AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen, mailto:kontakt at

More information about the samba-technical mailing list