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

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Wed, Feb 11, 2015 at 10:45:44AM +0000, Andrew Cooper wrote:
> On 11/02/15 08:05, Jan Beulich wrote:
> >>>> 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.
> 
> 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.
> 

Yes. I think we can trust maintainers' judgement on this. In fact that
is what we've always been doing during last two cycles -- maintainers
actively endorsed a series if he thought it was important.

> 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.
> 

Agreed.

> 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.
> 

Agreed.

Wei.

> ~Andrew

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