Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 18 Sep 1995 20:42:31 +0100 (BST)
From:      Paul Richards <paul@netcraft.co.uk>
To:        rgrimes@GndRsh.aac.dev.com (Rodney W. Grimes)
Cc:        paul@freebsd.org, terry@lambert.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:  <199509181942.UAA20900@server.netcraft.co.uk>
In-Reply-To: <199509181914.MAA04387@GndRsh.aac.dev.com> from "Rodney W. Grimes" at Sep 18, 95 12:14:16 pm

next in thread | previous in thread | raw e-mail | index | archive | help
In reply to Rodney W. Grimes who said
> 
> > I agree with Terry that for
> > your average FreeBSD user, saying it's fixed in the next release is
> > good enough.
> > 
> 
> Well, maybe you should step back and take a closer look as to what some
> of our ``average FreeBSD users'' are doing with FreeBSD.  Believe it or
> not FreeBSD is becomeing very large in the ISP market segment, these
> people _must_ have security related bugs fixes in a rapid manner, and
> infact many of them have there own full time staff to make _sure_ they
> have these fixes in place.  That is a lot of resource that could be pulled
> into a cooperative effort to create this ``maintaninance team'', and these
> people tend to be very conservative about doing anything that could degrade
> there systems.

Well, I'd disagree about numbers but I appreciate their importance.
I agree 100% that there needs to be a group to deal with this side
of things but I think the current FreeBSD project is not capable
of dealing with such issues. There need to be an bodies that
deal with support but not the current setup.

> 
> > 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.
> 
> Simple for me, I shadow off a repository after the release tag and do
> all my customer support work in there.  I am willing to think about

Yeah well, that's what I meant. You and I have access to the repository
but your average company that might want to offer support doesn't. That's
probably good since the core team would then have to decide whether a
particular group or company should be given access to "internal" project
information.

I think various things external to the "core" of the project, like
support companies popping up, will mean these issues will have to be looked
at soon.

> > 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.
> 
> Point well made, but I think being in a ``maintainance mode'' after a release
> fully knowing that 2.2 is coming will help curtail a lot of the ``pull the
> latest wizzy wig into the branch'' problem that has pleagued the release
> person or team over the years.  People won't be pusing to get stuff into
> the maintainance branch, they will be pusing to get things into the next
> release branch, thus eliminating a lot of the problem.  

I honestly doubt it. We'll just have another 2.0.5 scenario, where decisions
are made to make a "bug fix only" interim release because current isn't
stable enough yet and instead of a bug-fix release it turns into a full
featured re-write, delaying 2.1 probably by 6 months.

This is exactly what I fear 2.1.1 would be.

-- 
  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?199509181942.UAA20900>