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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 10.02.15 at 16:04, <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.

While I agree with others that giving this is try may certainly be
worth it, I'd like to point out another aspect: Consider a series that
has undergone 9 revisions at the time of the freeze, and the 10th
would be the final one that could go in. It would be rather
unfortunate to tell the submitter that now he's got to wait for 3 or
more months until that code can go in. Or, in order to avoid that
situation, it could increase pressure on maintainers to accept code
without all issues addressed, or with only a relaxed review done.
At least as long as we're suffering from limited reviewing capacity
and at least as long as we're having contributors who step away
from their code the moment their base submission got committed,
we should at least take this aspect into consideration.

Jan


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