RFC: change to 6 months release cycle

RFC: change to 6 months release cycle

[Wei Liu]

Hi all

As I understand it in the past there were discussions on release every
6 months. I would like to revisit this topic.

# Rationale for a shorter release cycle

The current 9 months cadence is too long. That create at least two
problems for us.

The first problem is that Xen delivers features much slower than other
projects. Linux kernel releases every 3 months. QEMU releases every 4
months. They deliver new features at a much higher frequency.

The second problem is that the opportunity cost for vendors to miss a
release is very high. When combined with the freeze exception scheme,
tension quickly builds up around cut-off point, which creates
frictions and frustrations for both contributors and maintainers. This
is detrimental to the project in the long run.

Having a shorter release cycle plus some other measures seem to make
sense.

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.

A side note is that if we really go down this route we need to stick
with it for a few releases to let people get used to it. Any change to
the release process is going to cause some issues.

# Proposed release cycle

Aim for 6 months release cycle -- 4 months development period, 2
months hardening period. Make two releases per year.

Fixed hard cut-off date, no more freeze exception. Arrange RCs
immediately after cut-off.

Take into account holiday seasons in US, Europe and China, the two
cut-off dates are the Fridays in which that last day of March and
September are in.

Targeted release date is two months after cut-off date. Still, we pick
a Friday using the same rule. We can also release a bit earlier if
everything goes well. If we somehow fail to release on time, we eat
into next development cycle. The next cut-off date will still be
fixed.

With the proposed scheme, the dates will be:

 - 4.7 cut-off date: April 1, 2016
 - 4.7 release date: June 1, 2016

 - 4.8 cut-off date: September 30, 2016
 - 4.8 release date: December 2, 2016

 - 4.9 cut-off date: March 31, 2017
 - 4.9 release date: June 2, 2017

and it goes on.

# Feasibility analysis

Xen 4.6 is almost out of the door. I think it's convenient to use it as one
data point about how we can achieve the proposed plan.

Xen 4.6 release time line broken down:

 - developemnt: 6 months
 - consideration for freeze exception: 1 week
 - applying patches with free exception: 1 week
 - fix major bugs: 2 weeks
 - RCs: every 1 to 2 weeks

We aimed for a 9 months release cycle. That means we have 3 months for
stabilisation and RCs.

Note that the 2 weeks used to fix bugs were mostly for bugs introduced
during free exception.

The riddance of freeze exception saves us at least the first 2 weeks.
And because there are less changes due to shorter development cycle and
no freeze exception, there are probably less bugs, which means we can
potentially save another week or two. So the 6 months time line is
realistic to achieve.

We branched and reopened xen-unstable at RC3 on September 9, which is
more or less two months after freeze (July 10) and one month before
anticipated release date (October 9).  With the new release cycle, we
can probably reopen the tree after 4 to 6 weeks of frozen state. This
helps our contributors upstream their code faster.

Comments are welcome!

Wei.

Re: RFC: change to 6 months release cycle

[Juergen Gross]

On 10/02/2015 07:43 PM, Wei Liu wrote:
> Hi all
>
> As I understand it in the past there were discussions on release every
> 6 months. I would like to revisit this topic.
>
> # Rationale for a shorter release cycle
>
> The current 9 months cadence is too long. That create at least two
> problems for us.
>
> The first problem is that Xen delivers features much slower than other
> projects. Linux kernel releases every 3 months. QEMU releases every 4
> months. They deliver new features at a much higher frequency.
>
> The second problem is that the opportunity cost for vendors to miss a
> release is very high. When combined with the freeze exception scheme,
> tension quickly builds up around cut-off point, which creates
> frictions and frustrations for both contributors and maintainers. This
> is detrimental to the project in the long run.
>
> Having a shorter release cycle plus some other measures seem to make
> sense.
>
> 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.
>
> A side note is that if we really go down this route we need to stick
> with it for a few releases to let people get used to it. Any change to
> the release process is going to cause some issues.
>
> # Proposed release cycle
>
> Aim for 6 months release cycle -- 4 months development period, 2
> months hardening period. Make two releases per year.
>
> Fixed hard cut-off date, no more freeze exception. Arrange RCs
> immediately after cut-off.
>
> Take into account holiday seasons in US, Europe and China, the two
> cut-off dates are the Fridays in which that last day of March and
> September are in.
>
> Targeted release date is two months after cut-off date. Still, we pick
> a Friday using the same rule. We can also release a bit earlier if
> everything goes well. If we somehow fail to release on time, we eat
> into next development cycle. The next cut-off date will still be
> fixed.
>
> With the proposed scheme, the dates will be:
>
>   - 4.7 cut-off date: April 1, 2016
>   - 4.7 release date: June 1, 2016
>
>   - 4.8 cut-off date: September 30, 2016
>   - 4.8 release date: December 2, 2016
>
>   - 4.9 cut-off date: March 31, 2017
>   - 4.9 release date: June 2, 2017
>
> and it goes on.
>
> # Feasibility analysis
>
> Xen 4.6 is almost out of the door. I think it's convenient to use it as one
> data point about how we can achieve the proposed plan.
>
> Xen 4.6 release time line broken down:
>
>   - developemnt: 6 months
>   - consideration for freeze exception: 1 week
>   - applying patches with free exception: 1 week
>   - fix major bugs: 2 weeks
>   - RCs: every 1 to 2 weeks
>
> We aimed for a 9 months release cycle. That means we have 3 months for
> stabilisation and RCs.
>
> Note that the 2 weeks used to fix bugs were mostly for bugs introduced
> during free exception.
>
> The riddance of freeze exception saves us at least the first 2 weeks.
> And because there are less changes due to shorter development cycle and
> no freeze exception, there are probably less bugs, which means we can
> potentially save another week or two. So the 6 months time line is
> realistic to achieve.

Expecting less bugs due to a shorter development cycle is strange. I'd
expect more bugs as large features have less time to be stabilized. Or
are you expecting only small features in the future? I don't hope so.


Juergen

Re: RFC: change to 6 months release cycle

[Andrew Cooper]

