Date: Sun, 17 Sep 1995 19:44:12 +0100 (BST) From: Paul Richards <paul@netcraft.co.uk> To: jkh@time.cdrom.com (Jordan K. Hubbard) Cc: paul@FreeBSD.org, gibbs@freefall.freebsd.org, pete@sms.fi, davidg@Root.COM, current@FreeBSD.org Subject: Re: Which SUP files are available and where ? Message-ID: <199509171844.TAA04538@server.netcraft.co.uk> In-Reply-To: <21364.811354478@time.cdrom.com> from "Jordan K. Hubbard" at Sep 17, 95 09:14:38 am
next in thread | previous in thread | raw e-mail | index | archive | help
In reply to Jordan K. Hubbard who said > > > 2.1 should get abandoned immediately with the exception that a truly killer > > bug that is so bad that people can't just work around it until the next relea > se > > may get fixed with a 2.1.1 update. > > This seems contradictory. If 2.1 is "abandoned" then where does 2.1.1 > come from? > > I think it goes without saying that 2.1 will have problems which could > be fixed in a 2.1.1 and that people will strongly urge us to do so. > We *always* have problems with each release. It's a truism. > > > There should be a freeze date on 2.2 when no more experimental or major > > changes are made and after a brief period, say a week or two to make sure it' > s > > basically safe, it should move over to the stable branch. Once 2.1 is out tha > > That sounds OK in theory, but it both assumes that 2.2 is going to be > ready in a timeframe congruent with when people are expecting "their > bugs to be fixed" and that those bugs *will* be fixed in 2.2. Some > 3-5 months after 2.1 we WILL be sitting on a list of problems that > people are getting impatient with and it will be no trivial matter to > just assume that 2.2 will fill the bill. I see experimental changes > going into there for awhile yet, and that doesn't translate to the > kind of "incrementally debugged" release that 2.1.1 would represent. > Well, we're just never going to agree on a release strategy. Who's going to be maintaing 2.1? There may well be a long list of bugs that have surfaced in 2.1 but you're going to have to sit down and work out solutions for most of them independantly of current since it's almost always the case that the bugs we find these days are conceptual problems that are fixed by completely redesigning portions of the system. It's certainly never been easy in the past to retrofit fixes in current to older releases for this very reason. 2 releases a year is probably enough. People just don't want to upgrade much more often than that. 6 months should be more than enough time to get all but the most uncommon bugs out of a release. The problem has always been in the past that no-one is willing to clamp down on current and if people are stilling adding experimental code in 3-5 moths then it'll never converge to a stable state. If we could stick to a 6 month release cycle then there'd be no need for a 2.1.1 release, and if the 6 months is used to properly test the next release then there wouldn't be the continual screw-ups that require point release days after the cdrom ships. As long as the actual task of cutting the cdrom doesn't introduce any bugs then I doubt that 2.1 will have any serious bugs that *require* a point release, since this is the first release in a long time that's had a decent period of testing. If there are no serious bugs then people can wait 6 months until the next release. Would a 2.1.1 release go through the same vigourous testing as 2.1 did, if not I wouldn't consider it an upgrade. Having the ability to do a 2.1.1 release is good, if there are serious bugs we have the ability to fix them but you seem to be suggesting that we continue to work on a 2.1.1 branch while we wait for current to stabilise I wouldn't consider that a very sane idea. -- Paul Richards, Netcraft Ltd. Internet: paul@netcraft.co.uk, http://www.netcraft.co.uk Phone: 0370 462071 (Mobile), +44 1225 447500 (work)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199509171844.TAA04538>