Release early, Release often
scott.lovenberg at gmail.com
Mon Apr 27 17:03:47 MDT 2015
On Mon, Apr 27, 2015 at 4:26 PM, Andrew Bartlett <abartlet at samba.org> wrote:
> 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
Doesn't this also raise the issue of release cycles for related and
dependent packages? Just off the top of my head, cifs-utils (which,
at times, relies on a minimum kernel release) and clustered tdb would
have to be somewhat on cycle with the Samba release to keep things
Peace and Blessings,
More information about the samba-technical