On 02/10/15 18:52, Juergen Gross wrote:
> On 10/02/2015 07:43 PM, Wei Liu wrote:
>> Hi all
>>
>> As I understand it in the past there were discussions on release every
>> 6 months. I would like to revisit this topic.
>>
>> # Rationale for a shorter release cycle
>>
>> The current 9 months cadence is too long. That create at least two
>> problems for us.
>>
>> The first problem is that Xen delivers features much slower than other
>> projects. Linux kernel releases every 3 months. QEMU releases every 4
>> months. They deliver new features at a much higher frequency.
>>
>> The second problem is that the opportunity cost for vendors to miss a
>> release is very high. When combined with the freeze exception scheme,
>> tension quickly builds up around cut-off point, which creates
>> frictions and frustrations for both contributors and maintainers. This
>> is detrimental to the project in the long run.
>>
>> Having a shorter release cycle plus some other measures seem to make
>> sense.
>>
>> 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.
>>
>> A side note is that if we really go down this route we need to stick
>> with it for a few releases to let people get used to it. Any change to
>> the release process is going to cause some issues.
>>
>> # Proposed release cycle
>>
>> Aim for 6 months release cycle -- 4 months development period, 2
>> months hardening period. Make two releases per year.
>>
>> Fixed hard cut-off date, no more freeze exception. Arrange RCs
>> immediately after cut-off.
>>
>> Take into account holiday seasons in US, Europe and China, the two
>> cut-off dates are the Fridays in which that last day of March and
>> September are in.
>>
>> Targeted release date is two months after cut-off date. Still, we pick
>> a Friday using the same rule. We can also release a bit earlier if
>> everything goes well. If we somehow fail to release on time, we eat
>> into next development cycle. The next cut-off date will still be
>> fixed.
>>
>> With the proposed scheme, the dates will be:
>>
>>   - 4.7 cut-off date: April 1, 2016
>>   - 4.7 release date: June 1, 2016
>>
>>   - 4.8 cut-off date: September 30, 2016
>>   - 4.8 release date: December 2, 2016
>>
>>   - 4.9 cut-off date: March 31, 2017
>>   - 4.9 release date: June 2, 2017
>>
>> and it goes on.
>>
>> # Feasibility analysis
>>
>> Xen 4.6 is almost out of the door. I think it's convenient to use it
>> as one
>> data point about how we can achieve the proposed plan.
>>
>> Xen 4.6 release time line broken down:
>>
>>   - developemnt: 6 months
>>   - consideration for freeze exception: 1 week
>>   - applying patches with free exception: 1 week
>>   - fix major bugs: 2 weeks
>>   - RCs: every 1 to 2 weeks
>>
>> We aimed for a 9 months release cycle. That means we have 3 months for
>> stabilisation and RCs.
>>
>> Note that the 2 weeks used to fix bugs were mostly for bugs introduced
>> during free exception.
>>
>> The riddance of freeze exception saves us at least the first 2 weeks.
>> And because there are less changes due to shorter development cycle and
>> no freeze exception, there are probably less bugs, which means we can
>> potentially save another week or two. So the 6 months time line is
>> realistic to achieve.
>
> Expecting less bugs due to a shorter development cycle is strange. I'd
> expect more bugs as large features have less time to be stabilized. Or
> are you expecting only small features in the future? I don't hope so.

The expectation is that with a shorter release cycle, there will be less
pressure to push large series in at the last minute, as deferring them
to the next release comes with a substantially smaller penalty.  As a
result, large series will (hopefully) be better baked when they do get
accepted.

~Andrew

Re: RFC: change to 6 months release cycle

[Ian Campbell]

On Fri, 2015-10-02 at 19:21 +0100, Andrew Cooper wrote:
> On 02/10/15 18:52, Juergen Gross wrote:
> > On 10/02/2015 07:43 PM, Wei Liu wrote:
> > > Hi all
> > > 
> > > As I understand it in the past there were discussions on release
> > > every
> > > 6 months. I would like to revisit this topic.
> > > 
> > > # Rationale for a shorter release cycle
> > > 
> > > The current 9 months cadence is too long. That create at least two
> > > problems for us.
> > > 
> > > The first problem is that Xen delivers features much slower than
> > > other
> > > projects. Linux kernel releases every 3 months. QEMU releases every 4
> > > months. They deliver new features at a much higher frequency.
> > > 
> > > The second problem is that the opportunity cost for vendors to miss a
> > > release is very high. When combined with the freeze exception scheme,
> > > tension quickly builds up around cut-off point, which creates
> > > frictions and frustrations for both contributors and maintainers.
> > > This
> > > is detrimental to the project in the long run.
> > > 
> > > Having a shorter release cycle plus some other measures seem to make
> > > sense.
> > > 
> > > 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.
> > > 
> > > A side note is that if we really go down this route we need to stick
> > > with it for a few releases to let people get used to it. Any change
> > > to
> > > the release process is going to cause some issues.
> > > 
> > > # Proposed release cycle
> > > 
> > > Aim for 6 months release cycle -- 4 months development period, 2
> > > months hardening period. Make two releases per year.
> > > 
> > > Fixed hard cut-off date, no more freeze exception. Arrange RCs
> > > immediately after cut-off.
> > > 
> > > Take into account holiday seasons in US, Europe and China, the two
> > > cut-off dates are the Fridays in which that last day of March and
> > > September are in.
> > > 
> > > Targeted release date is two months after cut-off date. Still, we
> > > pick
> > > a Friday using the same rule. We can also release a bit earlier if
> > > everything goes well. If we somehow fail to release on time, we eat
> > > into next development cycle. The next cut-off date will still be
> > > fixed.
> > > 
> > > With the proposed scheme, the dates will be:
> > > 
> > >   - 4.7 cut-off date: April 1, 2016
> > >   - 4.7 release date: June 1, 2016
> > > 
> > >   - 4.8 cut-off date: September 30, 2016
> > >   - 4.8 release date: December 2, 2016
> > > 
> > >   - 4.9 cut-off date: March 31, 2017
> > >   - 4.9 release date: June 2, 2017
> > > 
> > > and it goes on.
> > > 
> > > # Feasibility analysis
> > > 
> > > Xen 4.6 is almost out of the door. I think it's convenient to use it
> > > as one
> > > data point about how we can achieve the proposed plan.
> > > 
> > > Xen 4.6 release time line broken down:
> > > 
> > >   - developemnt: 6 months
> > >   - consideration for freeze exception: 1 week
> > >   - applying patches with free exception: 1 week
> > >   - fix major bugs: 2 weeks
> > >   - RCs: every 1 to 2 weeks
> > > 
> > > We aimed for a 9 months release cycle. That means we have 3 months
> > > for
> > > stabilisation and RCs.
> > > 
> > > Note that the 2 weeks used to fix bugs were mostly for bugs
> > > introduced
> > > during free exception.
> > > 
> > > The riddance of freeze exception saves us at least the first 2 weeks.
> > > And because there are less changes due to shorter development cycle
> > > and
> > > no freeze exception, there are probably less bugs, which means we can
> > > potentially save another week or two. So the 6 months time line is
> > > realistic to achieve.
> > 
> > Expecting less bugs due to a shorter development cycle is strange. I'd
> > expect more bugs as large features have less time to be stabilized. Or
> > are you expecting only small features in the future? I don't hope so.
> 
> The expectation is that with a shorter release cycle, there will be less
> pressure to push large series in at the last minute, as deferring them
> to the next release comes with a substantially smaller penalty.  As a
> result, large series will (hopefully) be better baked when they do get
> accepted.

