From owner-freebsd-stable Fri Jun 22 9:38:16 2001 Delivered-To: freebsd-stable@freebsd.org Received: from guru.mired.org (okc-27-141-144.mmcable.com [24.27.141.144]) by hub.freebsd.org (Postfix) with SMTP id 0EFE537B407 for ; Fri, 22 Jun 2001 09:38:07 -0700 (PDT) (envelope-from mwm@mired.org) Received: (qmail 74831 invoked by uid 100); 22 Jun 2001 16:38:06 -0000 From: Mike Meyer MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15155.29806.145760.832648@guru.mired.org> Date: Fri, 22 Jun 2001 11:38:06 -0500 To: Dmitry Karasik Cc: freebsd-stable@freebsd.org Subject: Re: Staying *really stable* in FreeBSD In-Reply-To: References: X-Mailer: VM 6.90 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid X-face: "5Mnwy%?j>IIV\)A=):rjWL~NB2aH[}Yq8Z=u~vJ`"(,&SiLvbbz2W`;h9L,Yg`+vb1>RG% *h+%X^n0EZd>TM8_IB;a8F?(Fb"lw'IgCoyM.[Lg#r\ Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Dmitry Karasik types: > On 21 Jun 01 at 16:45, "Jason" (Jason Watkins) wrote: > Jason> Don't camoflage one problem by providing a solution to > Jason> another. What you're really worried about is how stable -stable > Jason> is. Address that, and things will be better than managing: > > Jason> -its_not_stable_but_we_pretend -stable -yet_more_stable > Jason> -so_stable_its_more_stale_than_the_cheesewiz_in_my_house > Well, instead of criticizing the only decent proposition in the thread > you all people could invent something that works. But no one wants to, > that's the point. If it were a decent proposition, it wouldn't be drawing criticism. What we have is a system that works, in the form of CURRENT, STABLE and RELEASE. We also have a new facility in the form of a branch that inludes only security fixes from STABLE - something I'm going to call RELENG. RELENG was introduced with the previous release, and we now have a proposition designed to work around the "problem" of having to edit the supfile to change to a new branch after a release. This is exactly the way things have worked with STABLE, and I've never seen anyone claim that that was a problem. Since this case has never happened, any problems are hypothetical. The relevant experience with FreeBSD is that: 1) Editing the supfile is trivial, and seldom causes problems. 2) Tracking STABLE at "reasonable" intervals is straightforward, and seldom causes problems. 3) Jumps of a release are slightly more complicated, sometimes cause problems, and should be handled with care. 4) Jumps across versions are a major PITA, and almost always have to be given special treatment. RELENG is an attempt to make life easier for people who don't want to upgrade their system, but do want to get security fixes. Given that goal and the relevant experience, RELENG seems to be a good solution. It may not be, but we really need some evidence before making such a decision. So we have a proposition that moves the work from people who want to track stable in a manner resembling the punctuated equilibrium theory of evolution to the release engineer - who is a volunteer - to solve a problem that has never been observed in the wild. Before doing any work to fix this problem, it would be nice to have some evidence that this problem exists, and to have more experience with the process of taking a system from one RELENG branch to the next one. If the problem is instead that STABLE isn't STABLE enough and RELENG doesn't move fast enough - though evidence for the latter would also seem to be in short supply - then one of those two problems should be attacked, rather than trying to automate something that experience shows doesn't automate well. http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message