From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steven Haigh Subject: Re: RFC: change to 6 months release cycle Date: Tue, 6 Oct 2015 00:21:18 +1100 Message-ID: <5612794E.8090700@crc.id.au> References: <20151002174356.GA3577@zion.uk.xensource.com> <5612755302000078000A8114@prv-mh.provo.novell.com> <20151005112357.GC29124@zion.uk.xensource.com> <5612629E.8020003@crc.id.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5159714476281369774==" Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --===============5159714476281369774== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Mic87vFMPJvslXXlfNVQJBA2Mf8asltFv" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Mic87vFMPJvslXXlfNVQJBA2Mf8asltFv Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 6/10/2015 12:05 AM, George Dunlap wrote: > On Mon, Oct 5, 2015 at 12:44 PM, Steven Haigh wrote:= >> On 5/10/2015 10:23 PM, Wei Liu wrote: >>> On Mon, Oct 05, 2015 at 05:04:19AM -0600, Jan Beulich wrote: >>>>>>> On 02.10.15 at 19:43, wrote: >>>>> The main objection from previous discussion seems to be that "short= er >>>>> release cycle creates burdens for downstream projects". I couldn't >>>>> quite get the idea, but I think we can figure out a way to sort tha= t >>>>> out once we know what exactly the burdens are. >>>> >>>> I don't recall it that way. My main objection remains the resulting >>>> higher burden of maintaining stable trees. Right now, most of the >>>> time we have two trees to maintain. A 6-month release cycle means >>>> three of them (shortening the time we maintain those trees doesn't >>>> seem a viable option to me). >>>> >>>> Similar considerations apply to security maintenance of older trees.= >> >>> Just to throw around some ideas: we can have more stable tree >>> maintainers, we can pick a stable tree every X releases etc etc. >> >> So everyone else in the industry is increasing their support periods f= or >> stable things, and we're wanting to go the opposite way? >> >> Sorry - but this is nuts. Have a stable branch that is actually >> supported properly with backports of security fixes etc - then have a >> 'bleeding edge' branch that rolls with the punches. >> >> Remember that folks are still running Xen 3.4 on EL5 - and will be at >> least until 2017. I still run the occasional patch for 4.2, and most >> people are on either 4.4 or testing with 4.5 when running with EL6. >> >> EL6 is supported until November 30, 2020. EL7 until 2024. People are n= ot >> exactly thrilled with EL7 in the virt area - but will eventually move = to >> it (or directly to EL8 or EL9). >> >> The 6 month release cycle is exactly why people don't run Fedora on >> their production environments. Why are we suddenly wanting the same >> release schedule for Xen? >> >> Sorry - but I'm VERY much against this proposal. Focus on stable and >> complete, not Ooohhhh Shiny! >=20 > I think you're talking about something completely different. >=20 > Wei is talking about releasing *more often*; you're talking about > having *longer support windows*. I think we are both along the same lines - however we both have different points. The problem is, the more releases you have in a support window, the more you have to maintain. I did like Ian's idea of a new stable / lts / whatever you want to call it every 4 x normal releases at 6 month timing. This would mean an LTS release would be supported for 2 years. I would really like to see: LTS =3D 4 year full support + 1 year security fixes only Rolling Release =3D 6 - 12 months between releases. Is this possible? Not really sure - but the bigger end users don't want to have to retest everything every year. Honestly, even an LTS of *longer* than 4 years would be good - but I'm not sure that is even in the realm of consideration. > Nobody is suggesting that we shouldn't have releases that are > supported for long periods of time. What Wei is proposing is that > instead of releasing every 0.75 years and supporting every release for > N years, we release every 0.5 years, but every 1.0 (or 1.5) years make > a release that we support for N years. Many projects do this, > including the Linux kernel. True, but the kernel has several orders of magnitude more resources contributed. I still do my best to keep a security patched package of 4.2 for EL6 users - some of who don't want to move to XL due to reworking all their management tools. --=20 Steven Haigh Email: netwiz@crc.id.au Web: https://www.crc.id.au Phone: (03) 9001 6090 - 0412 935 897 --Mic87vFMPJvslXXlfNVQJBA2Mf8asltFv Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWEnlXAAoJEEGvNdV6fTHcBlcP/3aJnsRCNTDFNnF7jYLhKuDP sRj54l0aVdWEgnGAH0CXihdk+B4lFSn1sxropNh++MlitBlGwvFDYlSmoxkRXt2M /dUJrDMduJIRJuZZN7vyNulpVrv5WRqV/02k3bnXQ0VjvApfq/0lITsO2msx9YSV btr2KZTX/wlsEbNQMJoV5b70tglPd0AVYsu7WvEOZqZ95hw79TUJ/zwXETDLMbd9 fiJcMcD4LJRlWQ0ssmbbjebj442G18Y1uCLjLwnN3ZObnn6xc6g9fAPys3uT9Lh5 AkeJqIbGchO+u8bEoOX62T27CpEvy6NmpsCFvKRQt7FqrBhko021dzutbk4bzAtm Y5U7l4fnE0YZg4QGIiEDoTpWQPmP4+Aqi8y0ZTmK8shWDYXaXdgkhJRW4gKE7LEf /u4GddOVZPcsCbVCkWnPgpFW0F19dqx/khidApMyxIlGJ2PUAZyyheMJxatstmGv i2Jrw3LBDknXaOGAxX7ifP8DJhn/xd5fIcTVwWt1d7+qV7ITpAMekJdgSOs8ARDX su0eOOZId40oqkIp7Pbb/E9od8+JC0GRo52xGd96dcmna4zx+2ULbBforeaLe5yV KeAL2yvQDZu18m0g2BuFS6dZN6plSOW1/jdr9sW14mJARCqxrhBPmuY3X3vIL710 hRJeGA+FpGKEU3o8h8JF =lc3F -----END PGP SIGNATURE----- --Mic87vFMPJvslXXlfNVQJBA2Mf8asltFv-- --===============5159714476281369774== 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 --===============5159714476281369774==--