Date: Tue, 11 Jun 1996 20:56:57 +0300 (EET DST) From: Narvi <narvi@haldjas.folklore.ee> To: Paul Richards <p.richards@elsevier.co.uk> Cc: stable@freebsd.org Subject: Re: Status of -stable Message-ID: <Pine.BSF.3.91.960611204305.19365B-100000@haldjas.folklore.ee> In-Reply-To: <199606111708.SAA27795@cadair.elsevier.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 11 Jun 1996, Paul Richards wrote: > >>>>> "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. 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.91.960611204305.19365B-100000>