From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [RFC] Tweaking the release process for Xen 4.6 Date: Tue, 10 Feb 2015 16:47:54 +0000 Message-ID: <1423586871.27712.9.camel@citrix.com> References: <20150210150424.GA32743@zion.uk.xensource.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0789082522947994923==" Return-path: In-Reply-To: Content-Language: en-US List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: George Dunlap Cc: "artem.mygaiev@globallogic.com" , "oleksandr.dmytryshyn@globallogic.com" , "cyliu@suse.com" , "edmund.h.white@intel.com" , "dongxiao.xu@intel.com" , Stefano Stabellini , "JBeulich@suse.com" , "feng.wu@intel.com" , "zhigang.x.wang@oracle.com" , "parth.dixit@linaro.org" , "dkiper@net-space.pl" , "w1.huang@samsung.com" , "wency@cn.fujitsu.com" , "guijianfeng@cn.fujitsu.com" , "daniel.kiper@oracle.com" , "Tim (Xen.org)" , "zoltan.kiss@citrix.com" , yang.z.zhang@intel List-Id: xen-devel@lists.xenproject.org --===============0789082522947994923== Content-Language: en-US Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-23Yh/VP6XZST/yxLJ0SC" --=-23Yh/VP6XZST/yxLJ0SC Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2015-02-10 at 11:11 -0500, George Dunlap wrote: > On Tue, Feb 10, 2015 at 10:04 AM, Wei Liu 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 merge= d > > 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. >=20 > I think it's certainly worth a try. >=20 It does indeed, IMHO. One thing that we did, at least for the past two cycles, was to have two distinct events: - feature freeze, starting from which no more new features where=20 accepted - code freeze, starting from which no more code, apart from bug fixes,=20 where accepted Genuine question: do we still want this distinction? Maybe getting rid of it, or cutting it as short as possible/practical could help achieve what you're after (i.e., less time in freeze)? Regards, Dario --=-23Yh/VP6XZST/yxLJ0SC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEABECAAYFAlTaNjgACgkQk4XaBE3IOsRd8gCgj7cIhte1DWvH0rS8ph8IS03d xbgAniRigTo8PqDVFzVItmbgTqlvpl9C =cJjB -----END PGP SIGNATURE----- --=-23Yh/VP6XZST/yxLJ0SC-- --===============0789082522947994923== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============0789082522947994923==--