Date: Fri, 7 Jun 1996 10:42:00 -0500 (CDT) From: "Karl Denninger, MCSNet" <karl@mcs.com> To: grog@lemis.de (Greg Lehey) Cc: hackers@freebsd.org, freebsd-stable@freebsd.org, FreeBSD-current@freebsd.org Subject: Re: The -stable problem: my view Message-ID: <m0uS3fk-000IDTC@venus.mcs.com> In-Reply-To: <199606071015.MAA00708@allegro.lemis.de> from "Greg Lehey" at Jun 7, 96 12:15:38 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> Sorry for the cross-posting, but I think we need to involve people in > all three groups, since -current and -hackers will both be involved > when -stable goes away. > > I buy most of Jordan's arguments about getting rid of -stable (though > I'm not sure why CVS should be the problem. Sure, I don't like it > either, but the way I see it, that's mainly a problem of > documentation), and so I'm not going to argue against killing -stable, > even though some good arguments have been put forward for its > retention. Uh, yuck. If STABLE goes away, and I cannot get a known-to-build-and-run version at a given point in time, FreeBSD goes away here. Why? Because I *cannot possibly* track -current given the state of broken code we sometimes end up with (I have tried!) and that means keeping *at least* two machines and doing continual regression tests on the -current tree. I don't have a full-time engineer at present to devote to this, nor can I afford the single mistake that destroys our environment. I can put someone on this with a 4-10 hour per week commitment, but that's about it. Somehow, the -STABLE intent must remain. I don't care *how* it is accomplished, but it has to be accomplished. An example of the problems is the difficulty in running nntplink on -STABLE; sometime a couple of months ago something in the select() call broke, has not been fixed, and nntplink won't run any longer (and yes, we have been asking infrequently and did report this when it happened). This means that one particular machine that could *really* use the recent VM fixes can't have them, because if I load that kernel on our main news system it stops talking to anyone. Not good. > 1. -current and -stable diverge too much. This means that -stable > really isn't, it's -dusty, and the occasions on which -current > updates get folded into -stable are fiascos like we've experienced > in the last week. That wasn't the intention. Yes. But throwing the baby out with the bathwater isn't the answer either. > 2. -current goes through periods of greater and less stability. It's > not practical for somebody who wants to run a stable system to > track -current. On the other hand, the more stable periods of > -current work very well. Correct as well. > What we need are shorter branches: say, we start a -stable branch at a > point on the -current branch where things are relatively stable. Then > we update it with bug fixes only for a relatively short period (say 4 > to 8 weeks). *Then we ditch it and start again at a new point on the > -current tree*. These branches could be called things like > 2.2.1-stable, 2.2.2-stable, etc. Like this, we could have our > relative stability while keeping the -stable branches more up to date. This will work if it is *clearly* documented when and if these things happen, and what you can (and cannot) keep at a given time (ie: if I must reload all the shared libraries then that effectively requires that I dump the machine and reload; this is a MAJOR problem if you're trying to track incremental improvements). .... > is included by the Makefile, and depend only on that. Does anybody > have any dependencies that couldn't be solved by this kind of method? ... > So now you'll come and say, "OK, do it". I'm not just bitching: I am > prepared to revise the whole build procedure. I think it would not > take much longer than I've spent trying to build the current version. > What do you people think? > > Greg I think it would be a *great* idea. A full build on a lightly-loaded P166 now requires nearly three hours, and that's too long for a SUP which only changes two files! -- -- Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity Modem: [+1 312 248-0900] | T1 from $600 monthly; speeds to DS-3 available Voice: [+1 312 803-MCS1] | 21 Chicagoland POPs, ISDN, 28.8, much more Fax: [+1 312 248-9865] | Email to "info@mcs.net" WWW: http://www.mcs.net/ ISDN - Get it here TODAY! | Home of Chicago's only FULL Clarinet feed!
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?m0uS3fk-000IDTC>