Date: Mon, 10 Dec 2001 17:21:10 -0500 (EST) From: Robert Watson <rwatson@FreeBSD.ORG> To: D J Hawkey Jr <hawkeyd@visi.com> Cc: Michael Lucas <mwlucas@FreeBSD.ORG>, hackers@FreeBSD.ORG Subject: Re: Tangent for discussion: FreeBSD performs worse that Linux Message-ID: <Pine.NEB.3.96L.1011210170942.4035Z-100000@fledge.watson.org> In-Reply-To: <20011210155924.A1542@sheol.localdomain>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 10 Dec 2001, D J Hawkey Jr wrote: > So, my question is then, just what is the policy defining > non-current-but- still-supported-releases? > > Right now, these is exactly one such release, 4.3, for security fixes. > Will there always be exactly one, such that when 4.5 is released, 4.3 > will fall off the planet, and 4.4 takes its place? Or might there be > two, 4.3 and 4.4? It depends on the level of work required, I expect. Right now, we're actively supporting 4.3-RELEASE and 4.4-RELEASE. Once we get to a point where the cost is greater than can be handled by our all-volunteer staff, we'll cut back. Currently, my hope is that we can keep supporting all branches of 4.x-RELEASE through to 5.0-RELEASE next year. If we try to avoid doing too many releases, that will be easier :-). > This comes 'round to one of my original questions, too: Why, as an > example, isn't the DELACK patches Matt made recently considered > "important" enough to be backported to RELENG_4_3 (which I have more > generically referred to as RELENG_(current - 1) or RELENG_(release - > 1))? It has been said that a fix might be backported to RELENG_(current > - 1) that isn't necessarily a security issue; can't that be expanded to > any (or perhaps just "major") fixes that don't imply a new feature of > RELENG_(current)? > > Yes, I know this would mean additional work on the part of the hacker > and committer, but is it not better they do it, than the likes of me, an > user/ admin that isn't necessarily in a position to stay -STABLE, but > knows enough of C and patch(1) to pro'lly get things right most of the > time? > > The problem with the latter is that I can't possibly know of what's > getting fixed in -STABLE (or -CURRENT), or the "severity" of the fixes, > without considerably more effort than that of the former. Then, I still > might not get it right, just 'cuz I'm not the expert the > hacker/committer is. The quick answer is: because the security-officer team is using the RELENG_4_x branches to generate binary updates, and has extremely limited resources. As such, the only things being merged onto the branch are security fixes. If the release engineering team is willing to take over the task of generating binary updates, and wants to broaden the scope of the branch, then such a proposal might make more sense. The goal of creating the branches was to permit version control to be applied to a series of updates that were previously being managed by hand: security patches. Using CVS allows the security-officer team to make the resulting patches more reproduceable, allows tag management for patchlevels, etc. While I'm sympathetic to the cause of "we want a -NOT-AS-AGRESSIVE-AS-STABLE-BUT-NOT-JUST-SECURITY-FIXES", I think our resources are already spread too thin to support that. If we were to move to a model where the branch was maintained by re@, who generated binary updates based on commits to the branch, and managed the QA process, looking at a broader scope of potential commits might be feasible. In such a scenario, the SO would work with re@ to get security fixes into the branch, but the re@ team would do the leg-work for updates and release notes. > The site Michael and I have discussed will be hugely deficient in terms > of what can be made available to any previous release (compared to what > is applied to -STABLE), but as it sits right now, it would be better > than nought for those that can't stay -STABLE. I think in practice you'll find what is needed is the ability to do local revision management in the form of branches. You may want to investigate version control software other than CVS, in that case. A number of consumers of FreeBSD, such as Yahoo!, make use of Perforce, importing the FreeBSD CVS repo hourly into a vendor branch. They can then maintain local changes relative to that branch easily. Note that you'd still be left with a heavy burden, however: QA. Part of the currently goal of RELENG_4_x is that each change be extensively tested, and usable by a wide audience with low levels of concern about picking up potentially conflicting changes. Most of the changes are very small, and as such have a higher probability of correctness. Broadening the charter for the release branch would mean expanding the QA process. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1011210170942.4035Z-100000>