Right, essentially this is reducing average the latency between acceptance
of a feature and the release which contains it, hopefully relieving some of
the pressure to get something in right away.

Obviously anything which would have gone in during the final 3 months of a
9 month release cycle will now be in the first 3 months of the next one, bu
t there is absolutely no implication on the size of an acceptable feature.

Ian.

Re: RFC: change to 6 months release cycle

[Juergen Gross]

On 10/05/2015 11:45 AM, Ian Campbell wrote:
> On Fri, 2015-10-02 at 19:21 +0100, Andrew Cooper wrote:
>> On 02/10/15 18:52, Juergen Gross wrote:
>>> On 10/02/2015 07:43 PM, Wei Liu wrote:
>>>> Hi all
>>>>
>>>> As I understand it in the past there were discussions on release
>>>> every
>>>> 6 months. I would like to revisit this topic.
>>>>
>>>> # Rationale for a shorter release cycle
>>>>
>>>> The current 9 months cadence is too long. That create at least two
>>>> problems for us.
>>>>
>>>> The first problem is that Xen delivers features much slower than
>>>> other
>>>> projects. Linux kernel releases every 3 months. QEMU releases every 4
>>>> months. They deliver new features at a much higher frequency.
>>>>
>>>> The second problem is that the opportunity cost for vendors to miss a
>>>> release is very high. When combined with the freeze exception scheme,
>>>> tension quickly builds up around cut-off point, which creates
>>>> frictions and frustrations for both contributors and maintainers.
>>>> This
>>>> is detrimental to the project in the long run.
>>>>
>>>> Having a shorter release cycle plus some other measures seem to make
>>>> sense.
>>>>
>>>> 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.
>>>>
>>>> A side note is that if we really go down this route we need to stick
>>>> with it for a few releases to let people get used to it. Any change
>>>> to
>>>> the release process is going to cause some issues.
>>>>
>>>> # Proposed release cycle
>>>>
>>>> Aim for 6 months release cycle -- 4 months development period, 2
>>>> months hardening period. Make two releases per year.
>>>>
>>>> Fixed hard cut-off date, no more freeze exception. Arrange RCs
>>>> immediately after cut-off.
>>>>
>>>> Take into account holiday seasons in US, Europe and China, the two
>>>> cut-off dates are the Fridays in which that last day of March and
>>>> September are in.
>>>>
>>>> Targeted release date is two months after cut-off date. Still, we
>>>> pick
>>>> a Friday using the same rule. We can also release a bit earlier if
>>>> everything goes well. If we somehow fail to release on time, we eat
>>>> into next development cycle. The next cut-off date will still be
>>>> fixed.
>>>>
>>>> With the proposed scheme, the dates will be:
>>>>
>>>>    - 4.7 cut-off date: April 1, 2016
>>>>    - 4.7 release date: June 1, 2016
>>>>
>>>>    - 4.8 cut-off date: September 30, 2016
>>>>    - 4.8 release date: December 2, 2016
>>>>
>>>>    - 4.9 cut-off date: March 31, 2017
>>>>    - 4.9 release date: June 2, 2017
>>>>
>>>> and it goes on.
>>>>
>>>> # Feasibility analysis
>>>>
>>>> Xen 4.6 is almost out of the door. I think it's convenient to use it
>>>> as one
>>>> data point about how we can achieve the proposed plan.
>>>>
>>>> Xen 4.6 release time line broken down:
>>>>
>>>>    - developemnt: 6 months
>>>>    - consideration for freeze exception: 1 week
>>>>    - applying patches with free exception: 1 week
>>>>    - fix major bugs: 2 weeks
>>>>    - RCs: every 1 to 2 weeks
>>>>
>>>> We aimed for a 9 months release cycle. That means we have 3 months
>>>> for
>>>> stabilisation and RCs.
>>>>
>>>> Note that the 2 weeks used to fix bugs were mostly for bugs
>>>> introduced
>>>> during free exception.
>>>>
>>>> The riddance of freeze exception saves us at least the first 2 weeks.
>>>> And because there are less changes due to shorter development cycle
>>>> and
>>>> no freeze exception, there are probably less bugs, which means we can
>>>> potentially save another week or two. So the 6 months time line is
>>>> realistic to achieve.
>>>
>>> Expecting less bugs due to a shorter development cycle is strange. I'd
>>> expect more bugs as large features have less time to be stabilized. Or
>>> are you expecting only small features in the future? I don't hope so.
>>
>> The expectation is that with a shorter release cycle, there will be less
>> pressure to push large series in at the last minute, as deferring them
>> to the next release comes with a substantially smaller penalty.  As a
>> result, large series will (hopefully) be better baked when they do get
>> accepted.
>
> Right, essentially this is reducing average the latency between acceptance
> of a feature and the release which contains it, hopefully relieving some of
> the pressure to get something in right away.
>
> Obviously anything which would have gone in during the final 3 months of a
> 9 month release cycle will now be in the first 3 months of the next one, bu
> t there is absolutely no implication on the size of an acceptable feature.

Bad example. Anything which would have gone in 3 months before the end
of the 9 month cycle will now go in just at the end of the 6 month
cycle.

The average time a feature is tested before release is about half the
release cycle. This will drop from 4.5 months to 3 months (assuming a
constant feature rate during a release cycle).

I'm not against a shorter cycle, I just wanted to point out a (in my
eyes) wrong expectation regarding number of bugs due to the changed
release cycle.


Juergen

Re: RFC: change to 6 months release cycle

[Stefano Stabellini]

