RFC: Survey on release cycle

RFC: Survey on release cycle

[Wei Liu]

Hi all

We've had two separate discussions about release cycles, one for
normal release [0], the other for changes in stable release
maintenance and possible long term supported releases [1]. There were
overwhelming support for having a shorter release cycle from
xen-unstable but we couldn't reach consensus on how to manage stable
releases.

The details on the current 9 months release cycle and proposed 6
months release cycle can be found in [0], while the current scheme for
stable releases can be found in [2]. A plethora of arguments can be
found in both [0] and [1], but in the end most if not all of them boil
down to empirical arguments / expectations or just merely different
opinions on the same fact so there wasn't really concrete outcome of
that two threads.

With the release of 4.6, it's important that we have agreement so that
we can get on with planning next release.

There are several general options on how to proceed that I summarise
from previous discussions. Note that because there are too many moving
parts I pick some of my preferences as a starting point for the
discussion. I also omit the combination of 9 months release cycle +
LTS scheme because it doesn't look attractive in the first place.

Please express your preference with -2 (strongly argue against), -1
(not happy but not against), +1 (happy but won't argue for) and +2
(happy and argue for).

# 6 months release cycle + current stable release scheme

The same stable release scheme applies (18 months full support + 18
months security fixes). Encourage more people to step up to share the
maintenance burden if necessary. Automate part of the workflow to
maintain stable releases. Write down guideline for maintainers.

# 6 months release cycle + LTS scheme

Pick LTS release every 4 releases. Announce LTS before hand. Non-LTS
releases receive shorter support. Encourage more people to step up to
share the maintenance burden if necessary. Automate part of the
workflow to maintain stable releases and LTS releases. Write down
guideline for maintainers.

The length of support hasn't been discussed thoroughly -- but to make
LTS scheme stand out the length of support would be longer than what
we have now (18 + 18).

# 9 months release cycle + current stable release scheme

Don't change anything.


Wei.

[0] <20151002174356.GA3577@zion.uk.xensource.com>
[1] <20151006110758.GV29124@zion.uk.xensource.com>
[2] http://wiki.xenproject.org/wiki/Xen_Project_Maintenance_Releases

Re: RFC: Survey on release cycle

[Dario Faggioli]

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

On Mon, 2015-10-12 at 18:32 +0100, Wei Liu wrote:
> Hi all
> 

> Please express your preference with -2 (strongly argue against), -1
> (not happy but not against), +1 (happy but won't argue for) and +2
> (happy and argue for).
> 

> # 6 months release cycle + current stable release scheme
> 
> The same stable release scheme applies (18 months full support + 18
> months security fixes). Encourage more people to step up to share the
> maintenance burden if necessary. Automate part of the workflow to
> maintain stable releases. Write down guideline for maintainers.
> 
+1

I especially like the 6 months cadence with fixed dates. Keeping the
current stable release scheme could be a good thing, e.g., to avoid
introducing too many changes at the same time (although, I personally
think we could well give the LTS model a try, as said below).

> # 6 months release cycle + LTS scheme
> 
> Pick LTS release every 4 releases. Announce LTS before hand. Non-LTS
> releases receive shorter support. Encourage more people to step up to
> share the maintenance burden if necessary. Automate part of the
> workflow to maintain stable releases and LTS releases. Write down
> guideline for maintainers.
> 
> The length of support hasn't been discussed thoroughly -- but to make
> LTS scheme stand out the length of support would be longer than what
> we have now (18 + 18).
> 
+2

I really like the 6 months cadence with fixed dates, and, although I
don't have much experience with them, I like the LTS idea, enough to
think that we should give it a try, at least.

> # 9 months release cycle + current stable release scheme
> 
-2

As said above, I think we should go (try) 6

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: Survey on release cycle

[Stefano Stabellini]

On Mon, 12 Oct 2015, Wei Liu wrote:
> Hi all
> 
> We've had two separate discussions about release cycles, one for
> normal release [0], the other for changes in stable release
> maintenance and possible long term supported releases [1]. There were
> overwhelming support for having a shorter release cycle from
> xen-unstable but we couldn't reach consensus on how to manage stable
> releases.
> 
> The details on the current 9 months release cycle and proposed 6
> months release cycle can be found in [0], while the current scheme for
> stable releases can be found in [2]. A plethora of arguments can be
> found in both [0] and [1], but in the end most if not all of them boil
> down to empirical arguments / expectations or just merely different
> opinions on the same fact so there wasn't really concrete outcome of
> that two threads.
> 
> With the release of 4.6, it's important that we have agreement so that
> we can get on with planning next release.
> 
> There are several general options on how to proceed that I summarise
> from previous discussions. Note that because there are too many moving
> parts I pick some of my preferences as a starting point for the
> discussion. I also omit the combination of 9 months release cycle +
> LTS scheme because it doesn't look attractive in the first place.
> 
> Please express your preference with -2 (strongly argue against), -1
> (not happy but not against), +1 (happy but won't argue for) and +2
> (happy and argue for).
> 
> # 6 months release cycle + current stable release scheme
> 
> The same stable release scheme applies (18 months full support + 18
> months security fixes). Encourage more people to step up to share the
> maintenance burden if necessary. Automate part of the workflow to
> maintain stable releases. Write down guideline for maintainers.

+1
I think it would be a bit too much work for us, but we could probably
cope. However it is still better than what we have now.


> # 6 months release cycle + LTS scheme
> 
> Pick LTS release every 4 releases. Announce LTS before hand. Non-LTS
> releases receive shorter support. Encourage more people to step up to
> share the maintenance burden if necessary. Automate part of the
> workflow to maintain stable releases and LTS releases. Write down
> guideline for maintainers.
> 
> The length of support hasn't been discussed thoroughly -- but to make
> LTS scheme stand out the length of support would be longer than what
> we have now (18 + 18).

+2
LTSes solve the problem of the load on stable trees maintainers.


> # 9 months release cycle + current stable release scheme
> 
> Don't change anything.

-2

Re: RFC: Survey on release cycle

[Ian Campbell]

On Mon, 2015-10-12 at 18:32 +0100, Wei Liu wrote:
> 
[...]
> There are several general options on how to proceed that I summarise
> from previous discussions. Note that because there are too many moving
> parts I pick some of my preferences as a starting point for the
> discussion.

I take it suggesting (and voting upon) other options is also acceptable?

Assuming so then:

> # 6 months release cycle + current stable release scheme
> 
> The same stable release scheme applies (18 months full support + 18
> months security fixes). Encourage more people to step up to share the
> maintenance burden if necessary. Automate part of the workflow to
> maintain stable releases. Write down guideline for maintainers.

I think this "current stable release scheme" and "18 months full support",
implies an increase in the number of supported stable releases at any given
time.

I'd therefore like to also propose:

# 6 months release cycle + extended security support

The number of active stable branches remains constant (I think this is
currently 2, implying a reducing from 18 months to 12 months) but the
security support period is extended, such that the final cut off is the
same 36 months (18+18 in the current scheme). So this becomes 12 months of
full support + 24 months of security support.

Aside: I'm a bit confused regarding whether our "stable release scheme" is
defined in terms of number of concurrently supported releases or in terms
of an absolute time. 
http://wiki.xenproject.org/wiki/Xen_Project_Maintenance_Releases definitely
says it is concurrent release based, but your proposal above suggests
otherwise. Is the wiki wrong?

Ian.

Re: RFC: Survey on release cycle

[Jan Beulich]

>>> On 14.10.15 at 14:21, <ian.campbell@citrix.com> wrote:
> Aside: I'm a bit confused regarding whether our "stable release scheme" is
> defined in terms of number of concurrently supported releases or in terms
> of an absolute time. 
> http://wiki.xenproject.org/wiki/Xen_Project_Maintenance_Releases definitely
> says it is concurrent release based, but your proposal above suggests
> otherwise. Is the wiki wrong?

I think the distinction wasn't relevant with the (intended) 9 month cycle.

Jan

Re: RFC: Survey on release cycle

[Ian Campbell]

On Wed, 2015-10-14 at 06:30 -0600, Jan Beulich wrote:
> > > > On 14.10.15 at 14:21, <ian.campbell@citrix.com> wrote:
> > Aside: I'm a bit confused regarding whether our "stable release scheme"
> > is
> > defined in terms of number of concurrently supported releases or in
> > terms
> > of an absolute time. 
> > http://wiki.xenproject.org/wiki/Xen_Project_Maintenance_Releases defini
> > tely
> > says it is concurrent release based, but your proposal above suggests
> > otherwise. Is the wiki wrong?
> 
> I think the distinction wasn't relevant with the (intended) 9 month
> cycle.

That's true, it also wouldn't really be relevant with any given new cycle.

But it does make talking about the new schemes confusing when they are
described in terms of the current scheme implicitly assuming one way or the
other.

Ian.

Re: RFC: Survey on release cycle

[Wei Liu]

On Wed, Oct 14, 2015 at 01:21:11PM +0100, Ian Campbell wrote:
> On Mon, 2015-10-12 at 18:32 +0100, Wei Liu wrote:
> > 
> [...]
> > There are several general options on how to proceed that I summarise
> > from previous discussions. Note that because there are too many moving
> > parts I pick some of my preferences as a starting point for the
> > discussion.
> 
> I take it suggesting (and voting upon) other options is also acceptable?
> 

Yes, of course.

> Assuming so then:
> 
> > # 6 months release cycle + current stable release scheme
> > 
> > The same stable release scheme applies (18 months full support + 18
> > months security fixes). Encourage more people to step up to share the
> > maintenance burden if necessary. Automate part of the workflow to
> > maintain stable releases. Write down guideline for maintainers.
> 
> I think this "current stable release scheme" and "18 months full support",
> implies an increase in the number of supported stable releases at any given
> time.
> 

Yes, it is the case.

> I'd therefore like to also propose:
> 
> # 6 months release cycle + extended security support
> 
> The number of active stable branches remains constant (I think this is
> currently 2, implying a reducing from 18 months to 12 months) but the
> security support period is extended, such that the final cut off is the
> same 36 months (18+18 in the current scheme). So this becomes 12 months of
> full support + 24 months of security support.
> 

This is reasonable suggestions. I'm not quite sure about the number of
full support backports vs security backports though, so the actual
impact is not very clear to me. But I think it is safe to say with this
scheme the work is less.

> Aside: I'm a bit confused regarding whether our "stable release scheme" is
> defined in terms of number of concurrently supported releases or in terms
> of an absolute time. 
> http://wiki.xenproject.org/wiki/Xen_Project_Maintenance_Releases definitely
> says it is concurrent release based, but your proposal above suggests
> otherwise. Is the wiki wrong?
> 

Sorry about the confusion. I picked the time-based interpretation
because that's why I slightly preferred (again, note that all details
are merely my preferences). There is room for discussion of course.
Whether the stable releases based on absolute time or number of
concurrent releases, I won't argue for one over another.

I think it would be better if Jan or Ian J express their preference
since they have been doing this for a long time and have better ideas of
what works best, and if we need more helping hand in stable release
maintenance.

It's safe to say people expressed opinions so far care more about 6
months release cycle and are willing to comprise on how we manage
stable releases (or LTSes).

Wei.

> Ian.

Re: RFC: Survey on release cycle

[Ian Campbell]

On Wed, 2015-10-14 at 14:08 +0100, Wei Liu wrote:
> On Wed, Oct 14, 2015 at 01:21:11PM +0100, Ian Campbell wrote:
> > Aside: I'm a bit confused regarding whether our "stable release scheme" is
> > defined in terms of number of concurrently supported releases or in terms
> > of an absolute time. 
> > http://wiki.xenproject.org/wiki/Xen_Project_Maintenance_Releases definitely
> > says it is concurrent release based, but your proposal above suggests
> > otherwise. Is the wiki wrong?
> > 
> 
> Sorry about the confusion. I picked the time-based interpretation
> because that's why I slightly preferred (again, note that all details
> are merely my preferences). There is room for discussion of course.
> Whether the stable releases based on absolute time or number of
> concurrent releases, I won't argue for one over another.

My confusion wasn't down to arguing for/against one or the other, just that
the options presented did not make it clear which one they were using,
which meant their use of the word "current" was potentially confusing.

Ian.

Re: RFC: Survey on release cycle

[Jan Beulich]

>>> On 12.10.15 at 19:32, <wei.liu2@citrix.com> wrote:
> # 6 months release cycle + current stable release scheme
> 
> The same stable release scheme applies (18 months full support + 18
> months security fixes). Encourage more people to step up to share the
> maintenance burden if necessary. Automate part of the workflow to
> maintain stable releases. Write down guideline for maintainers.

-1 (with a tendency towards 0 for the base proposal, i.e. willing to give
it a try, but a tendency towards -2 for the sharing of the maintenance
burden, as I don't expect much good to come from mixed maintainership
of stable branches)

> # 6 months release cycle + LTS scheme
> 
> Pick LTS release every 4 releases. Announce LTS before hand. Non-LTS
> releases receive shorter support. Encourage more people to step up to
> share the maintenance burden if necessary. Automate part of the
> workflow to maintain stable releases and LTS releases. Write down
> guideline for maintainers.
> 
> The length of support hasn't been discussed thoroughly -- but to make
> LTS scheme stand out the length of support would be longer than what
> we have now (18 + 18).

-1 (with a tendency towards -2, foreseeing non-LTS branches to
become "bad children")

> # 9 months release cycle + current stable release scheme
> 
> Don't change anything.

+1

> # 6 months release cycle + extended security support
> 
> The number of active stable branches remains constant (I think this is
> currently 2, implying a reducing from 18 months to 12 months) but the
> security support period is extended, such that the final cut off is the
> same 36 months (18+18 in the current scheme). So this becomes 12 months of
> full support + 24 months of security support.

0 (with a tendency towards -1 when taking on my SUSE hat, as a
reduction from 18 to 12 months of ordinary support means an
increased amount of patches the various distro versions will have
to carry on top of the last stable release from the respective
branch)

Jan

Re: RFC: Survey on release cycle

[Ian Campbell]

On Mon, 2015-10-12 at 18:32 +0100, Wei Liu wrote:

> # 6 months release cycle + current stable release scheme
  # 6 months release cycle + extended security support

+1 to either of these, but +2 for picking one of them.

(not really sure how to express that in a vote, sorry).

> # 6 months release cycle + LTS scheme

+1

> # 9 months release cycle + current stable release scheme

-1

Ian.

Re: RFC: Survey on release cycle

[Olaf Hering]

On Thu, Oct 15, Ian Campbell wrote:

> On Mon, 2015-10-12 at 18:32 +0100, Wei Liu wrote:
> 
> > # 6 months release cycle + current stable release scheme
>   # 6 months release cycle + extended security support
> 
> +1 to either of these, but +2 for picking one of them.

+1, as Ian said.

> (not really sure how to express that in a vote, sorry).
> 
> > # 6 months release cycle + LTS scheme

0

> > # 9 months release cycle + current stable release scheme

0

Olaf

Re: RFC: Survey on release cycle

[Juergen Gross]

On 10/12/2015 07:32 PM, Wei Liu wrote:

> Please express your preference with -2 (strongly argue against), -1
> (not happy but not against), +1 (happy but won't argue for) and +2
> (happy and argue for).
>
> # 6 months release cycle + current stable release scheme

0

> # 6 months release cycle + LTS scheme

-1

> # 9 months release cycle + current stable release scheme

+1


Juergen

Re: RFC: Survey on release cycle

[Ian Jackson]

Wei Liu writes ("[Xen-devel] RFC: Survey on release cycle"):
> Please express your preference with -2 (strongly argue against), -1
> (not happy but not against), +1 (happy but won't argue for) and +2
> (happy and argue for).
> 
> # 6 months release cycle + current stable release scheme
> 
> The same stable release scheme applies (18 months full support + 18
> months security fixes). Encourage more people to step up to share the
> maintenance burden if necessary. Automate part of the workflow to
> maintain stable releases. Write down guideline for maintainers.

+2

> # 6 months release cycle + LTS scheme
> 
> Pick LTS release every 4 releases. Announce LTS before hand. Non-LTS
> releases receive shorter support. Encourage more people to step up to
> share the maintenance burden if necessary. Automate part of the
> workflow to maintain stable releases and LTS releases. Write down
> guideline for maintainers.

+1

> The length of support hasn't been discussed thoroughly -- but to make
> LTS scheme stand out the length of support would be longer than what
> we have now (18 + 18).
> 
> # 9 months release cycle + current stable release scheme

-2

Ian.

Re: RFC: Survey on release cycle

[Ian Jackson]

Ian Campbell writes ("Re: [Xen-devel] RFC: Survey on release cycle"):
> On Mon, 2015-10-12 at 18:32 +0100, Wei Liu wrote:
> > The same stable release scheme applies (18 months full support + 18
> > months security fixes). Encourage more people to step up to share the
> > maintenance burden if necessary. Automate part of the workflow to
> > maintain stable releases. Write down guideline for maintainers.
> 
> I think this "current stable release scheme" and "18 months full support",
> implies an increase in the number of supported stable releases at any given
> time.
> 
> I'd therefore like to also propose:
> 
> # 6 months release cycle + extended security support

This would also be acceptable to me (+1 in Wei's notation).

Ian.

Re: RFC: Survey on release cycle

[Andrew Cooper]

On 12/10/15 18:32, Wei Liu wrote:
> Hi all
>
> <snip>
>
> Please express your preference with -2 (strongly argue against), -1
> (not happy but not against), +1 (happy but won't argue for) and +2
> (happy and argue for).

With my XenServer hat on, the precise release doesn't matter too much. 
For a XenServer release, we will choose something (generally lastest
stable-X.Y) and freeze on it, with only targeted bug/security fixes
being backported later on.

However, with my upstream hat on, we do have a problem, and changing the
release cadence seems to be a plausible experiment to investigate fixing it.

>
> # 6 months release cycle + current stable release scheme
> # 6 months release cycle + LTS scheme

+1 to either of these.

>
>
> # 9 months release cycle + current stable release scheme

-1

>
> Don't change anything.

-1

~Andrew