Date: Mon, 15 Mar 1999 19:49:04 -0500 From: Garance A Drosihn <drosih@rpi.edu> To: Richard Dawes <rdawes@ucsd.edu> Cc: freebsd-stable@FreeBSD.ORG Subject: Re: An Idea [was "What do people think of May 1st for a 3.2 release date?"] Message-ID: <v04011701b31356db5c7a@[128.113.24.47]> In-Reply-To: <Pine.SOL.3.96.990315114717.16819D-100000@huntington> References: <199903151103.AA17270@waltz.rahul.net>
next in thread | previous in thread | raw e-mail | index | archive | help
At 1:09 PM -0800 3/15/99, Richard J. Dawes wrote: > First, keep the longer release interval in place, whatever you > all think that should be (6 mos., a year, whatever). Then, simply > designate on a regular basis (monthly, bimonthly, whatever) some > source-snap to be an entirely unofficial subrelease (is > "point-release" the lingo?). It should probably be a couple weeks > old at least, one that seems to have the best combo. of bug fixes > vs. new bugs caused by them. A nice idea in theory, but in practice the logistics would probably be a bit problematic. > This way, the regular development cycle can be preserved. > Dummies (like me ;-), though, would have a means for being quite > reasonably sure that such "stable-snap" source would build into > a more stable system then what the last CD provides, and yet not > have to follow the day-to-day developments with freebsd-stable. A given snapshot may have the best combo of "bug fixes" vs "new bugs" in Jordan's opinion on Jordan's systems, but that isn't going to be much consolation to someone who blindly (ie, "without having to follow freebsd-stable"...) picks it up and is badly hit by one of those new bugs. One problem is that you're thinking of "stability" as a single value for all users, and that's not true. One snapshot may be "wonderfully stable" for single-CPU machines, for instance, but have a serious problem in it for multi-cpu configs. Or it would be great for everything except people using 'softupdates'. The difficultly is that you're hoping for something that someone can pick up and use without thinking too much about it. To do that requires some testing and legwork, and once you have the FreeBSD project doing that legwork then they might as well do the legwork for a real release. Just my opinion... --- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or drosih@rpi.edu Rensselaer Polytechnic Institute To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?v04011701b31356db5c7a>