On Mon, 5 Oct 2015, Ian Campbell wrote:
> On Fri, 2015-10-02 at 19:21 +0100, Andrew Cooper wrote:
> > On 02/10/15 18:52, Juergen Gross wrote:
> > > On 10/02/2015 07:43 PM, Wei Liu wrote:
> > > > Hi all
> > > > 
> > > > As I understand it in the past there were discussions on release
> > > > every
> > > > 6 months. I would like to revisit this topic.
> > > > 
> > > > # Rationale for a shorter release cycle
> > > > 
> > > > The current 9 months cadence is too long. That create at least two
> > > > problems for us.
> > > > 
> > > > The first problem is that Xen delivers features much slower than
> > > > other
> > > > projects. Linux kernel releases every 3 months. QEMU releases every 4
> > > > months. They deliver new features at a much higher frequency.
> > > > 
> > > > The second problem is that the opportunity cost for vendors to miss a
> > > > release is very high. When combined with the freeze exception scheme,
> > > > tension quickly builds up around cut-off point, which creates
> > > > frictions and frustrations for both contributors and maintainers.
> > > > This
> > > > is detrimental to the project in the long run.
> > > > 
> > > > Having a shorter release cycle plus some other measures seem to make
> > > > sense.
> > > > 
> > > > 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.
> > > > 
> > > > A side note is that if we really go down this route we need to stick
> > > > with it for a few releases to let people get used to it. Any change
> > > > to
> > > > the release process is going to cause some issues.
> > > > 
> > > > # Proposed release cycle
> > > > 
> > > > Aim for 6 months release cycle -- 4 months development period, 2
> > > > months hardening period. Make two releases per year.
> > > > 
> > > > Fixed hard cut-off date, no more freeze exception. Arrange RCs
> > > > immediately after cut-off.
> > > > 
> > > > Take into account holiday seasons in US, Europe and China, the two
> > > > cut-off dates are the Fridays in which that last day of March and
> > > > September are in.
> > > > 
> > > > Targeted release date is two months after cut-off date. Still, we
> > > > pick
> > > > a Friday using the same rule. We can also release a bit earlier if
> > > > everything goes well. If we somehow fail to release on time, we eat
> > > > into next development cycle. The next cut-off date will still be
> > > > fixed.
> > > > 
> > > > With the proposed scheme, the dates will be:
> > > > 
> > > >   - 4.7 cut-off date: April 1, 2016
> > > >   - 4.7 release date: June 1, 2016
> > > > 
> > > >   - 4.8 cut-off date: September 30, 2016
> > > >   - 4.8 release date: December 2, 2016
> > > > 
> > > >   - 4.9 cut-off date: March 31, 2017
> > > >   - 4.9 release date: June 2, 2017
> > > > 
> > > > and it goes on.
> > > > 
> > > > # Feasibility analysis
> > > > 
> > > > Xen 4.6 is almost out of the door. I think it's convenient to use it
> > > > as one
> > > > data point about how we can achieve the proposed plan.
> > > > 
> > > > Xen 4.6 release time line broken down:
> > > > 
> > > >   - developemnt: 6 months
> > > >   - consideration for freeze exception: 1 week
> > > >   - applying patches with free exception: 1 week
> > > >   - fix major bugs: 2 weeks
> > > >   - RCs: every 1 to 2 weeks
> > > > 
> > > > We aimed for a 9 months release cycle. That means we have 3 months
> > > > for
> > > > stabilisation and RCs.
> > > > 
> > > > Note that the 2 weeks used to fix bugs were mostly for bugs
> > > > introduced
> > > > during free exception.
> > > > 
> > > > The riddance of freeze exception saves us at least the first 2 weeks.
> > > > And because there are less changes due to shorter development cycle
> > > > and
> > > > no freeze exception, there are probably less bugs, which means we can
> > > > potentially save another week or two. So the 6 months time line is
> > > > realistic to achieve.

+1


> > > Expecting less bugs due to a shorter development cycle is strange. I'd
> > > expect more bugs as large features have less time to be stabilized. Or
> > > are you expecting only small features in the future? I don't hope so.
> > 
> > The expectation is that with a shorter release cycle, there will be less
> > pressure to push large series in at the last minute, as deferring them
> > to the next release comes with a substantially smaller penalty.  As a
> > result, large series will (hopefully) be better baked when they do get
> > accepted.
> 
> Right, essentially this is reducing average the latency between acceptance
> of a feature and the release which contains it, hopefully relieving some of
> the pressure to get something in right away.

I think so too

Re: RFC: change to 6 months release cycle

[Andrew Cooper]

On 02/10/15 18:43, Wei Liu wrote:
> Hi all
>
> <snip>
>
> Comments are welcome!

+1.

We have consistently hit certain problems for the past few releases.  A
6 month cycle offers a plausible easing of some of the problems, and if
the worst comes to the worst we can always decide to move back to a 9
month cycle if 6 causes more problems than expected.

~Andrew

Re: RFC: change to 6 months release cycle

[Dario Faggioli]

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

On Fri, 2015-10-02 at 18:43 +0100, Wei Liu wrote:

> # Proposed release cycle
> 
> Aim for 6 months release cycle -- 4 months development period, 2
> months hardening period. Make two releases per year.
> 
> Fixed hard cut-off date, no more freeze exception. Arrange RCs
> immediately after cut-off.
> 
> Take into account holiday seasons in US, Europe and China, the two
> cut-off dates are the Fridays in which that last day of March and
> September are in.

> Comments are welcome!
> 
+1

I do like a lot the fact that this, as Wei mentioned, gives us the
chance to (at least potentially) deliver new features and improvements
much faster/more frequent to downstreams and end users.

Also, I think the idea of code and feature freeze, with freeze
exceptions, was a good idea, and served us well for the first couple of
releases for which it's been in effect. However, lately, maybe also
because of changes/evolution of the project and the community, it has
IMO shown its limits, and did cause issues, so I'd really love ditching
that.

Regards,
Dario

-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

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

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

Re: RFC: change to 6 months release cycle

[Ian Campbell]

On Fri, 2015-10-02 at 18:43 +0100, Wei Liu wrote:

> # Proposed release cycle
> 
> Aim for 6 months release cycle -- 4 months development period, 2
> months hardening period. Make two releases per year.
> 
> Fixed hard cut-off date, no more freeze exception. Arrange RCs
> immediately after cut-off.

+1

> Take into account holiday seasons in US, Europe and China, the two
> cut-off dates are the Fridays in which that last day of March and
> September are in.

I can't actually parse(*) this but +1 to the concept of having a well
established rule based on absolute times rather than relative to some
previous event.

> Targeted release date is two months after cut-off date. Still, we pick
> a Friday using the same rule. We can also release a bit earlier if
> everything goes well. If we somehow fail to release on time, we eat
> into next development cycle. The next cut-off date will still be
> fixed.

+1, I think this is a very important difference to the current scheme,
where slippage pushes out the next release, leading to uncertainty in
general and annoying things like slowly shifting the release schedule into
clashing with all sorts of things (Xmas, Chinese New Year, etc).

Ian.

(*) I think there may be a missing "of the week", i.e. "the Fridays of the
week in which the last day of March and September falls"? Anyway, I don't
actually care what the rule is, just that it exists ;-)

Re: RFC: change to 6 months release cycle

[Wei Liu]

