Date: Tue, 11 Jun 1996 18:08:50 +0100 From: Paul Richards <p.richards@elsevier.co.uk> To: Narvi <narvi@haldjas.folklore.ee> Cc: stable@freebsd.org Subject: Re: Status of -stable Message-ID: <199606111708.SAA27795@cadair.elsevier.co.uk> In-Reply-To: <Pine.BSF.3.91.960611163125.17445B-100000@haldjas.folklore.ee> References: <199606110154.TAA16483@rover.village.org> <Pine.BSF.3.91.960611163125.17445B-100000@haldjas.folklore.ee>
next in thread | previous in thread | raw e-mail | index | archive | help
>>>>> "Narvi" == Narvi <narvi@haldjas.folklore.ee> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199606111708.SAA27795>