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

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Tue, Feb 10, 2015 at 07:29:30PM +0000, Lars Kurth wrote:
> Wei,
> 
> thanks for clarifying. I don't think you answered all the practical
> implications of your proposal though.
> A) Do we start making RC's straight after the Feature Freeze?

Yes. Wait for our push gate to clear then arrange RC. Basically that's
a fortnight after the freeze.

Previously we stated the freeze time is three months but in practice it
was always longer than that. It looks to me we didn't set aside enough
leeway for various things (holidays, events and  unexpected bugs etc).

> B) Will there still be exceptions? I am assuming yes

Yes. The bar would be high. The principle is only code that is 1)
self-contained, 2) has little possibility of breaking existing system
can be accepted. Maintainers can actively endorse a series if he wants
to.

> C) Do you expect a gradual decrease of what bug fixes are allowed after
> the Feature Freeze?
> 

Yes. At one point we would want declare non-critical, non-blocker bugs as
known issues and release. Just like what we did in last two releases.

> If the answer is yes to A), we would have more RC's and more test days.
> That means slightly more overhead but also - if we get good community
> engagement - better quality.
> 

The three month freeze is not a goal. If there is no critical bug after
several RCs (1~2 months) we just release and reopen for development.

> If the answer is yes to C), the Release Manager would in essence have more
> flexibility, but also has to make more decisions. The same applies to B).
>  

From what I saw during last two release cycles, maintainers generally
have very good sense on what is risky to accept and what is not. The
occasions that required release manager to make hard decision were
limited. And with the help from relevant maintainers it was possible to
come to a rational resolution in a timely manner.

> 
> I am not convinced that the hard freeze really would go away. It would
> merely not be as cleanly identifiable and we would gradually move from
> soft to hard freeze.
> 

In a way, the hard (you mean soft?) freeze is still there, but the bar
is higher.  As you said, they are not that clearly identifiable.  We
just don't advertise the period which allows patches to get merged in
last minute. Hopefully this can prompt people to submit their patches
earlier and not have a mentality to rush everything in during last
minute, Resulting in a shorter freeze time and release cycle.

Wei.

> If the answer was NO to any of the questions above, I think you would need
> to elaborate what the alternatives are.
> 
> 
> Cheers
> Lars
> 
> On 10/02/2015 18:29, "Wei Liu" <wei.liu2@xxxxxxxxxx> wrote:
> 
> >On Tue, Feb 10, 2015 at 06:04:10PM +0000, Lars Kurth wrote:
> >> Wei,
> >> could you explain what you mean by soft freeze and hard freeze.
> >> Regards
> >
> >They correspond to feature freeze and code freeze respectively.
> >
> >A bit more background information for developers that are new to the
> >community. In 4.5 and 4.4 there were two freezes, one called feature
> >freeze (soft freeze), the other called code freeze (hard freeze).
> >
> >In 4.4 and 4.5, feature posted before feature freeze but didn't get in
> >before feature freeze still have a chance to get merged, provided that
> >1) it's in good shape, 2) there is a strong argument that it should be
> >merged. Code freeze is the strict freezing point, when no more new
> >features can go in after that.
> >
> >That model has its pros and cons. I proposed in my previous email to
> >just scrap the feature freeze and go with only code freeze, with the
> >hope to create shorter release cycle and smoother workflow.
> >
> >Wei.
> 

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