On Mon, Oct 05, 2015 at 10:55:37AM +0100, Ian Campbell wrote:
[...]
> > Take into account holiday seasons in US, Europe and China, the two
> > cut-off dates are the Fridays in which that last day of March and
> > September are in.
> 
> I can't actually parse(*) this but +1 to the concept of having a well
> established rule based on absolute times rather than relative to some
> previous event.
[...]
> 
> (*) I think there may be a missing "of the week", i.e. "the Fridays of the
> week in which the last day of March and September falls"? Anyway, I don't
> actually care what the rule is, just that it exists ;-)
> 

Yes. That's what I meant.

Wei.

Re: RFC: change to 6 months release cycle

[George Dunlap]

On Fri, Oct 2, 2015 at 6:43 PM, Wei Liu <wei.liu2@citrix.com> wrote:
> Hi all
>
> As I understand it in the past there were discussions on release every
> 6 months. I would like to revisit this topic.
>
> # Rationale for a shorter release cycle
>
> The current 9 months cadence is too long. That create at least two
> problems for us.
>
> The first problem is that Xen delivers features much slower than other
> projects. Linux kernel releases every 3 months. QEMU releases every 4
> months. They deliver new features at a much higher frequency.
>
> The second problem is that the opportunity cost for vendors to miss a
> release is very high. When combined with the freeze exception scheme,
> tension quickly builds up around cut-off point, which creates
> frictions and frustrations for both contributors and maintainers. This
> is detrimental to the project in the long run.
>
> Having a shorter release cycle plus some other measures seem to make
> sense.
>
> 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.
>
> A side note is that if we really go down this route we need to stick
> with it for a few releases to let people get used to it. Any change to
> the release process is going to cause some issues.
>
> # Proposed release cycle
>
> Aim for 6 months release cycle -- 4 months development period, 2
> months hardening period. Make two releases per year.
>
> Fixed hard cut-off date, no more freeze exception. Arrange RCs
> immediately after cut-off.
>
> Take into account holiday seasons in US, Europe and China, the two
> cut-off dates are the Fridays in which that last day of March and
> September are in.
>
> Targeted release date is two months after cut-off date. Still, we pick
> a Friday using the same rule. We can also release a bit earlier if
> everything goes well. If we somehow fail to release on time, we eat
> into next development cycle. The next cut-off date will still be
> fixed.

+1

>
> With the proposed scheme, the dates will be:
>
>  - 4.7 cut-off date: April 1, 2016
>  - 4.7 release date: June 1, 2016
>
>  - 4.8 cut-off date: September 30, 2016
>  - 4.8 release date: December 2, 2016
>
>  - 4.9 cut-off date: March 31, 2017
>  - 4.9 release date: June 2, 2017

Won't that mean that 4.7 will essentially have a 9-month release again?

But the actual dates all look good -- hard cut-off more than 4 weeks
after any major holiday, release 3-4 weeks before any major holiday.
So we'll basically just have to wait until 4.8 to *actually* try the
6-month cycle thing.

I'm 100% on board with the "hard cut-off", but since we're dealing
with human beings, I think we should also include another target for
people to aim for.  We should tell people to *target* submissions for
at least 1 week, maybe 2, before the hard deadline.

So that would be:

4.7 submission target: 18 March 2016
4.7 cut-off: 1 April 2016
4.7 expected release: 1 June 2016

4.8 submission target: 16 September 2016
4.8 cut-off: 30 September 2016
4.8 expected release: 2 December, 2016

 -George

Re: RFC: change to 6 months release cycle

[Wei Liu]

On Mon, Oct 05, 2015 at 11:29:35AM +0100, George Dunlap wrote:
[...]
> >
> > With the proposed scheme, the dates will be:
> >
> >  - 4.7 cut-off date: April 1, 2016
> >  - 4.7 release date: June 1, 2016
> >
> >  - 4.8 cut-off date: September 30, 2016
> >  - 4.8 release date: December 2, 2016
> >
> >  - 4.9 cut-off date: March 31, 2017
> >  - 4.9 release date: June 2, 2017
> 
> Won't that mean that 4.7 will essentially have a 9-month release again?
> 

Yes, but we need to start somewhere...

> But the actual dates all look good -- hard cut-off more than 4 weeks
> after any major holiday, release 3-4 weeks before any major holiday.
> So we'll basically just have to wait until 4.8 to *actually* try the
> 6-month cycle thing.
> 
> I'm 100% on board with the "hard cut-off", but since we're dealing
> with human beings, I think we should also include another target for
> people to aim for.  We should tell people to *target* submissions for
> at least 1 week, maybe 2, before the hard deadline.
> 

That's a good idea.

Wei.

> So that would be:
> 
> 4.7 submission target: 18 March 2016
> 4.7 cut-off: 1 April 2016
> 4.7 expected release: 1 June 2016
> 
> 4.8 submission target: 16 September 2016
> 4.8 cut-off: 30 September 2016
> 4.8 expected release: 2 December, 2016
> 
>  -George

Re: RFC: change to 6 months release cycle

[Jan Beulich]

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

> # Proposed release cycle
> 
> Aim for 6 months release cycle -- 4 months development period, 2
> months hardening period. Make two releases per year.
> 
> Fixed hard cut-off date, no more freeze exception. Arrange RCs
> immediately after cut-off.
> 
> Take into account holiday seasons in US, Europe and China, the two
> cut-off dates are the Fridays in which that last day of March and
> September are in.
> 
> Targeted release date is two months after cut-off date. Still, we pick
> a Friday using the same rule. We can also release a bit earlier if
> everything goes well. If we somehow fail to release on time, we eat
> into next development cycle. The next cut-off date will still be
> fixed.
> 
> With the proposed scheme, the dates will be:
> 
>  - 4.7 cut-off date: April 1, 2016
>  - 4.7 release date: June 1, 2016
> 
>  - 4.8 cut-off date: September 30, 2016
>  - 4.8 release date: December 2, 2016
> 
>  - 4.9 cut-off date: March 31, 2017
>  - 4.9 release date: June 2, 2017
> 
> and it goes on.

Despite my disagreement to the 6 month cycle, I do agree to
this part of the proposal, i.e. setting a fixed release schedule,
independent of how much the previous release slipped (or got
released early).

Jan

Re: RFC: change to 6 months release cycle

[Wei Liu]

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

Sorry, my memory failed me. So the major objection is the maintenance
burden of stable releases.

What do you consider "must-have"s when it comes to stable releases?

The only "must-have" to me is that we need stable releases. This
doesn't preclude us from exploring other options to achieve that goal.

