Release early, Release often

[Andrew Bartlett]

On Mon, 2015-04-27 at 21:29 +0200, Karolin Seeger wrote:
> On Mon, Apr 27, 2015 at 10:53:42AM +0200, Michael Adam wrote:
> > Hi Andrew,
> > 
> > On 2015-04-25 at 21:06 +1200, Andrew Bartlett wrote:
> > > Since the long-delayed release of Samba 4.2, I have been thinking about 
> > > our release process, and I would like to suggest a 4-6 month release cycle.

> > Iirc, I think it would reflect the situation more precisely to say that we
> > 
> > 1. previously had no fixed release cycle,
> > 2. wanted to do releases more frequently and reliably,
> > 3. had tried 6 months, saw it did not work out (too much work for Karolin iirc),
> > 4. and hence agreed to TRY the compromise of 9 a months cycle
> >    (because we did not want to go to 12 months)
> > 
> > > However, I think that '9' month release cycles are hurt us more
> > > than they have helped.  Since 2010 our last release cycles have lasted
> > > 17, 16, 10 and 15 months!
> > 
> > Right, this has not really worked out well.
> > Mainly due to delaying for features as you point out. 

...

> > I agree with most of what you are writing!
> > We should not be blocking releases for features anyways.
> > Especially from a developer's point of view, more frequent
> > releases would make that much more bearable (4 months better
> > than 6 from that pov).
> > 
> > But I think there two major concerns to be resolved:
> > 
> > 1.) load on release management:
> >     - At least this was the reason to move from 6 to try 9 months, iirc.
> >     - One could argue that a slimmer release process would
> >       ideally reduce the load on release management for each
> >       individual release.
> 
> There were times we did not have enough new features for major releases.
> Release notes were pretty short.
>  
> > 2.) lifetime of a releases:
> >     - Currently we have >= 9 months of major stable release,
> >       >=9 months of maintenance mode and  >= 9 months of
> >       security mode, hence >= 27 months of lifetime of a release.
> >     - With 4 months cycle we would be down yo 1 year of
> >       lifetime for a release.
> >     - The question is how nice this would be for the distributors
> >       and vendors, that like to rely on long term supported
> >       versions.
> >     - Hence the question (that has already been raised) whether
> >       we'd need to add long term support (LTS) releases, which
> >       would again raise the amount of work needed for releases.
> >       ==> Can we do without having LTS releases and leave that
> >           maintenance to the distributors and vendors???
> > 
> > My thoughts so far...
> > 
> > Cheers - Michael
> > 

Thanks to everyone who has commented so far for your thoughtful
consideration of this.  

I do agree, there are three issues:

* What if there is 'nothing to release'?

We should remember that making a release serves more purposes than just
putting out big, impressive features.  It also marks time, making the
next release come along sooner, ages our old releases that otherwise
would still be in maintenance and security support and brings to
productions use and real-world testing the ongoing re-factoring that
supports larger features. 

* How do we bridge between the 'enterprise' life cycle of our most
important important customers and the 'agile' life cycle we need as a
more dynamic free software project?

Nico makes a really interesting point here, that having two 'side by
side' enterprise cycles risks the version in RHEL, Debian stable et al
being very stale, if the cycles clash.  It also is part of what creates
the feature-driven delays - if a feature 'must' make it into this
release otherwise it will miss RHEL, then we are back to delaying
releases.

I see a few options here.  First, I think we need to lean on those who
wish to see Samba supported for long periods of time to do that support
work, or provide better options.  We have seen RHEL ship more modern
Samba versions in alternate packages, for example.  

Secondly, I think we could extend security support (which we frankly
always provide back a large number of releases, even if we never promise
to) to more (say 2) release cycles after maintenance. 

* Should we provide an LTS release

I'm nervous about providing an LTS.  My main concern regarding LTS
release is this:  Particularly if they are chosen before they are
released, then we re-start the pressure to delay it for 'must have'
features.  

The other concern I would see needing to be addressed is expectations
around an LTS release.  The lifetime promoted by vendors on these is
significantly more than we can offer given our own capacities.  We would
need to work out if our resources are well spent providing what could
only really be 'medium term support'. 

Thanks!

Andrew Bartlett

-- 
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team  http://samba.org
Samba Developer, Catalyst IT          http://catalyst.net.nz/services/samba