[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [RFC] Tweaking the release process for Xen 4.6
Wei, could you explain what you mean by soft freeze and hard freeze. Regards Lars > On 10 Feb 2015, at 15:04, Wei Liu <wei.liu2@xxxxxxxxxx> wrote: > > Hi, all > > With Xen 4.5 released on Jan 14 and the open of Xen 4.6 (commit > 0082626f35, Jan 6), we are now one month into 4.6 development window. > > This is an email to kick off a discussion with regard to our release > process.The goal is to create a smoother workflow for everyone involved. > Emails to track features will be sent separately. > > # Xen 4.5 time frame retrospect > > Xen 4.5 time frame is as followed. > > Development start: 21 Feb 2014 > Feature freeze: 24 Sept 2014 > RC 1: 24 Oct 2014 > RC 2: 11 Nov 2014 > RC 3: 3 Dec 2014 > RC 4: 15 Dec 2014 > Release: 14 Jan 2015 > > Counting from the point that we forked the tree, it took ~11 months to > ship 4.5. The time spent on development was 7 months (Feb 21 to Sept > 24), and the time spent on freeze was ~4 months (Sept 24 to Jan 6). > > The good thing was that code quality was ensured, the downside was that > such long freeze made upstreaming new features harder for contributors > -- they need to rush to get their features at least posted in > development window, then argue for whether it's OK to get in after soft > freeze; Otherwise they risk waiting several more months. > > # 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. > > What contributors need to do with this changed process: develop and > upstream features as usual in development window, but no more arguing > whether a feature should go in after freeze. > > What maintainers / committers need to do with this changed process: > "business as usual" during development window, no more new feature > after freeze, only bug fixes can go in. > > # Proposed Xen 4.6 time frame > > With the above proposal in mind, here is my proposed time frame for > Xen 4.6 release: > > Development start: 6 Jan 2015 > Feature freeze: 10 Jul 2015 > Release date: 9 Oct 2015 (could release earlier) > > Note that the release date is not a goal. It is more like a deadline > we try to keep up with. We might be well able to release earlier if > everything is in good shape. > > Any thought on this tweaked process? Comments are welcome. > > Wei. > > _______________________________________________ > Xen-devel mailing list > Xen-devel@xxxxxxxxxxxxx > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |