Date: Tue, 03 Oct 2000 18:03:37 -0700 From: Michael Bryan <fbsd-security@ursine.com> To: freebsd-security@FreeBSD.ORG Cc: cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: How long for -stable [ Re: cvs commit: src/usr.bin/finger finger.c ] Message-ID: <39DA81E9.FD461622@ursine.com> References: <paul@originative.co.uk> <84222.970618959@winston.osd.bsdi.com> <20001003173414.A58372@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Kris Kennaway wrote: > > On Tue, Oct 03, 2000 at 05:22:39PM -0700, Jordan Hubbard wrote: > > > I would therefore like to propose the following: We change the wording > > of our policy to state that upgrading to something within two releases > > of the "current -stable" product is the *recommended* action but that > > we will continue to provide, WHERE POSSIBLE, support for older > > branches of FreeBSD. We also stop telling people running 3.x (or I like this. A lot. > I suggest that in practise it will be all but impossible for people to > get active bugfix support for 3.x, and we'd probably be giving a false > impression if we say otherwise. > [...] > Speaking for myself as part of the security team, I don't want to > support 3.x for security fixes any more, since it's been just too damn > hard to do that over the past few months (i.e. in fact we havent been > providing good security support because developers aren't backporting > security fixes), and as warner pointed out we've now passed our "3 > releases along a branch" cutoff policy. Well, it's been said before, but I'll add my two cents to this. Support for at least security-related issues really needs to be provided for a reasonable duration, probably about a year, maybe longer, after a release comes out. Some production environments need (or at least strongly desire) this in order to more cautiously roll out full-on upgrades in a more planned mode of operation, where planning/testing/rollout can take many months, up to a significant part of a year. Shortcuts/quickfixes can be done in a more timely fashion when an urgent problem can be fixed with a relatively isolated patch or utility update, but that's frequently much harder to get approved when you're talking about a full upgrade that touches a lot more of the system. Having a cutoff based on number of releases just isn't realistic for the way a lot of production sites operate, not when the releases come out in relatively quick succession. 4.0 came out in March, and 4.1 in July. A lot of sites are hesitant to upgrade to any x.0 point release (whether or not FreeBSD warrants that caution is a separate issue, it -is- a real concern a lot of companies face and have been burned by.) So it's extremely unrealistic to tell them "Yes, you rolled out 3.5 in June when it first came out, but now you have to do a major upgrade to 4.x to get security fix 'foobar', even though your schedule for rollout says you were going to do it in November/December". :-/ If FreeBSD does -not- do this, I strongly feel that a lot of potential users of it will simply say "Sorry, we need at least one year of critical bug/security fix support on any given release tree, so we'll go with somebody who can give us that." I know this has been discussed before, but since Jordon has stepped up to the plate with what I think is an extremely realistic and workable framework for release support, I wanted to try to make sure that gets supported, and not shot down. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?39DA81E9.FD461622>