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

[Andrew Bartlett]

On Wed, 2012-06-13 at 20:31 +0200, Karolin Seeger wrote:
> On Sun, Jun 10, 2012 at 10:35:44AM +1000, Andrew Bartlett wrote:
> > I'm not against shipping stable releases, and I am for constantly
> > improving the software we ship.  But for me that means that if a release
> > is an improvement, then we should make it.
> 
> In general I agree, but I think there are certain key features that should
> work.

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. 

> > This is actually a prefect example.  The issue is serious, but by
> > blocking a release waiting for a fix (or confirmation of a fix) for this
> > issue, we have denied users access to a stable release for non-DC
> > environments (or environments with the 'right' length hostnames - it was
> > an odd/even issue).
> 
> That's not true. The delay was caused by the possible security issue which
> turned out to be not so bad later on. Of course, I couldn't write that on
> this list publicly. Catching the joining issue was a nice side effect.
> And I am very glad that this one is fixed as it kept users away from 3.6!

As the release was almost ready, how much extra work would it have been
to spin the security release the next week, compared with waiting,
spinning the security release, and then spinning a real release?

As this turned out to be nothing more than a DoS, could it not have
waited for the next release, or (because it isn't much more work) have
just been a release on it's own?

I asked before, but focusing on normal releases this time, what is so
costly about making releases, and how can we help reduce that cost?  
 
> > This is important, particularly as we move to Samba 4.0 with a much
> > larger codebase.  The failure to join to an S3 DC has been with us since
> > before 3.6.0, so a release without that fix would by definition be no
> > worse than 3.6.0 or any subsequent point release.  Therefore we should
> > make the release. 
> > 
> > The same *will* happen with Samba 4.0.  The new AD DC will not be
> > released perfect - no software ever is - but if we apply this test, then
> > bugs in the AD DC (and it's complex code, there is a good chance of some
> > quite serious issues despite our good results so far) will hold up file
> > server users from getting releases.  This would not be a good thing!
> > 
> > So far, due to these delays, our 3.6 users are still waiting for fixes
> > for:
> > 

> To be completed. And I know this list very well as I created it.

I'm sorry if that came across in a patronising way, but for the benefit
of the rest of the list, I felt it was important to give the scale of
the issue here. 
 
> > Should we deny our users all these fixes, because we want to get in one
> > more fix?  Instead of saying 'these serious issues remain unresolved' in
> > a WHATSNEW of a release fixing all these other things, we are saying
> > 'these serious issues remain unresolved, so you can't have a release at
> > all!'
> 
> No. Again, it's a special case this time. Due to the 3 (almost 4) security
> releases, the list of fixed bugs is longer than usual, but it's still very
> short compared with older 3.0 releases!

Why does a security release have to impact on the timeframe so much?  I
know they are a lot of work, but could we work out a way to get the cost
of the normal releases down so they are easier to fit in between them?

> > Beyond individual users (who could go to GIT if they really wanted)
> > there are other costs to constantly slipping.  For distributions, in the
> > thread on changing the stable branch rules Christian PERRIER
> > <bubulle at debian.org> said:
> > > 
> > > Next Debian stable should be frozen "Quite Soon". We hope we'll be
> > > able
> > > to get 3.6.6 in before that (which is why the delay in that release
> > > saddens me, though I understand the reasons).
> 
> Sticking to the last planned release date would have meant to ship a
> bugfix release with a known security issue (which it was to me at that
> point). That would have been inacceptable from my point of view.

Unless the security issue was introduced recently, and given we don't
bundle security releases and bugfixes, why does it make a difference, as
long as we are working to get the security release out as soon as
confirmed and isolated?

Thanks for taking the time and effort to discuss this.  It is really
important. 

Andrew Bartlett

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