Date: Sun, 17 Sep 1995 16:08:41 -0700 (PDT) From: "Rodney W. Grimes" <rgrimes@GndRsh.aac.dev.com> To: terry@lambert.org (Terry Lambert) Cc: 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: <199509172308.QAA03205@GndRsh.aac.dev.com> In-Reply-To: <199509172035.NAA06633@phaeton.artisoft.com> from "Terry Lambert" at Sep 17, 95 01:35:26 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > After a release based on a "stable" branch, all patches should be applied > to the next release, not to the stable branch post-release. > > The only exception to this should be a rerelease of the stable branch to > correct a gross error in usability (install, etc.). That would bump > the minor rev to 2.1.1 (for instance) and is only likely to be done in > the first little while after the release (perhaps as a way of tracking > release candidates?). > > The point being that once it is on CDROM, any subsequent changes should go > into a different branch tag and the branch tag of the RELEASE frozen. > > Period. It's *got* to be possible to recover the CDROM image from the > CVS tree. You should perhaps read more about cvs and go study the tags I have been placing in the tree. I can tag a branch at a state (and have for every single release we have ever rolled) that says this ``IS'' RELENG_2_1_0_RELEASE. I can commit onto the branch (RELENG_2_1_0) any time after that tag working towards RELENG_2_1_1_RELEASE and _still_ cvs co -rRELENG_2_1_0_RELEASE and get exactly what went onto CDROM. There are lots of good reasons to work on the RELENG_2_1_0 branch post release 2_1_0, say a CERT advisory comes out against 2.1.0, simply fix it in the branch, cvs rdiff -rRELENG_2_1_0_RELEASE -rRELENG_2_1_0 and send the patch out. RELENG_2_1_0 is a missnamed tag, it should just be RELENG_2_1 (this is a branch tag, not a state tag), but that is just a name, it has the correct function. > 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. I pushed a bit to get this branch stuff done, as it was pretty much what I have been doing in the commercial world of FreeBSD, I just moved it down to FreeFall so _every_ FreeBSD site could have the advantage that an AAC supported site does. My customers tend to land CERT advisories in my lap before I get them from other sources, they have people who keep an eye on that stuff, and these are _CRITICAL_ things to get fixed for many of them as there boxes are the outside internet visible flavor and holes must be plugged asap. > > 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). -- 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?199509172308.QAA03205>