[VOTE] Release cycle scheme

[VOTE] Release cycle scheme

[Wei Liu]

Hi committers,

There doesn't seem to be consensus on how release cycle should be
managed. In the survey [0] about release cycle there were following
proposed schemes:

#1. 6 months release cycle + current stable release scheme
#2. 6 months release cycle + LTS scheme
#3. 6 months release cycle + extended security support
#4. 9 months release cycle + current stable release scheme (no change
    at all)

And the tally:

		#1	#2	#3	#4
George		+1	+2		-2
Dario		+1	+2		-2
Stefano		+1	+2		-2
Ian C		+1	+1	+1	-1
Olaf		+1	 0	+1	 0
Juergen		 0	-1	 	+1
Ian J		+2	+1	+1	-2
Andrew		+1	+1		-1
Jan		-1	-1	 0	+1


There are comments made by individuals that couldn't be clearly
represent in tally. The most acceptable option to stable tree
maintainers is #1.

So I propose we use the following scheme:

- 6 months release cycle from unstable branch.
  - 4 months development.
  - 2 months freeze.
  - Eat into next cycle if doesn't release on time.
- Fixed cut-off date: the Fridays of the week in which the last day of
  March and September falls.
- No more freeze exception, but heads-up mails about freeze will be
  sent a few weeks before hand.
- Stable branch maintained for 18 months full support plus 18 months
  security support. No mixed maintainership for stable trees.


Please vote to ack or nack this proposal.


Thanks
Wei.

[0]: <20151012173222.GE2421@zion.uk.xensource.com>

Re: [VOTE] Release cycle scheme

[Lars Kurth]

Hi everyone,
may I ask you to prioritise this vote, such that 4.7 release planning can start? Right now, it is holding up the release planning process, which normally starts around a month after a release (the release was on the 13th of Oct, well a little earlier of we count branching).
Lars

> On 2 Nov 2015, at 13:47, Wei Liu <wei.liu2@citrix.com> wrote:
> 
> Hi committers,
> 
> There doesn't seem to be consensus on how release cycle should be
> managed. In the survey [0] about release cycle there were following
> proposed schemes:
> 
> #1. 6 months release cycle + current stable release scheme
> #2. 6 months release cycle + LTS scheme
> #3. 6 months release cycle + extended security support
> #4. 9 months release cycle + current stable release scheme (no change
>    at all)
> 
> And the tally:
> 
> 		#1	#2	#3	#4
> George		+1	+2		-2
> Dario		+1	+2		-2
> Stefano		+1	+2		-2
> Ian C		+1	+1	+1	-1
> Olaf		+1	 0	+1	 0
> Juergen		 0	-1	 	+1
> Ian J		+2	+1	+1	-2
> Andrew		+1	+1		-1
> Jan		-1	-1	 0	+1
> 
> 
> There are comments made by individuals that couldn't be clearly
> represent in tally. The most acceptable option to stable tree
> maintainers is #1.
> 
> So I propose we use the following scheme:
> 
> - 6 months release cycle from unstable branch.
>  - 4 months development.
>  - 2 months freeze.
>  - Eat into next cycle if doesn't release on time.
> - Fixed cut-off date: the Fridays of the week in which the last day of
>  March and September falls.
> - No more freeze exception, but heads-up mails about freeze will be
>  sent a few weeks before hand.
> - Stable branch maintained for 18 months full support plus 18 months
>  security support. No mixed maintainership for stable trees.
> 
> 
> Please vote to ack or nack this proposal.
> 
> 
> Thanks
> Wei.
> 
> [0]: <20151012173222.GE2421@zion.uk.xensource.com>
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

Re: [VOTE] Release cycle scheme

[George Dunlap]

On Mon, Nov 2, 2015 at 1:47 PM, Wei Liu <wei.liu2@citrix.com> wrote:
> - 6 months release cycle from unstable branch.
>   - 4 months development.
>   - 2 months freeze.
>   - Eat into next cycle if doesn't release on time.
...
> - Stable branch maintained for 18 months full support plus 18 months
>   security support. No mixed maintainership for stable trees.

