From owner-freebsd-stable Tue Jun 11 10:58:47 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA15609 for stable-outgoing; Tue, 11 Jun 1996 10:58:47 -0700 (PDT) Received: from mail.barrnet.net (mail.barrnet.net [131.119.246.7]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id KAA15600 for ; Tue, 11 Jun 1996 10:58:45 -0700 (PDT) Received: from haldjas.folklore.ee (Haldjas.folklore.ee [193.40.6.121]) by mail.barrnet.net (8.7.5/MAIL-RELAY-LEN) with SMTP id KAA16079 for ; Tue, 11 Jun 1996 10:58:39 -0700 (PDT) Received: (from narvi@localhost) by haldjas.folklore.ee (8.6.12/8.6.12) id UAA19785; Tue, 11 Jun 1996 20:56:58 +0300 Date: Tue, 11 Jun 1996 20:56:57 +0300 (EET DST) From: Narvi To: Paul Richards cc: stable@freebsd.org Subject: Re: Status of -stable In-Reply-To: <199606111708.SAA27795@cadair.elsevier.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-stable@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 11 Jun 1996, Paul Richards wrote: > >>>>> "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. It is present in the LINT kernel of the -SNAP and so it will likely make to the release in 2.1.5? > > >> 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. I see the -stable branch almost the only way of warranting the -releases to be stable. Perhaps not a -stable branch as we know it now but one that diverges off the -current say some months before the -release for more throughout testing. > > 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). There should be no *commits* to -stable that cause *anything to happen*. Things should be tested and then commited, maybe giving out the patches for extra testing - I don't think there would be a patch or change for which there would be only one person to want it. > > I'm perfectly happy to do this if resources are kept available on freefall > to maintain the cvs and sup/ctm facilities. > > Most probably it all shall go your way - unless something changes real soon. But I am not going to do anythibg about itr and hope I will some time get a computer to play with -current on... Sander