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

[Andrew Bartlett]

On Fri, 2012-06-15 at 16:03 -0700, Jeremy Allison 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.
> 
> Yeah, I depend on blocker bugs in order to make sure critical
> fixes don't get lost for a release.
> 
> They're essential, and not abused IMHO. If people disagree
> they can (and do) mark them down from blocker.
> 
> This system works well IMHO.

Could you depend instead on 'critical' bugs, which would be described as
'we want this in the next release' without actually blocking it?  

Then we could continue to aim to get these fixed, monitor the list and
generally deal with them promptly, while leaving 'blocker' (and the
associated delay) for regressions since a/the previous point release?

A blocker bug without a fix won't help anyone, while a critical bug with
a fix will easily make the release, without delaying anyone. 

Would this be a reasonable approach?

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org