These are the only things I think we actually need to vote on; and for
these I have a +1 from me.

> - Fixed cut-off date: the Fridays of the week in which the last day of
>   March and September falls.
> - No more freeze exception, but heads-up mails about freeze will be
>   sent a few weeks before hand.

These should be left at the discretion of the release manager, as they
are now.  (FWIW they sound like reasonable decisions to me.)

 -George

Re: [VOTE] Release cycle scheme

[Jan Beulich]

>>> On 02.11.15 at 14:47, <wei.liu2@citrix.com> wrote:
> So I propose we use the following scheme:
> 
> - 6 months release cycle from unstable branch.
>   - 4 months development.
>   - 2 months freeze.
>   - Eat into next cycle if doesn't release on time.
> - Fixed cut-off date: the Fridays of the week in which the last day of
>   March and September falls.
> - No more freeze exception, but heads-up mails about freeze will be
>   sent a few weeks before hand.
> - Stable branch maintained for 18 months full support plus 18 months
>   security support. No mixed maintainership for stable trees.

-1 overall (the different points would get different ratings
individually)

Jan

Re: [VOTE] Release cycle scheme

[Wei Liu]

On Wed, Nov 04, 2015 at 03:46:59AM -0700, Jan Beulich wrote:
> >>> On 02.11.15 at 14:47, <wei.liu2@citrix.com> wrote:
> > So I propose we use the following scheme:
> > 
> > - 6 months release cycle from unstable branch.
> >   - 4 months development.
> >   - 2 months freeze.
> >   - Eat into next cycle if doesn't release on time.
> > - Fixed cut-off date: the Fridays of the week in which the last day of
> >   March and September falls.
> > - No more freeze exception, but heads-up mails about freeze will be
> >   sent a few weeks before hand.
> > - Stable branch maintained for 18 months full support plus 18 months
> >   security support. No mixed maintainership for stable trees.
> 
> -1 overall (the different points would get different ratings
> individually)
> 

For the record, Jan and I had a conversation on IRC. This -1 was cast on
-2...+2 scale and he changed it to -0 (against but non-blocking) to fit
in our governance.

Wei.

> Jan
> 

-- 
Wei.

Re: [VOTE] Release cycle scheme

[Lars Kurth]

On 09/11/2015 11:04, "Wei Liu" <wei.liu2@citrix.com> wrote:

>On Wed, Nov 04, 2015 at 03:46:59AM -0700, Jan Beulich wrote:
>> >>> On 02.11.15 at 14:47, <wei.liu2@citrix.com> wrote:
>> > So I propose we use the following scheme:
>> > 
>> > - 6 months release cycle from unstable branch.
>> >   - 4 months development.
>> >   - 2 months freeze.
>> >   - Eat into next cycle if doesn't release on time.
>> > - Fixed cut-off date: the Fridays of the week in which the last day of
>> >   March and September falls.
>> > - No more freeze exception, but heads-up mails about freeze will be
>> >   sent a few weeks before hand.
>> > - Stable branch maintained for 18 months full support plus 18 months
>> >   security support. No mixed maintainership for stable trees.
>> 
>> -1 overall (the different points would get different ratings
>> individually)
>> 
>
>For the record, Jan and I had a conversation on IRC. This -1 was cast on
>-2...+2 scale and he changed it to -0 (against but non-blocking) to fit
>in our governance.
>
>Wei.

It appears then, that we have a consensus and all stake-holders have
voted. I think in future, it may be good to paste snippets of clarifying
IRC conversation into the mail thread.

I was wondering, whether the dates you marked you proposed in "RFC: change
to 6 months release cycle" (see
http://markmail.org/message/hcp4wifaybk4vtkk#query:+page:1+mid:veqxur64wrwi
ni73+state:results for entire conversation) with release dates at the
beginning of June and December according to the new scheme hold (meaning
that the 4.7 release will follow a 6+2 month cycle or probably more along
the lines of 5.5+2.5), or whether maybe we gradually move to the new
scheme over two releases (4.7 and 4.8 to follow 5+2 and subsequently 4+2).
No strong opinion, just something I'd like to know.

