Date: Mon, 12 Jun 1995 11:41:40 -0700 (PDT) From: "Rodney W. Grimes" <rgrimes@gndrsh.aac.dev.com> To: dufault@hda.com (Peter Dufault) Cc: FreeBSD-current@FreeBSD.ORG (FreeBSD current) Subject: Re: CVS and FreeBSD 2.0.5/2.1/2.2 Message-ID: <199506121841.LAA02608@gndrsh.aac.dev.com> In-Reply-To: <199506121818.OAA00342@hda.com> from "Peter Dufault" at Jun 12, 95 02:18:02 pm
next in thread | previous in thread | raw e-mail | index | archive | help
[Put back on the mailling lists...] > > Rodney W. Grimes writes: > This sounds good. I only have two concerns: > > 1. 2.1 "stable" will be under-tested, since the split will be > between 2.05R and -current, and not enough sites will be running > -stable. Will -stable will be the main branch you try to steer > random internet users to and not 2.05R? Not ``random internet users'', there have been many requests for something between RELEASE and CURRENT. Stable will be basically the last release + critical bug fixes. 2.1 is going to be 2.0.5R + what ever CRITICAL bug fixes David gets done between now and when he says it is done. > If we set up a formal > release mechanism similar to the snapshots HD can run those releases > on Greg's system. This presumes running -stable will be fairly > low risk. That is the idea, for most folks sticking to RELEASE for mission critical systems has left them wanting some of the more critical bug fixes, but not wanting to risk jumping up to -current. We will walk -stable down a fine line between the last full release and current developement work only putting the critical bug fixes into it. > 2. I won't have space for both a 2.1 tree (I know I can't commit > to it but I could prepare fixes if someone submitted a bug) and > -current, I'll stick to -current. Submitting fixes will be more > time consuming unless they happen to match -current. Submit them against -current, it will take the release engineering team to pull these changes from -current into -stable. Since we all have the cvs bits on our boxes we can produce the needed -stable diff pretty quickly if there is a conflict. This also gives the release team a little more control over the next release without slowing down developement. Look at it this way, after today we will begin the testing of 2.1A as that is now the branch!! > Anyway, it sounds like a good plan so we'll see how it works out > in practice. Yep, live and learn... the release team is going to have to pick up a few cvs tricks to learn to deal with this better, but that is a small price to pay for what it should gain us. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Custom computers for FreeBSD
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199506121841.LAA02608>