Release early, Release often

[Michael Adam]

Hi Andrew,

On 2015-04-25 at 21:06 +1200, Andrew Bartlett wrote:
> (I started this discussion somewhere else, but it belongs on samba-technical, 
> so I'm starting it again here)
> 
> 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.
> 
> We agreed back in 2010 (just after 3.5) to move to 9 month release
> cycles.

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.

> Moving to a 4-6 month release cycle means that we would stop holding up
> releases for features that 'can't wait for the next release', because it
> will be along soon enough.  
> 
> I'm mindful of the load on Karolin, but it should be less stress because
> we certainly won't be waiting for features that are not already finished
> in master, and the shorter RC releases should only be addressing actual
> regressions, not backported features that really belong in the next
> release.
> 
> For Samba 4.2 in particular, this release not only started quite late -
> we cut rc1 a full year after 4.1, but we kept on waiting and waiting for
> a feature (leases) that wasn't in master at the time we wanted to
> freeze, and we kept chasing that almost right to the end.
> 
> The position I have is that, now that we are past the disruptive time of
> the 4.0 merge, we just shouldn't be waiting for features.  We should
> instead have a much more 'linux-kernel' release schedule, making new,
> production releases on a time-frame measured in months, not years.  
> 
> We need a much higher release velocity to give our users and customers
> confidence that even if a feature is on the Roadmap as under active 
> development, or that if a feature is in master, that it will soon be 
> in a release.  
> 
> We have managed 6 month releases in the past, between 3.2, 3.3 and 3.4.
> It was only after taking 9 months to do 3.5, and that decision at
> SambaXP 2010, that the timeframes started to really extend.

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.

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20150427/00e09e8e/attachment.pgp>