On 09/11/2015 11:50, "Wei Liu" wrote:
>On Mon, Nov 09, 2015 at 11:24:59AM +, Lars Kurth wrote:
>>
>>
>> On 09/11/2015 11:04, "Wei Liu" wrote:
>>
>> >On Wed, Nov 04, 2015 at 03:46:59AM -0700, Jan Beulich wrote:
>> >> >>> On 02.11.15 at 14:47, wrote:
>> >> > So I propose we use the follo
On Mon, Nov 09, 2015 at 11:24:59AM +, Lars Kurth wrote:
>
>
> On 09/11/2015 11:04, "Wei Liu" wrote:
>
> >On Wed, Nov 04, 2015 at 03:46:59AM -0700, Jan Beulich wrote:
> >> >>> On 02.11.15 at 14:47, wrote:
> >> > So I propose we use the following scheme:
> >> >
> >> > - 6 months release cyc
On 09/11/2015 11:04, "Wei Liu" wrote:
>On Wed, Nov 04, 2015 at 03:46:59AM -0700, Jan Beulich wrote:
>> >>> On 02.11.15 at 14:47, wrote:
>> > So I propose we use the following scheme:
>> >
>> > - 6 months release cycle from unstable branch.
>> > - 4 months development.
>> > - 2 months free
On Wed, Nov 04, 2015 at 03:46:59AM -0700, Jan Beulich wrote:
> >>> On 02.11.15 at 14:47, 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 releas
On Mon, Nov 02, 2015 at 01:47:21PM +, 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
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 relea
At 13:47 + 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 w
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 commen
On Mon, 2015-11-02 at 13:47 +, 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
>>> On 02.11.15 at 14:47, 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 las
On Mon, Nov 2, 2015 at 1:47 PM, Wei Liu 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.
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
>
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 + ex
13 matches
Mail list logo
