From owner-freebsd-stable Tue Jun 11 10:10:48 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA12706 for stable-outgoing; Tue, 11 Jun 1996 10:10:48 -0700 (PDT) Received: from epprod.elsevier.co.uk (epprod.elsevier.co.uk [193.131.222.35]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id KAA12701 for ; Tue, 11 Jun 1996 10:10:45 -0700 (PDT) Received: from snowdon.elsevier.co.uk (snowdon.elsevier.co.uk [193.131.197.164]) by epprod.elsevier.co.uk (8.6.13/8.6.12) with ESMTP id SAA22813 for ; Tue, 11 Jun 1996 18:09:21 +0100 Received: from cadair.elsevier.co.uk (actually host cadair) by snowdon with SMTP (PP); Tue, 11 Jun 1996 18:09:32 +0100 Received: (from dpr@localhost) by cadair.elsevier.co.uk (8.6.12/8.6.12) id SAA27795; Tue, 11 Jun 1996 18:08:50 +0100 Date: Tue, 11 Jun 1996 18:08:50 +0100 Message-Id: <199606111708.SAA27795@cadair.elsevier.co.uk> To: Narvi Cc: stable@freebsd.org Subject: Re: Status of -stable In-Reply-To: References: <199606110154.TAA16483@rover.village.org> Reply-To: p.richards@elsevier.co.uk From: Paul Richards X-Attribution: Paul X-Mailer: GNU Emacs [19.30.1], RMAIL, Mailcrypt [3.3] Sender: owner-stable@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >>>>> "Narvi" == Narvi writes: Narvi> On Mon, 10 Jun 1996, Warner Losh wrote: >> I like the idea of -stable where you have MAJOR bugfixes only. >> That's it. No mega-commits. No trying to get neat new features. >> Only security holes, core dumps, data corruption and kernel panic >> fixed. The current -stable branch has been good for me in that it >> is 2.1R + a few good patches. I'd be happy with that. Something >> that you'd have to SUP once or maybe twice a month to keep current >> would be ideal. Wanna commit anything else: Tough. Use -current. >> This is somewhat of a hard line, I know, but it would mirror well >> what standard practice in the industry is. This is *exactly* my view of what -stable should be. Narvi> Then there would not be the ccd driver in -stable... :-( Tough, it's a new feature it will be in the next -current release. >> I appreciate the monitary concerns raised here. I think that if >> the volume of deltas are very small, one person could handle them >> in a sane manner. Would make a good way to donate to the FreeBSD >> project, IMHO. If no one comes forward, then I believe that the >> right approach would be to kill the whole -stable concept. While >> it does differentiate FreeBSD from the other BSDs out there, it is >> not worth undue stress and strain on the core team to make it >> happen. I've already said I'd be willing to maintain -stable if it was *just* bug fixes and access to the tree was restricted to a small handfull of stable maintainers so that changes were strictly controlled. Absolutely no retrofitting of -current stuff into it. My idea would be to run things as follows (which is what I'm planning to do for the Apache cvs tree as well): 1) I think -stable should go away since it's misleaeding, it suggests an ongoing stable branch which was never what it was supposed to be and is unworkable in practice. 2) Development is ongoing and takes place in -current. At some point it's decided that things have reached a point where it's time to do a release, a cdrom is pressed and the tree is branched so people can keep playing in -current. The -whatever (needs a name, probably something based on the release number) branch can then be used to maintain minimal impace bug fixes. I'd consider the issue of new drivers but other than that it really would be strictly maintained as a bug fix only branch. 3) The bug fix branch would be available using ctm/sup as an automated bug fix support service. We can consider the option of doing a 2.2.1 (e.g.) cdrom in between main -current driven releases if the development cycle is prolonged (which it always seems to be). Such a cdrom could have updated ports as well. 4) There would *never* be any merges from -current into -whatever. Fixes to -whatever would be done using separate patches (possibly extrated from current but more likely as things diverge by simply doing -whatever specific fixes by hand). I'm perfectly happy to do this if resources are kept available on freefall to maintain the cvs and sup/ctm facilities.