Just to throw around some ideas: we can have more stable tree
maintainers, we can pick a stable tree every X releases etc etc.

> > # Proposed release cycle
> > 
> > Aim for 6 months release cycle -- 4 months development period, 2
> > months hardening period. Make two releases per year.
> > 
> > Fixed hard cut-off date, no more freeze exception. Arrange RCs
> > immediately after cut-off.
> > 
> > Take into account holiday seasons in US, Europe and China, the two
> > cut-off dates are the Fridays in which that last day of March and
> > September are in.
> > 
> > Targeted release date is two months after cut-off date. Still, we pick
> > a Friday using the same rule. We can also release a bit earlier if
> > everything goes well. If we somehow fail to release on time, we eat
> > into next development cycle. The next cut-off date will still be
> > fixed.
> > 
> > With the proposed scheme, the dates will be:
> > 
> >  - 4.7 cut-off date: April 1, 2016
> >  - 4.7 release date: June 1, 2016
> > 
> >  - 4.8 cut-off date: September 30, 2016
> >  - 4.8 release date: December 2, 2016
> > 
> >  - 4.9 cut-off date: March 31, 2017
> >  - 4.9 release date: June 2, 2017
> > 
> > and it goes on.
> 
> Despite my disagreement to the 6 month cycle, I do agree to
> this part of the proposal, i.e. setting a fixed release schedule,
> independent of how much the previous release slipped (or got
> released early).
> 

Any cycle that is not denominator of 12 is going to eventually collide
with holiday seasons. That's bad IMHO, but with adequate planning the
impact can be minimised.

Wei.

> Jan

Re: RFC: change to 6 months release cycle

[Jan Beulich]

>>> On 05.10.15 at 13:23, <wei.liu2@citrix.com> 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.
>> 
> 
> Sorry, my memory failed me. So the major objection is the maintenance
> burden of stable releases.
> 
> What do you consider "must-have"s when it comes to stable releases?
> 
> The only "must-have" to me is that we need stable releases. This
> doesn't preclude us from exploring other options to achieve that goal.
> 
> Just to throw around some ideas: we can have more stable tree
> maintainers, we can pick a stable tree every X releases etc etc.

Both points we have been discussing before:

More stable tree maintainers means higher total cost (there's certainly
some amortization if a single person maintains the same [parts of the]
tree everywhere), plus an increased chance for certain backports
ending up in only some of the trees (clearly bad if a newer one retains
a bug that got fixed in an older one).

Picking a release (or a longer term maintained one) results in some
releases being "better" than others.

Jan

Re: RFC: change to 6 months release cycle

[Wei Liu]

On Mon, Oct 05, 2015 at 05:37:32AM -0600, Jan Beulich wrote:
> >>> On 05.10.15 at 13:23, <wei.liu2@citrix.com> 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.
> >> 
> > 
> > Sorry, my memory failed me. So the major objection is the maintenance
> > burden of stable releases.
> > 
> > What do you consider "must-have"s when it comes to stable releases?
> > 
> > The only "must-have" to me is that we need stable releases. This
> > doesn't preclude us from exploring other options to achieve that goal.
> > 
> > Just to throw around some ideas: we can have more stable tree
> > maintainers, we can pick a stable tree every X releases etc etc.
> 
> Both points we have been discussing before:
> 
> More stable tree maintainers means higher total cost (there's certainly
> some amortization if a single person maintains the same [parts of the]
> tree everywhere), plus an increased chance for certain backports
> ending up in only some of the trees (clearly bad if a newer one retains
> a bug that got fixed in an older one).
> 
> Picking a release (or a longer term maintained one) results in some
> releases being "better" than others.
> 

If this is not an option for you. We can work on a technical solution
for having more stable release maintainers. 

For example, we create an email alias for stable backport requests,
subscribe every stable tree maintainers to that list. This should make
it impossible to miss patches. The rest is subject to individual stable
tree maintainers' discretion if a certain patch goes in or not. This has
worked and scaled reasonably well for Linux.

Note that I'm not advocating one solution over another. Ian's suggestion
of 1/N LTS release is worth considering. I'm just saying there is a
technical solution for having more stable tree maintainers.

Wei.

> Jan

Re: RFC: change to 6 months release cycle

[Jan Beulich]

>>> On 05.10.15 at 14:52, <wei.liu2@citrix.com> wrote:
> On Mon, Oct 05, 2015 at 05:37:32AM -0600, Jan Beulich wrote:
>> >>> On 05.10.15 at 13:23, <wei.liu2@citrix.com> 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.
>> >> 
>> > 
>> > Sorry, my memory failed me. So the major objection is the maintenance
>> > burden of stable releases.
>> > 
>> > What do you consider "must-have"s when it comes to stable releases?
>> > 
>> > The only "must-have" to me is that we need stable releases. This
>> > doesn't preclude us from exploring other options to achieve that goal.
>> > 
>> > Just to throw around some ideas: we can have more stable tree
>> > maintainers, we can pick a stable tree every X releases etc etc.
>> 
>> Both points we have been discussing before:
>> 
>> More stable tree maintainers means higher total cost (there's certainly
>> some amortization if a single person maintains the same [parts of the]
>> tree everywhere), plus an increased chance for certain backports
>> ending up in only some of the trees (clearly bad if a newer one retains
>> a bug that got fixed in an older one).
>> 
>> Picking a release (or a longer term maintained one) results in some
>> releases being "better" than others.
>> 
> 
> If this is not an option for you. We can work on a technical solution
> for having more stable release maintainers. 
> 
> For example, we create an email alias for stable backport requests,
> subscribe every stable tree maintainers to that list. This should make
> it impossible to miss patches. The rest is subject to individual stable
> tree maintainers' discretion if a certain patch goes in or not. This has
> worked and scaled reasonably well for Linux.

How many stable backport requests have you seen over the last
couple of years, perhaps excluding ones in reply to stable tree
release preparation polls? Take that number and compare to the
one of backports that actually went into the stable trees...

Jan

Re: RFC: change to 6 months release cycle

[Wei Liu]

