Blockers in Bugfix-Releases (Re: [Release Planning 3.6] Samba 3.6.6 on May 31 (was May 24)?)
mat at matws.net
Mon Jun 18 13:13:12 MDT 2012
On 06/18/2012 03:23 AM, Volker Lendecke wrote:
> 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.
I mostly agree on this too, I want to know what is the position on
regressions, in my mind there is 2 kinds of regressions:
* Those that were introduced in a previous release (that we were or
weren't aware of when we did the release)
* Those that are introduced by the changes that we want to bring in the
coming release, I really do think that this case could happen if we have
a development that have a huge gain and a regression with a small impact
(ie. breaking some stuff for os/2 client).
I'd like to know also if this position is for major releases as well.
More information about the samba-technical