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

[Lars Kurth <lars.kurth@xxxxxxxxxx>]

Wei,

this sounds reasonable. I just wanted to ensure that I understood fully?
Do you want me to update the presentation I sent you yesterday and which
is also at 
http://www.slideshare.net/xen_com_mgr/xen-project-release-and-roadmap-proce
ss with some mods to outline the changes based on what you described?

As an aside: we should also track this thread on bugs.xenproject.org - I
don't think we need a vote, but it is good to track process changes.

Regards
Lars

On 11/02/2015 11:55, "Wei Liu" <wei.liu2@xxxxxxxxxx> wrote:

>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