Date: Thu, 19 Mar 2009 09:34:12 +0000 (GMT) From: Robert Watson <rwatson@FreeBSD.org> To: Jack Raats <jack@jarasoft.net> Cc: kama <kama@pvp.se>, Ken Smith <kensmith@cse.Buffalo.EDU>, freebsd-stable <freebsd-stable@freebsd.org> Subject: Re: FreeBSD 7.2 Release process starting... Message-ID: <alpine.BSF.2.00.0903190927320.99520@fledge.watson.org> In-Reply-To: <91210A8474CD444786833AFD3542BCCA@jarasoft.net> References: <1237299551.80881.16.camel@bauer.cse.buffalo.edu><20090318102134.D55869@ns1.as.pvp.se> <alpine.BSF.2.00.0903181134380.99720@fledge.watson.org> <91210A8474CD444786833AFD3542BCCA@jarasoft.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 19 Mar 2009, Jack Raats wrote: >> One of the most important things for us to keep an eye on in this release >> is that the boot loader now works on a number of pieces of hardware on >> which it reressed for 6.4/7.1. If it proves successful, we'll likely also >> do errata notes and roll new ISOs for 6.4. > > About FreeBSD 6.4. If you consider to make new 6.4 iso's, perhaps it would > be better to think about an 6.5 release???? It's a question of bandwidth for the release engineering team, ports team, security officer team, etc -- I think a 6.5 is pretty much out of the question right now with 8.0 preparing to ramp up and 7.2 now in flight. That gives us a short menu of options: - Errata patches - Errata patches + ISO reroll - Point release Because of the boot loader issues, errata patches don't really cut it alone, as if you can't install, you definitely can't apply errata patches :-). This suggests a reroll or a point release. For me the distinction remains fuzzy, but I think a key to either approach would be avoiding having to fully re-QA, do BETAs, build new packages, etc. This suggests taking RELENG_6_4 on some date, perhaps rebranching if it's a point release, or not if it's an ISO reroll, and bundling it with exactly the same packages we shipped in 6.4 (etc) and bumping a few documentation parts. We'd cut a release candidate just to make sure we had the bits right, ask people to test install it, etc, but as there would be no new features, we'd expect relatively little change. I think I wouldn't even change the proposed EoL date of the branch -- 7.x is doing very well, and we need developers to focus on getting 8.0 ready to ship. Robert N M Watson Computer Laboratory University of Cambridge
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.0903190927320.99520>