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>