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

[Michael Adam]

Stefan (metze) Metzmacher wrote:
> Am 18.06.2012 12:23, schrieb Volker Lendecke:
> > 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,
> 
> I fully agree on that:-)
> 
> The important thing is that the next release is better than the current one,
> we don't need to wait until the next release is perfect.

Oops,

I did not notice that the thread already continued while I was
writing my other mail...

The above sums it up very nicely what I have written much (and
possibly unnecessarily :) longer in my other mail.

Full ack on time-based releases. And the mode for security
releases.

Cheers - Michael

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