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

Andrew Bartlett abartlet at
Tue Jun 19 07:16:19 MDT 2012

On Mon, 2012-06-18 at 12:23 +0200, Volker Lendecke wrote:
> 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.


You express the situation and the need for this solution very well.  

Thank you.


Andrew Bartlett

Andrew Bartlett                      
Authentication Developer, Samba Team 

More information about the samba-technical mailing list