We should probably also write a blog post and update/create information on
the wiki. Am willing to volunteer to put the latter together.

Regards
Lars

Re: [VOTE] Release cycle scheme

[Wei Liu]

On Mon, Nov 09, 2015 at 11:24:59AM +0000, Lars Kurth wrote:
> 
> 
> On 09/11/2015 11:04, "Wei Liu" <wei.liu2@citrix.com> wrote:
> 
> >On Wed, Nov 04, 2015 at 03:46:59AM -0700, Jan Beulich wrote:
> >> >>> On 02.11.15 at 14:47, <wei.liu2@citrix.com> wrote:
> >> > So I propose we use the following scheme:
> >> > 
> >> > - 6 months release cycle from unstable branch.
> >> >   - 4 months development.
> >> >   - 2 months freeze.
> >> >   - Eat into next cycle if doesn't release on time.
> >> > - Fixed cut-off date: the Fridays of the week in which the last day of
> >> >   March and September falls.
> >> > - No more freeze exception, but heads-up mails about freeze will be
> >> >   sent a few weeks before hand.
> >> > - Stable branch maintained for 18 months full support plus 18 months
> >> >   security support. No mixed maintainership for stable trees.
> >> 
> >> -1 overall (the different points would get different ratings
> >> individually)
> >> 
> >
> >For the record, Jan and I had a conversation on IRC. This -1 was cast on
> >-2...+2 scale and he changed it to -0 (against but non-blocking) to fit
> >in our governance.
> >
> >Wei.
> 
> It appears then, that we have a consensus and all stake-holders have
> voted. I think in future, it may be good to paste snippets of clarifying
> IRC conversation into the mail thread.
> 

That conversation was a bit long to paste in so I just stated the
conclusion.

> I was wondering, whether the dates you marked you proposed in "RFC: change
> to 6 months release cycle" (see
> http://markmail.org/message/hcp4wifaybk4vtkk#query:+page:1+mid:veqxur64wrwi
> ni73+state:results for entire conversation) with release dates at the
> beginning of June and December according to the new scheme hold (meaning
> that the 4.7 release will follow a 6+2 month cycle or probably more along
> the lines of 5.5+2.5), or whether maybe we gradually move to the new
> scheme over two releases (4.7 and 4.8 to follow 5+2 and subsequently 4+2).
> No strong opinion, just something I'd like to know.
> 

Most people agreed the fixed date arrangement is a good idea, so I would
go for end of March cut-off date.

> We should probably also write a blog post and update/create information on
> the wiki. Am willing to volunteer to put the latter together.
> 

As for blog post, I will try to come up with something after I finish my
email to xen-devel.

-- 
Wei.

Re: [VOTE] Release cycle scheme

[Lars Kurth]

On 09/11/2015 11:50, "Wei Liu" <wei.liu2@citrix.com> wrote:

>On Mon, Nov 09, 2015 at 11:24:59AM +0000, Lars Kurth wrote:
>> 
>> 
>> On 09/11/2015 11:04, "Wei Liu" <wei.liu2@citrix.com> wrote:
>> 
>> >On Wed, Nov 04, 2015 at 03:46:59AM -0700, Jan Beulich wrote:
>> >> >>> On 02.11.15 at 14:47, <wei.liu2@citrix.com> wrote:
>> >> > So I propose we use the following scheme:
>> >> > 
>> >> > - 6 months release cycle from unstable branch.
>> >> >   - 4 months development.
>> >> >   - 2 months freeze.
>> >> >   - Eat into next cycle if doesn't release on time.
>> >> > - Fixed cut-off date: the Fridays of the week in which the last
>>day of
>> >> >   March and September falls.
>> >> > - No more freeze exception, but heads-up mails about freeze will be
>> >> >   sent a few weeks before hand.
>> >> > - Stable branch maintained for 18 months full support plus 18
>>months
>> >> >   security support. No mixed maintainership for stable trees.
>> >> 
>> >> -1 overall (the different points would get different ratings
>> >> individually)
>> >> 
>> >
>> >For the record, Jan and I had a conversation on IRC. This -1 was cast
>>on
>> >-2...+2 scale and he changed it to -0 (against but non-blocking) to fit
>> >in our governance.
>> >
>> >Wei.
>> 
>> It appears then, that we have a consensus and all stake-holders have
>> voted. I think in future, it may be good to paste snippets of clarifying
>> IRC conversation into the mail thread.
>> 
>
>That conversation was a bit long to paste in so I just stated the
>conclusion.

