[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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.