Re: RFC: change to 6 months release cycle

[Steven Haigh <netwiz@crc.id.au>]

[-- Attachment #1.1: Type: text/plain, Size: 3851 bytes --]

On 6/10/2015 12:05 AM, George Dunlap wrote:
> On Mon, Oct 5, 2015 at 12:44 PM, Steven Haigh <netwiz@crc.id.au> wrote:
>> On 5/10/2015 10:23 PM, Wei Liu wrote:
>>> On Mon, Oct 05, 2015 at 05:04:19AM -0600, Jan Beulich wrote:
>>>>>>> On 02.10.15 at 19:43, <wei.liu2@citrix.com> wrote:
>>>>> The main objection from previous discussion seems to be that "shorter
>>>>> release cycle creates burdens for downstream projects". I couldn't
>>>>> quite get the idea, but I think we can figure out a way to sort that
>>>>> out once we know what exactly the burdens are.
>>>>
>>>> I don't recall it that way. My main objection remains the resulting
>>>> higher burden of maintaining stable trees. Right now, most of the
>>>> time we have two trees to maintain. A 6-month release cycle means
>>>> three of them (shortening the time we maintain those trees doesn't
>>>> seem a viable option to me).
>>>>
>>>> Similar considerations apply to security maintenance of older trees.
>> <snip>
>>> Just to throw around some ideas: we can have more stable tree
>>> maintainers, we can pick a stable tree every X releases etc etc.
>>
>> So everyone else in the industry is increasing their support periods for
>> stable things, and we're wanting to go the opposite way?
>>
>> Sorry - but this is nuts. Have a stable branch that is actually
>> supported properly with backports of security fixes etc - then have a
>> 'bleeding edge' branch that rolls with the punches.
>>
>> Remember that folks are still running Xen 3.4 on EL5 - and will be at
>> least until 2017. I still run the occasional patch for 4.2, and most
>> people are on either 4.4 or testing with 4.5 when running with EL6.
>>
>> EL6 is supported until November 30, 2020. EL7 until 2024. People are not
>> exactly thrilled with EL7 in the virt area - but will eventually move to
>> it (or directly to EL8 or EL9).
>>
>> The 6 month release cycle is exactly why people don't run Fedora on
>> their production environments. Why are we suddenly wanting the same
>> release schedule for Xen?
>>
>> Sorry - but I'm VERY much against this proposal. Focus on stable and
>> complete, not Ooohhhh Shiny!
> 
> I think you're talking about something completely different.
> 
> Wei is talking about releasing *more often*; you're talking about
> having *longer support windows*.

I think we are both along the same lines - however we both have
different points. The problem is, the more releases you have in a
support window, the more you have to maintain.

I did like Ian's idea of a new stable / lts / whatever you want to call
it every 4 x normal releases at 6 month timing. This would mean an LTS
release would be supported for 2 years.

I would really like to see:
LTS = 4 year full support + 1 year security fixes only
Rolling Release = 6 - 12 months between releases.

Is this possible? Not really sure - but the bigger end users don't want
to have to retest everything every year. Honestly, even an LTS of
*longer* than 4 years would be good - but I'm not sure that is even in
the realm of consideration.

> Nobody is suggesting that we shouldn't have releases that are
> supported for long periods of time.  What Wei is proposing is that
> instead of releasing every 0.75 years and supporting every release for
> N years, we release every 0.5 years, but every 1.0 (or 1.5) years make
> a release that we support for N years.  Many projects do this,
> including the Linux kernel.

True, but the kernel has several orders of magnitude more resources
contributed. I still do my best to keep a security patched package of
4.2 for EL6 users - some of who don't want to move to XL due to
reworking all their management tools.

-- 
Steven Haigh

Email: netwiz@crc.id.au
Web: https://www.crc.id.au
Phone: (03) 9001 6090 - 0412 935 897


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel