From owner-freebsd-hackers Mon Dec 10 15:32:18 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from breg.mc.mpls.visi.com (breg.mc.mpls.visi.com [208.42.156.101]) by hub.freebsd.org (Postfix) with ESMTP id 6ED0037B417; Mon, 10 Dec 2001 15:32:08 -0800 (PST) Received: from sheol.localdomain (hawkeyd-fw.dsl.visi.com [208.42.101.193]) by breg.mc.mpls.visi.com (Postfix) with ESMTP id 62DDE2D0693; Mon, 10 Dec 2001 17:32:07 -0600 (CST) Received: (from hawkeyd@localhost) by sheol.localdomain (8.11.1/8.11.1) id fBANW6g02097; Mon, 10 Dec 2001 17:32:06 -0600 (CST) (envelope-from hawkeyd) Date: Mon, 10 Dec 2001 17:32:06 -0600 From: D J Hawkey Jr To: Robert Watson Cc: Michael Lucas , hackers@FreeBSD.ORG Subject: Re: Tangent for discussion: FreeBSD performs worse that Linux Message-ID: <20011210173206.A1795@sheol.localdomain> Reply-To: hawkeyd@visi.com References: <20011210155924.A1542@sheol.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from rwatson@FreeBSD.ORG on Mon, Dec 10, 2001 at 05:21:10PM -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Dec 10, at 05:21 PM, Robert Watson wrote: > > 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? > > > > [SNIP] > > 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 :-). Don't get me wrong - I don't expect the same level of support from the FreeBSD Project than I would from, say, Sybase or Sun. Having said that, I think FreeBSD's is outstanding, even compared to some other commercial *cough*Microsquish(tm)*cough* entities. > > 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))? > > > > [SNIP] > > > > Yes, I know this would mean additional work on the part of the hacker > > and committer ... > > > > [SNIP] > > 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 ... 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. > > [SNIP] I understand. I also understand that my questions and suggestions have the benefit of 20/20 hindsight. > > 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. > > [SNIP] My current plans are to have several patchfiles, grouped by subject (bugfix and/or enhancement), and subordinately grouped by FreeBSD release: ich_sound-patch-4.2REL.udiff delayed_ack-patch-4.2REL.udiff ich_sound-patch-4.3REL.udiff delayed_ack-patch-4.3REL.udiff ich_sound-patch-4.3STA.udiff agp_for_xf86-patch-4.2REL.udiff You get the idea. It will be all over the web page(s) that the patches are very narrowly targetted, and will list all the usual paranoia steps that should be taken for a decent fallback position should something fail. I have no intention of trying to emulate the FreeBSD model - not that it's not worth emulating, but rather, I simply don't have the resources. Unless it proves overwhelming, I do plan on offering my help in applying patches to the newbie/clueless. or to already hacked sources. Finally, it will be perfectly clear on the web page(s) that what is presented is not endorsed or supported by The Project, blah-blah-woof-woof. > 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. Well, I can't provide that level of QA, of course. I can and do run systems with these patches in place, and I pick my targets carefully. I'm not about to backport something like DIRPREFs, but things more discreet/isolated, like ICH sound and delayed ACKs, I can wrap my arms around with fair confidence that I won't muck up something else. C is no stranger to me, and I've hacked/patched a lot of source. I still maintain an X WM that's over ten years old now. Hacking FreeBSD offers one advantage over that - cross-platform compatability isn't an issue! > Broadening the charter for the > release branch would mean expanding the QA process. And, had the Core 20/20 foresight, it might well have chosen that path, no? Granted, any one patch (and therefore, release) might well take longer to complete, but continued previous-release support would be more do-able. Hey, I'm not taking _anything_ away from y'all; I think all the BSDs are outstanding products. I'm just gonna see if I can't fulfill what I percieve as a support deficiency (again, from my own perspective) in my own little way. > Robert N M Watson FreeBSD Core Team, TrustedBSD Project Dave PS, I'm rather honored that such an illustrious group has shown interest enough to even discuss all this with me. -- ______________________ ______________________ \__________________ \ D. J. HAWKEY JR. / __________________/ \________________/\ hawkeyd@visi.com /\________________/ http://www.visi.com/~hawkeyd/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message