Date: Mon, 18 Sep 1995 12:14:16 -0700 (PDT) From: "Rodney W. Grimes" <rgrimes@GndRsh.aac.dev.com> To: paul@freebsd.org Cc: 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: <199509181914.MAA04387@GndRsh.aac.dev.com> In-Reply-To: <199509181403.PAA14538@server.netcraft.co.uk> from "Paul Richards" at Sep 18, 95 03:03:39 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. How about some definitions.... FreeBSD Project: a large mass of folks working on FreeBSD, usually as groups of people called ``teams''. FreeBSD release team: The small group of folks working on producing releases. FreeBSD maintainance team: A non existent group of folks working on fixing critical bugs in the last release, things that create CERT advisories should be fixed by these folks, and releases as a .x point release(s) to all proir production releases created by the ``release team''. This team must have conservative views as to what is a ``fix'' to a realease, and what is a ``new feature''. Major rewrites of code to fix a bug should not be considered by them. Fixing off_t in src/sbin/dump should for all releases lower than 2.1, as should fixing security holes in sendmail on all prior releases to 2.1. My estimate for man power needed here is <8 hours per week, which is about what I spend on doing similiar things for existing customers. FreeBSD developement team: The largest group of folks working on FreeBSD, these are the people who lay down major new functionality and rework code so that it works the ``right way'' for future releases. > 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. > 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 provoding this work back to the project for free, but that may be cutting my own throat with respect to why should we pay Accurate Automation for this work when it just turns around and gives it away. Well, I have a simple answer for that, if no one pays me to do it I ain't going to do it at all. Simple business folks, yes, I am now fully in the Commercial FreeBSD business, work won't come from me on this project unless someone is footing the bill to have me do it, I simply no longer have the time to give away massive numbers of my hours :-(. > 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. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199509181914.MAA04387>