From owner-freebsd-current Mon Sep 18 07:05:25 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA16767 for current-outgoing; Mon, 18 Sep 1995 07:05:25 -0700 Received: from server.netcraft.co.uk (server.netcraft.co.uk [194.72.238.2]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id HAA16758 ; Mon, 18 Sep 1995 07:05:18 -0700 Received: (from paul@localhost) by server.netcraft.co.uk (8.6.11/8.6.9) id PAA14538; Mon, 18 Sep 1995 15:03:40 +0100 From: Paul Richards Message-Id: <199509181403.PAA14538@server.netcraft.co.uk> Subject: Re: Which SUP files are available and where ? To: rgrimes@GndRsh.aac.dev.com (Rodney W. Grimes) Date: Mon, 18 Sep 1995 15:03:39 +0100 (BST) Cc: terry@lambert.org, paul@FreeBSD.ORG, jkh@time.cdrom.com, gibbs@freefall.freebsd.org, pete@sms.fi, davidg@Root.COM, current@FreeBSD.ORG In-Reply-To: <199509172308.QAA03205@GndRsh.aac.dev.com> from "Rodney W. Grimes" at Sep 17, 95 04:08:41 pm Reply-to: paul@FreeBSD.ORG X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 3435 Sender: owner-current@FreeBSD.ORG Precedence: bulk In reply to Rodney W. Grimes who said > > > After a release there is no "ongoing maintenance" only "new release work". > > Wrong, that is one place FreeBSD has surely lacked in being of ``commercial'' > quality. I still have support contracts with customers running 1.1.5.1 and > I have rolled my own ``update'' kits that include things like the CERT > fixes for sendmail, CERT fixes for libskey, CERT fixes for BIND, etc... > My customers pay me dearly for this, but are quite glad to know they can > come to me and get this type of stuff fixed. FreeBSD, can now, and should > start to provide these on its own. Well I agree in one sense but not another. I don't think the "FreeBSD team" is in the business of providing support. I think it should concentrate on getting the development work done so I don't want to see that effort diverted to maintaing previous releases except in exceptional cases where serious bugs slipped through. I agree with Terry that for your average FreeBSD user, saying it's fixed in the next release is good enough. Now, where I agree is that there are oppurtunities to offer FreeBSD on a more serious level, where companies pay decent bucks for ongoing support contracts. Providing the mechanism to make this possible is a good thing although it raises more complex issues relating to who has access to the repository and so forth. I should perhaps clarify that the two roles overlap, I'd expect that individual from the "FreeBSD team" would be the one's dealing with support but the abstract entity "FreeBSD team" should be in the business of getting the next release done and not worry about retrofitting various bug fixes into releases that are long gone. There simply aren't the resources to do so. A point release takes the same amount of effort to push out the door as a completely new release, if it's treated with the same level of seriousness. > > This has to be true because the work that went into making the "stable" > > branch "stable" in the first place can not be duplicated in the rolling > > in of a quick patch. By doing ongoing maintenance without equivalently > > long cycle times, you compromise the meaning of the "stable" tag. > > Not if you only fix _CRITICAL_ bugs, and do complete testing of the fix > before you intergrate it. This is no different that what is being done > to _create_ the 2.1 release as a stabalized release. IMHO, a little too > much is coming over, but it is not my *ss on the line if it blows up so > I will defer that judgement to those who are doing the work (and it is > work, and it is a judgement call). I agree with these points, if only critical fixes are done then this is basically what I'm in favour of but I know from experience that not enough restraint is exercised during the release process and that too many things get unecessarily upgraded or enhanced because they seem safe enough or individuals just decide that bits aren't presentable enough and start re-writing them and a 2.1.1 on that basis would be unreliable and would detract from development on -current, which is where such things should take place anyway. 2.1 is likely to be our most stable release for a while because controls have been placed on it and it has been in that "controlled" state for quite a while. -- Paul Richards, Netcraft Ltd. Internet: paul@netcraft.co.uk, http://www.netcraft.co.uk Phone: 0370 462071 (Mobile), +44 1225 447500 (work)