Re: RFC: change to 6 months release cycle

[Juergen Gross <jgross@suse.com>]

On 10/05/2015 02:55 PM, Wei Liu wrote:
> On Mon, Oct 05, 2015 at 12:55:00PM +0100, Ian Campbell wrote:
>> On Mon, 2015-10-05 at 13:51 +0200, Juergen Gross wrote:
>>> On 10/05/2015 01:44 PM, Ian Campbell wrote:
>>>> On Mon, 2015-10-05 at 12:23 +0100, Wei Liu wrote:
>>>>> we can pick a stable tree every X releases etc etc.
>>>>
>>>> I think switching to an LTS style model, i.e. only supporting 1/N for
>>>> longer than it takes to release the next major version might be
>>>> interesting
>>>> to consider. I'm thinking e.g. of N=4 with a 6 month cycle.
>>>>
>>>> I think some of our downstreams (i.e. distros) would like this, since
>>>> it
>>>> gives them releases which are supported for a length of time more like
>>>> their own release cycles.
>>>
>>> And again there will be a rush to get a feature in at the end of each
>>> Nth cycle, as it will end up in the long-term stable version...
>>
>> I actually think there is plenty of stuff which people just want in _some_
>> release.
>>
>
> I concur. Having a feature in some release, albeit not the stable one,
> helps. For example, downstream developer will have a strong
> justification for backporting stuff.

How often did we have real feature backports in the past?

Won't the increasing number of feature backport requests nullify the
purpose of the short-time support of some releases: decrease the load
of the stable maintainers?

> As for "rush to get a feature at the end of each Nth cycle", it wouldn't
> put us in a worse situation than we already have because N==1 nowadays.

Sure. But reasoning "6 month release cycle is better because no feature
needs to rush in" and "doing a stable release every 2 years with a
possible rush at the end won't make it worse than today" seems to be a
little bit strange to me.

I don't fight against the 6 months release cycle. I just wanted to point
out some IMO wrong justification for it.


Juergen