Blockers in Bugfix-Releases (Re: [Release Planning 3.6] Samba 3.6.6 on May 31 (was May 24)?)
abartlet at samba.org
Thu Jun 7 16:07:06 MDT 2012
On Thu, 2012-06-07 at 21:33 +0200, Karolin Seeger wrote:
> On Tue, Jun 05, 2012 at 11:54:27PM +0200, Björn JACKE wrote:
> > On 2012-06-05 at 14:06 +0200 Michael Adam sent off:
> > > Opinions?
> > +1
> > and thanks for proposing this on the list once more. We will have (at least) 5
> > months between the last ordinary 3.6 release on January 29th and the next
> > bugfix release (June 25th, unless more blocking bugs pop up). That also means
> > we have bugs that have been fixed 5 months ago without pushing them into a
> > release that our users can benefit from. That's suboptimal.
> Yes, that's true, but it's a special situation because of the three
> security releases. Otherwise, there would have been bugfix releases in the
> Security releases, especially when all three branches are affected, are
> very time-consuming!
What can we do to make this less time consuming? I know security
releases are a particular pain, but what about normal releases - is
there anything in that process we could simplify or automate to make
> Additionally, another issue popped up and came across the release
> planning. But you are aware of that. Very unusual cricumstances.
> So you guys want to ship bugfix releases with severe known issues?
> That might work with more developers working on bugs on a regular basis.
> Currently, it does not. There are severe bugs that need to be addressed
> before the next bugfix release. Otherwise, they would never be addressed.
> IMHO blockers are needed to create a certain pressure.
Does it really work like that?
That is, does the threat that the release might be delayed create enough
pressure that issues are actually addressed, or does it just penalise
our other users because not addressing it 'just' means that we keep
If an issue is severe, then it should deserve attention on it's own, and
missing the release entirely is our penalty.
> Of course a release should not be delayed due to minor issues. If that
> ever happened, please let me know.
As per our other discussion, I think we have terrible trouble defining
minor/major. For each of us, particularly after spending days chasing
difficult issue, our particular bug is usually a major issue.
I would much rather use 'regression' as the definition - that is much
easier to pin down.
Andrew Bartlett http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
More information about the samba-technical