ACK

>Most people agreed the fixed date arrangement is a good idea, so I would
>go for end of March cut-off date.

ACK

>> We should probably also write a blog post and update/create information
>>on
>> the wiki. Am willing to volunteer to put the latter together.
>> 
>
>As for blog post, I will try to come up with something after I finish my
>email to xen-devel.

Ping me when you are done. As I am in the process of updating the Xen
Project Contributor training material, I will include the new scheme and
dates. I also wanted to update http://wiki.xenproject.org/wiki/Xen_Roadmap
& 
http://xenproject.org/developers/teams/hypervisor/hypervisor-roadmap.html
accordingly. You can then refer back to it in the blog post. It is likely
to be picked up by the Register again, so we should run this past
Zibby/Sarah via publicity@.

Lars

Re: [VOTE] Release cycle scheme

[Ian Campbell]

On Mon, 2015-11-02 at 13:47 +0000, Wei Liu wrote:
> 
> So I propose we use the following scheme:
> 
> - 6 months release cycle from unstable branch.
>   - 4 months development.
>   - 2 months freeze.

+1

>   - Eat into next cycle if doesn't release on time.

+2

> - Fixed cut-off date: the Fridays of the week in which the last day of
>   March and September falls.

+2

> - No more freeze exception, but heads-up mails about freeze will be
>   sent a few weeks before hand.

+2

> - Stable branch maintained for 18 months full support plus 18 months
>   security support. No mixed maintainership for stable trees.

0.

> Please vote to ack or nack this proposal.

