Date: Tue, 03 Sep 1996 08:32:04 -0700 From: "Jordan K. Hubbard" <jkh@time.cdrom.com> To: rkw@dataplex.net (Richard Wackerbarth) Cc: current@freebsd.org Subject: Re: Food for thought Message-ID: <9738.841764724@time.cdrom.com> In-Reply-To: Your message of "Tue, 03 Sep 1996 07:59:17 CDT." <v02140b05ae51d3bdc27e@[208.2.87.4]>
next in thread | previous in thread | raw e-mail | index | archive | help
> There are a few policies that I think lead to some of the problem. I agree that most of these things are true problems, though I'm not sure they all point back to the same common solution. More specifically: > 1) Although I like the idea that "current" is readily available, forcing > new development to be done against it leads, IMHO, to making people use > something which is more unstable than what they need or desire. The You have this inverted. New development has to go somewhere, it not being a question of "forcing" anything, and it's the *inappropriate* use of -current by some which is the real problem. In that we're not providing them with an alternative other than the previous release, I suppose it could be said that we are "making people use something which use more unstable ...", but even the answer there is not to alter -current, it's to offer the new "metered -current" service I proposed at the beginning of this whole thread. > 2) The relative reluctance to attempt to support "released" systems. There > appears to be an attitude of "shipped and forgotten". Not in this neck of the woods, they're not. I spend most of my tech support work dealing with the most recent release, as do quite a few others. Nobody I know on the core team takes this attitude, that's for sure. > 3) The extremely short test cycle for new releases. IMHO, we should already > have a feature freeze for 2.2 and the leading edge should be planning for > 2.3. While I agree that some of the recent "test cycles" were too short, each feature freeze date is something that has to be derived more from instinct than formula. Again, these are volunteers here and they work in ways different than what you'd typically expect from a paid development team. During feature freezes, when work is constrained to relatively boring stuff, the pace and scale of contributions slows down comeasurately. There's a certain point where the lines cross on the graph and beyond you could have a 6 month freeze, but only 4 changes would be committed during that time and most of the active development projects mysteriously abandoned. Flexibility is sometimes more important than a rigid release ideology if you want to keep having releases in another year's time. > 4) It's too hard for the "average Joe" to isolate various parallel > developments. Often the "unbuildability" of current bounces from one camp Exactly, which is why the average Joe should stick with the latest -release and wait for us to get our acts together on implementing a system for getting only critical bug fixes to him. > 5) Unfortunately, only a few of us can afford to have spare machines to > "burn" on instability. How often do we see somebody limping along without > adequate HD? Thankfully rather less often since 2Gb SCSI drives fell through the $400 mark. Jordan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9738.841764724>