On Mon, Oct 05, 2015 at 07:31:05AM -0600, Jan Beulich wrote:
> >>> On 05.10.15 at 14:52, <wei.liu2@citrix.com> wrote:
> > On Mon, Oct 05, 2015 at 05:37:32AM -0600, Jan Beulich wrote:
> >> >>> On 05.10.15 at 13:23, <wei.liu2@citrix.com> 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.
> >> >> 
> >> > 
> >> > Sorry, my memory failed me. So the major objection is the maintenance
> >> > burden of stable releases.
> >> > 
> >> > What do you consider "must-have"s when it comes to stable releases?
> >> > 
> >> > The only "must-have" to me is that we need stable releases. This
> >> > doesn't preclude us from exploring other options to achieve that goal.
> >> > 
> >> > Just to throw around some ideas: we can have more stable tree
> >> > maintainers, we can pick a stable tree every X releases etc etc.
> >> 
> >> Both points we have been discussing before:
> >> 
> >> More stable tree maintainers means higher total cost (there's certainly
> >> some amortization if a single person maintains the same [parts of the]
> >> tree everywhere), plus an increased chance for certain backports
> >> ending up in only some of the trees (clearly bad if a newer one retains
> >> a bug that got fixed in an older one).
> >> 
> >> Picking a release (or a longer term maintained one) results in some
> >> releases being "better" than others.
> >> 
> > 
> > If this is not an option for you. We can work on a technical solution
> > for having more stable release maintainers. 
> > 
> > For example, we create an email alias for stable backport requests,
> > subscribe every stable tree maintainers to that list. This should make
> > it impossible to miss patches. The rest is subject to individual stable
> > tree maintainers' discretion if a certain patch goes in or not. This has
> > worked and scaled reasonably well for Linux.
> 
> How many stable backport requests have you seen over the last
> couple of years, perhaps excluding ones in reply to stable tree
> release preparation polls? Take that number and compare to the
> one of backports that actually went into the stable trees...
> 

Sorry, I don't quite follow the point you're trying to make. 

Excluding replies to preparation polls, the only way of requesting a
backport is to do it in patch, which is very informal nowadays and easy
to get lost in huge amount of emails.

If you're saying the only a low number of backport requests make it to
stable trees, doesn't that mean we have issues here? Either maintainers
are overloaded hence forgetting things, or we don't have a good way of
tracking requests even if people are willing to help. Or it could be the
combination of both issues. The first issue can be addressed with more
maintainers, the second issues can be addressed with a formal way of
requesting and keeping track of backports.

If your point is "there isn't that many backport requests", doesn't it
make the argument of "having too big burden for maintaining more stable
releases" moot?

Wei.

> Jan

Re: RFC: change to 6 months release cycle

[Jan Beulich]

>>> On 05.10.15 at 15:51, <wei.liu2@citrix.com> wrote:
> On Mon, Oct 05, 2015 at 07:31:05AM -0600, Jan Beulich wrote:
>> >>> On 05.10.15 at 14:52, <wei.liu2@citrix.com> wrote:
>> > On Mon, Oct 05, 2015 at 05:37:32AM -0600, Jan Beulich wrote:
>> >> >>> On 05.10.15 at 13:23, <wei.liu2@citrix.com> 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.
>> >> >> 
>> >> > 
>> >> > Sorry, my memory failed me. So the major objection is the maintenance
>> >> > burden of stable releases.
>> >> > 
>> >> > What do you consider "must-have"s when it comes to stable releases?
>> >> > 
>> >> > The only "must-have" to me is that we need stable releases. This
>> >> > doesn't preclude us from exploring other options to achieve that goal.
>> >> > 
>> >> > Just to throw around some ideas: we can have more stable tree
>> >> > maintainers, we can pick a stable tree every X releases etc etc.
>> >> 
>> >> Both points we have been discussing before:
>> >> 
>> >> More stable tree maintainers means higher total cost (there's certainly
>> >> some amortization if a single person maintains the same [parts of the]
>> >> tree everywhere), plus an increased chance for certain backports
>> >> ending up in only some of the trees (clearly bad if a newer one retains
>> >> a bug that got fixed in an older one).
>> >> 
>> >> Picking a release (or a longer term maintained one) results in some
>> >> releases being "better" than others.
>> >> 
>> > 
>> > If this is not an option for you. We can work on a technical solution
>> > for having more stable release maintainers. 
>> > 
>> > For example, we create an email alias for stable backport requests,
>> > subscribe every stable tree maintainers to that list. This should make
>> > it impossible to miss patches. The rest is subject to individual stable
>> > tree maintainers' discretion if a certain patch goes in or not. This has
>> > worked and scaled reasonably well for Linux.
>> 
>> How many stable backport requests have you seen over the last
>> couple of years, perhaps excluding ones in reply to stable tree
>> release preparation polls? Take that number and compare to the
>> one of backports that actually went into the stable trees...
>> 
> 
> Sorry, I don't quite follow the point you're trying to make. 
> 
> Excluding replies to preparation polls, the only way of requesting a
> backport is to do it in patch, which is very informal nowadays and easy
> to get lost in huge amount of emails.
> 
> If you're saying the only a low number of backport requests make it to
> stable trees, doesn't that mean we have issues here? Either maintainers
> are overloaded hence forgetting things, or we don't have a good way of
> tracking requests even if people are willing to help. Or it could be the
> combination of both issues. The first issue can be addressed with more
> maintainers, the second issues can be addressed with a formal way of
> requesting and keeping track of backports.
> 
> If your point is "there isn't that many backport requests", doesn't it
> make the argument of "having too big burden for maintaining more stable
> releases" moot?

My point was that I'm trying to make sure that relevant changes fine
their way into the stable tree without explicit backport requests. I.e.
I don't think we have an issue now, but this model imo wouldn't work
well with multiple stable tree maintainers.

Jan

Re: RFC: change to 6 months release cycle

[Wei Liu]

On Mon, Oct 05, 2015 at 08:07:18AM -0600, Jan Beulich wrote:
[...]
> >> > For example, we create an email alias for stable backport requests,
> >> > subscribe every stable tree maintainers to that list. This should make
> >> > it impossible to miss patches. The rest is subject to individual stable
> >> > tree maintainers' discretion if a certain patch goes in or not. This has
> >> > worked and scaled reasonably well for Linux.
> >> 
> >> How many stable backport requests have you seen over the last
> >> couple of years, perhaps excluding ones in reply to stable tree
> >> release preparation polls? Take that number and compare to the
> >> one of backports that actually went into the stable trees...
> >> 
> > 
> > Sorry, I don't quite follow the point you're trying to make. 
> > 
> > Excluding replies to preparation polls, the only way of requesting a
> > backport is to do it in patch, which is very informal nowadays and easy
> > to get lost in huge amount of emails.
> > 
> > If you're saying the only a low number of backport requests make it to
> > stable trees, doesn't that mean we have issues here? Either maintainers
> > are overloaded hence forgetting things, or we don't have a good way of
> > tracking requests even if people are willing to help. Or it could be the
> > combination of both issues. The first issue can be addressed with more
> > maintainers, the second issues can be addressed with a formal way of
> > requesting and keeping track of backports.
> > 
> > If your point is "there isn't that many backport requests", doesn't it
> > make the argument of "having too big burden for maintaining more stable
> > releases" moot?
> 
> My point was that I'm trying to make sure that relevant changes fine
> their way into the stable tree without explicit backport requests. I.e.
> I don't think we have an issue now, but this model imo wouldn't work
> well with multiple stable tree maintainers.
> 

