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

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 11/02/15 08:05, Jan Beulich wrote:
>>>> On 10.02.15 at 16:04, <wei.liu2@citrix.com> 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.

At the point of code freeze, the maintainers can take a decision as to
whether a pending series is just a few tweaks away from acceptance or
not.  A v1 rewriting Xen in C++ is unlikely to qualify, whereas a v10
which is mostly acked/reviewed and only has a few comments remaining is
likely to be able to be turned around in a quick time, and can be
permitted to go for one further round and be accepted.

The other advantage with a shorter release cycle and freeze is that, for
items which do miss the freeze, there is less time until staging opens
again for submissions.

One thing which could help is, where appropriate, leading patches on a
series being accepted even if the series as a whole may have issues. 
Leading patches tend to be cleanup, rather than the meat of a series. 
Taking these patches ahead of the series as a whole would reduce traffic
to xen-devel, reduce the cognitive review load of working out whether it
had changed since last time, and reduce the amount of effort required to
maintain the series as changes are made.  Of course, this should fall
strictly under the prerogative of the maintainer as to whether this is
safe to do, but I feel it could safely happen rather more than it
currently does.

~Andrew