Re: [Xen-devel] [RFC] Tweaking the release process for Xen 4.6

[George Dunlap <dunlapg@xxxxxxxxx>]

On Tue, Feb 10, 2015 at 11:47 AM, Dario Faggioli
<dario.faggioli@xxxxxxxxxx> wrote:
> On Tue, 2015-02-10 at 11:11 -0500, George Dunlap wrote:
>> On Tue, Feb 10, 2015 at 10:04 AM, Wei Liu <wei.liu2@xxxxxxxxxx> wrote:
>
>> > # Scrapping soft freeze
>> >
>> > I think existing model (development + freeze) works well in general,
>> > but it would be better if we can shorten the time frame a bit, or try
>> > harder to stick to the 9 months promise.
>> >
>> > I would like to propose a tweak: scrap the soft freeze. The soft freeze
>> > is used to allow features posted during development window to get merged
>> > in time for a certain release. However this practice leads to longer
>> > freeze period (new features means more testing, hence longer freeze).
>> >
>> > If we scrap the soft freeze, there are several pros:
>> >
>> > 1. We only need to harden existing features in freeze. That would
>> >    probably shorten the time needed for freeze, or at least keep
>> >    everything within 3 months time frame.
>> >
>> > 2. Contributors with big features to upstream would not need to rebase
>> >    aggressively because they don't need to worry about features that
>> >    go in between soft freeze and hard freeze.
>> >
>> > 3. Contributors can accelerate their upstreaming effort by benefiting
>> >    from the possible shorter freeze time.
>> >
>> > I think this tweaked process can help make the development flow
>> > smoother. We release in a more timely manner and contributors have less
>> > work to do.
>> >
>> > The cons are of course we have shorter time in freeze and lead to
>> > possible less harden code. But I don't really see that as a big
>> > issue, given that we a) we still set aside 3 months for it, b) we
>> > only need to harden existing code.
>> >
>> > What contributors need to do with this changed process: develop and
>> > upstream features as usual in development window, but no more arguing
>> > whether a feature should go in after freeze.
>> >
>> > What maintainers / committers need to do with this changed process:
>> > "business as usual" during development window, no more new feature
>> > after freeze, only bug fixes can go in.
>> >
>> > # Proposed Xen 4.6 time frame
>> >
>> > With the above proposal in mind, here is my proposed time frame for
>> > Xen 4.6 release:
>> >
>> >   Development start: 6  Jan 2015
>> >   Feature freeze:    10 Jul 2015
>> >   Release date:      9  Oct 2015 (could release earlier)
>> >
>> > Note that the release date is not a goal. It is more like a deadline
>> > we try to keep up with. We might be well able to release earlier if
>> > everything is in good shape.
>> >
>> > Any thought on this tweaked process? Comments are welcome.
>>
>> I think it's certainly worth a try.
>>
> It does indeed, IMHO.
>
> One thing that we did, at least for the past two cycles, was to have two
> distinct events:
>  - feature freeze, starting from which no more new features where
>    accepted
>  - code freeze, starting from which no more code, apart from bug fixes,
>    where accepted
>
> Genuine question: do we still want this distinction? Maybe getting rid
> of it, or cutting it as short as possible/practical could help achieve
> what you're after (i.e., less time in freeze)?

I think he answers that here:

>> > # Scrapping soft freeze
>> >
>> > I would like to propose a tweak: scrap the soft freeze. The soft freeze
>> > is used to allow features posted during development window to get merged
>> > in time for a certain release. However this practice leads to longer
>> > freeze period (new features means more testing, hence longer freeze).

 -George

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