Indeed. That model only works with single stable tree maintainers.  My
point is I believe there are technical solutions and procedural
solutions to the issues introduced by the changed stable releases
procedure.

The more important question is whether you think it's worth trying 6
months cycle and introduce necessary changes to stable release models.

Wei.

> Jan

Re: RFC: change to 6 months release cycle

[Jan Beulich]

>>> On 05.10.15 at 16:50, <wei.liu2@citrix.com> wrote:
> The more important question is whether you think it's worth trying 6
> months cycle and introduce necessary changes to stable release models.

Since a majority seems to be willing to give this a try, I don't think
me not seeing the point would matter much; I'll just have to live
with it.

Jan

Re: RFC: change to 6 months release cycle

[Steven Haigh]

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

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!

-- 
Steven Haigh

Email: netwiz@crc.id.au
Web: http://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

Re: RFC: change to 6 months release cycle

[Wei Liu]

Hi Steven

On Mon, Oct 05, 2015 at 10:44:30PM +1100, Steven Haigh 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!
> 

No, you misunderstand. I'm not advocating shorten stable supports --
that's different issue from how we manage xen-unstable.

Just keep in mind that we *don't* have to stick with current stable
release model. If we fixate on one solution or one aspect of the whole
picture, then there is no problem that we can solve.

Wei.

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



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

Re: RFC: change to 6 months release cycle

[George Dunlap]

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

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.

 -George

Re: RFC: change to 6 months release cycle

[Steven Haigh]

[-- 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

Re: RFC: change to 6 months release cycle

[Wei Liu]

On Tue, Oct 06, 2015 at 12:21:18AM +1100, Steven Haigh wrote:
> 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.
> 

FWIW current scheme (last 3 releases as stable releases) means a release
is supported for at least 27 months (well, let's forget about the
possibility of releasing a version earlier than expected for now because
it never happened before).

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

Not sure if it is possible. I can't speak for stable tree maintainers.

For Linux, a LTS version is maintained from about 2.5 years to 5.5 years
(https://www.kernel.org/category/releases.html).  In that sense, we're
not particularly bad, but we're not particularly good either.

In any case, I think this is still open to discussion.

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

I don't think it is fair to mix the effort of stable tree maintenance
and development.

In terms of stable tree maintenance, Linux only has one maintainer per
tree. We're not worse than that.

I think what we can learn from Linux is that they seem to have a culture
that different vendors step up as stable tree maintainers. We're not
quite there yet.

Anyway, I think at some point we shall start a thread for stable
releases. I will make sure you are CC'ed.

Wei.

Re: RFC: change to 6 months release cycle

[Jan Beulich]

>>> On 05.10.15 at 18:22, <wei.liu2@citrix.com> wrote:
> FWIW current scheme (last 3 releases as stable releases) means a release
> is supported for at least 27 months (well, let's forget about the
> possibility of releasing a version earlier than expected for now because
> it never happened before).

Where did you find that? My understanding of the current scheme is
that we generally support branches for 18 months (plus another 18
security-only), which normally results in a wrap up release on the
oldest maintained branch once its second successor went out.

Jan

Re: RFC: change to 6 months release cycle

[Wei Liu]

On Tue, Oct 06, 2015 at 07:03:28AM -0600, Jan Beulich wrote:
> >>> On 05.10.15 at 18:22, <wei.liu2@citrix.com> wrote:
> > FWIW current scheme (last 3 releases as stable releases) means a release
> > is supported for at least 27 months (well, let's forget about the
> > possibility of releasing a version earlier than expected for now because
> > it never happened before).
> 
> Where did you find that? My understanding of the current scheme is
> that we generally support branches for 18 months (plus another 18
> security-only), which normally results in a wrap up release on the
> oldest maintained branch once its second successor went out.
> 

I was going to say I saw that in 
http://wiki.xenproject.org/wiki/Xen_Project_Maintenance_Releases
but it turned out I misremembered.

Now you point out this is wrong.  Thanks for correcting.

So the correct term is:

Stable releases are supported fully for 18 months plus another 18 months
of security update.

I will need to rectify the other email I send.

Wei.


> Jan

Re: RFC: change to 6 months release cycle

[Ian Campbell]

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.

On a completely different tack, one way of looking at this is that there
are 2 releases in a given 18 month period with 9 month cycle vs 4 in the 6
month variant but that the amount of code change in that 18 month cycle is
approximately the same for both, such that backporting over 2x 9 month
releases vs 4x 6 month ones ends up getting about the same number of cherry
-pick conflicts. Together with our recent decision to not bother with rc's
for stable releases it may be that there is very little impact on the
actual work needed to cover the same absolute time span.

Ian.

Re: RFC: change to 6 months release cycle

[Juergen Gross]

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

> On a completely different tack, one way of looking at this is that there
> are 2 releases in a given 18 month period with 9 month cycle vs 4 in the 6

Huh?

4 * 6 = 24, not 18!


Juergen

Re: RFC: change to 6 months release cycle

[Ian Campbell]

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.

> > On a completely different tack, one way of looking at this is that
> > there
> > are 2 releases in a given 18 month period with 9 month cycle vs 4 in
> > the 6
> 
> Huh?
> 
> 4 * 6 = 24, not 18!

Oops yes. 3*6=18 just makes my point more valid though I think.

Ian.

Re: RFC: change to 6 months release cycle

[Wei Liu]

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.

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.

Wei.

Re: RFC: change to 6 months release cycle

[Juergen Gross]

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

Re: RFC: change to 6 months release cycle

[Wei Liu]

On Mon, Oct 05, 2015 at 03:51:21PM +0200, Juergen Gross wrote:
> 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?
> 

I think there is misunderstanding.

I don't say it's our duty (stable maintainers) to backport feature --
we certainly don't do that even if requested. But I can imagine some
downstream has an internal tree that only accepts backporting a feature
that's already in upstream. Anyway, I can't say for sure.

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

Sure. I just want to make sure everyone is on the same page.  But for
now let's focus on things we haven't had agreement instead of all these
tiny little details. :-)

Wei.

> 
> Juergen

Re: RFC: change to 6 months release cycle

[Steven Haigh]

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

On 5/10/2015 10: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.

^^ This.

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

^^ This as well :)

-- 
Steven Haigh

Email: netwiz@crc.id.au
Web: http://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