Date: Fri, 7 Jun 1996 15:05:32 -0400 (EDT) From: "Marc G. Fournier" <scrappy@ki.net> To: "Karl Denninger, MCSNet" <karl@mcs.com> Cc: Greg Lehey <grog@lemis.de>, hackers@freebsd.org, freebsd-stable@freebsd.org, FreeBSD-current@freebsd.org Subject: Re: The -stable problem: my view Message-ID: <Pine.NEB.3.93.960607144806.25123A-100000@ki.net> In-Reply-To: <m0uS3fk-000IDTC@venus.mcs.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 7 Jun 1996, Karl Denninger, MCSNet wrote: > 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. > -RELEASE is 'known-to-build-and-run'...and, I believe, so are -SNAPs, so you build all yuor machines with -RELEASE, and if you feel you need to upgrade, through -SNAP on one of your machines, run it for a week so that you are confident with it, and then upgrade the rest of your machines. I believe you do have several PCs running FreeBSD now, don't you? > 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. > Sounds like the time to get a -SNAP installed... > 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. > *scratch head* if something in the select() call broke several months ago (and I *am* running -STABLE and -CURRENT machines), why wouldn't it affect everything that uses select()? I've been using innfeed here (much better then nntplink, IMHO) for the past month or so with absolutely no problems, or, no problems related to select() > > 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. > Not *really* correct...that is what the -SNAPs are for...someone (Jordan?) determines that the *current* state of -current is stable enough to package as an install kit...similar to how someday, someone will decide that 2.2 is ready for release. Or, better yet, -current *is* 2.2 and the SNAPs are 2.2.x, and > > 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). > Again, isn't this what Jordan is doing with his -SNAPs...stating that at this point in time, it is felt that -current has proven to be stable enough to make an install kit out of? Marc G. Fournier scrappy@ki.net Systems Administrator @ ki.net scrappy@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.93.960607144806.25123A-100000>