Release early, Release often

[Scott Lovenberg]

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
> releases.
>

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
sane, right?


-- 
Peace and Blessings,
-Scott.