Date: Thu, 17 Oct 1996 11:06:21 +0300 (EET DST) From: Narvi <narvi@haldjas.folklore.ee> To: Joe Greco <jgreco@brasil.moneng.mei.com> Cc: freebsd-hackers@FreeBSD.org Subject: Re: IP bugs in FreeBSD 2.1.5 Message-ID: <Pine.BSF.3.91.961017105145.17620B-100000@haldjas.folklore.ee> In-Reply-To: <199610161348.IAA27595@brasil.moneng.mei.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hmmm... I feel I trimmed the cc: list a bit. On Wed, 16 Oct 1996, Joe Greco wrote: > > We're still talking about it. Right now we still intend to release a 2.1.6 > > in December, but we are also considering releasing 2.2 at about the same time. > > With all the nifty stuff like SMP, we want to move along towards 3.0. No > > concrete decisions have yet been made, but we all would like to see the > > technology in -current enjoy wider use and this plan seems to have wide > > acceptence. > > Hi David, > > This would be, IMHO, an excellent path to follow. 2.1.5 (to become 2.1.6) > is very obviously a highly polished product, and for many of us would > continue to be the "OS of choice" for quite some time, for those demanding, > high availability applications.. There are some problems. One of these are ports. Some of ports (SSLeay for example) do not compile under -stable as they require DES code present only in -current, all new ports are for -current only and some of them won't work on -stable as they depend on say TCL being present in the system. -stable is not only dead it is even buried. And a new release on -stable will be for only very specific uses and most people perhaps even wouldn't want it. They just may require all those user programs that are only for 2.2.x. > > On the other hand, some of us are anxious enough to actually TRY 2.2R that > we will trade stability for new features. I myself have some boxes that > sit in "critical but redundant" positions and would certainly be willing > to put 2.2R to the test - IF something were available. > > I mean, I did run a production news server on 2.0R, and I am quite familiar > with the problems of running a "mostly stable" release. I did not mind the > weekly freakouts or lockups too much, as I knew my problem reports would > help make 2.0.5R a more reliable release. > > But I am not willing to try to track -current as it is just really hard to > do (I'm one guy, I don't have the hours in the day as it is)... and the > SNAP releases seem to be both bad and good... I have been tempted to look > at Karl's MCS releases. If I could get a -current that was not so subject > to such reliability variances, I would certainly run it. > > That's why the 2.2R thing seems like such a good idea. If a new "-stable" > is created at 2.2R, and "-current" goes its merry way on to 3.0R, that > gives people like me a good solid point at which to start, and a path to > follow for the next year or two while 2.2.XR becomes as stable as 2.1.5R. 3.0R? wouldn't it be a too high increment in the version number? In that way we will soon be at FreeBSD 4.3 (and 4.4) release. How about 2.4? It would allow enough of growing place for 2.2 to evolve into ultrastable 2.3 (if it stays around for that long). As we seem to be using numbers of the x.y.z kind we should think too much about x. Or are we going to undergo some *MAJOR* change? Sander > > It sounds like something along these lines is just exactly what is needed. > > Thanks for the info, > > ... JG >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.91.961017105145.17620B-100000>