Overall +1. I just wanted to highlight the three aspects which really
matter IMHO (although I agree with George that the "Fixed..." and "No
more..." are really up to the RM to decide).

Ian.

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

Re: [VOTE] Release cycle scheme

[Ian Jackson]

Wei Liu writes ("[VOTE] Release cycle scheme"):
> There are comments made by individuals that couldn't be clearly
> represent in tally. The most acceptable option to stable tree
> maintainers is #1.
> 
> So I propose we use the following scheme:

+1


Following Ian Campbell's lead, I want to comment on the aspects of the
proposal:

> - 6 months release cycle from unstable branch.

+2

>   - 4 months development.
>   - 2 months freeze.
>   - Eat into next cycle if doesn't release on time.

+2

> - Fixed cut-off date: the Fridays of the week in which the last day of
>   March and September falls.

+1

You should perhaps adjust the wording here because the ends of a
"week" are slightly fuzzy.  How about "the last Friday in March or
September" ?

(With my own definition of "week", which has weeks running Sunday to
Saturday, I think what you wrote means the same as "the Friday after
the last Sunday in March or September" - which is rather complex!)

> - No more freeze exception, but heads-up mails about freeze will be
>   sent a few weeks before hand.

0

> - Stable branch maintained for 18 months full support plus 18 months
>   security support. No mixed maintainership for stable trees.

+1

Ian.

Re: [VOTE] Release cycle scheme

[Stefano Stabellini]

On Mon, 2 Nov 2015, Wei Liu wrote:
> Hi committers,

I am not a xen.git committer, but I am the qemu-xen.git committer, and
since I maintain all the qemu-xen stable trees and releases, I think
that my vote should count, at least for this proposal.


> There doesn't seem to be consensus on how release cycle should be
> managed. In the survey [0] about release cycle there were following
> proposed schemes:
> 
> #1. 6 months release cycle + current stable release scheme
> #2. 6 months release cycle + LTS scheme
> #3. 6 months release cycle + extended security support
> #4. 9 months release cycle + current stable release scheme (no change
>     at all)
> 
> And the tally:
> 
> 		#1	#2	#3	#4
> George		+1	+2		-2
> Dario		+1	+2		-2
> Stefano		+1	+2		-2
> Ian C		+1	+1	+1	-1
> Olaf		+1	 0	+1	 0
> Juergen		 0	-1	 	+1
> Ian J		+2	+1	+1	-2
> Andrew		+1	+1		-1
> Jan		-1	-1	 0	+1
> 
> 
> There are comments made by individuals that couldn't be clearly
> represent in tally. The most acceptable option to stable tree
> maintainers is #1.
> 
> So I propose we use the following scheme:
> 
> - 6 months release cycle from unstable branch.
>   - 4 months development.
>   - 2 months freeze.
>   - Eat into next cycle if doesn't release on time.

+2


> - Fixed cut-off date: the Fridays of the week in which the last day of
>   March and September falls.

+1


> - No more freeze exception, but heads-up mails about freeze will be
>   sent a few weeks before hand.

+1


> - Stable branch maintained for 18 months full support plus 18 months
>   security support. No mixed maintainership for stable trees.

-1


If I need to give an overall vote, I'll give +1.

 
> Please vote to ack or nack this proposal.
> 
> 
> Thanks
> Wei.
> 
> [0]: <20151012173222.GE2421@zion.uk.xensource.com>
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> 

Re: [VOTE] Release cycle scheme

[Tim Deegan]

At 13:47 +0000 on 02 Nov (1446472041), Wei Liu wrote:
> So I propose we use the following scheme:
> 
> - 6 months release cycle from unstable branch.
>   - 4 months development.
>   - 2 months freeze.
>   - Eat into next cycle if doesn't release on time.
> - Fixed cut-off date: the Fridays of the week in which the last day of
>   March and September falls.
> - No more freeze exception, but heads-up mails about freeze will be
>   sent a few weeks before hand.
> - Stable branch maintained for 18 months full support plus 18 months
>   security support. No mixed maintainership for stable trees.
> 
> Please vote to ack or nack this proposal.

This seems like a reasonable plan.  Since I'm not actively involved in
releases or large feature review, and I don't want to dictate things
that really only affect other people, I vote 0.

Cheers,

Tim.

Re: [VOTE] Release cycle scheme

[Konrad Rzeszutek Wilk]

On Mon, Nov 02, 2015 at 01:47:21PM +0000, Wei Liu wrote:
> Hi committers,
> 
> There doesn't seem to be consensus on how release cycle should be
> managed. In the survey [0] about release cycle there were following
> proposed schemes:
> 
> #1. 6 months release cycle + current stable release scheme
> #2. 6 months release cycle + LTS scheme
> #3. 6 months release cycle + extended security support
> #4. 9 months release cycle + current stable release scheme (no change
>     at all)
> 
> And the tally:
> 
> 		#1	#2	#3	#4
> George		+1	+2		-2
> Dario		+1	+2		-2
> Stefano		+1	+2		-2
> Ian C		+1	+1	+1	-1
> Olaf		+1	 0	+1	 0
> Juergen		 0	-1	 	+1
> Ian J		+2	+1	+1	-2
> Andrew		+1	+1		-1
> Jan		-1	-1	 0	+1
> 
> 
> There are comments made by individuals that couldn't be clearly
> represent in tally. The most acceptable option to stable tree
> maintainers is #1.
> 
> So I propose we use the following scheme:
> 
> - 6 months release cycle from unstable branch.
>   - 4 months development.
>   - 2 months freeze.
>   - Eat into next cycle if doesn't release on time.

+1
> - Fixed cut-off date: the Fridays of the week in which the last day of
>   March and September falls.

0

> - No more freeze exception, but heads-up mails about freeze will be
>   sent a few weeks before hand.

+1
> - Stable branch maintained for 18 months full support plus 18 months
>   security support. No mixed maintainership for stable trees.

0. 
> 
> 
> Please vote to ack or nack this proposal.
> 
> 
> Thanks
> Wei.
> 
> [0]: <20151012173222.GE2421@zion.uk.xensource.com>