Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 18 Sep 1995 15:03:39 +0100 (BST)
From:      Paul Richards <paul@netcraft.co.uk>
To:        rgrimes@GndRsh.aac.dev.com (Rodney W. Grimes)
Cc:        terry@lambert.org, paul@FreeBSD.ORG, jkh@time.cdrom.com, gibbs@freefall.freebsd.org, pete@sms.fi, davidg@Root.COM, current@FreeBSD.ORG
Subject:   Re: Which SUP files are available and where ?
Message-ID:  <199509181403.PAA14538@server.netcraft.co.uk>
In-Reply-To: <199509172308.QAA03205@GndRsh.aac.dev.com> from "Rodney W. Grimes" at Sep 17, 95 04:08:41 pm

next in thread | previous in thread | raw e-mail | index | archive | help
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)



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199509181403.PAA14538>