Date: Fri, 22 Jun 2001 11:38:06 -0500 From: Mike Meyer <mwm@mired.org> To: Dmitry Karasik <dmitry@karasik.eu.org> Cc: freebsd-stable@freebsd.org Subject: Re: Staying *really stable* in FreeBSD Message-ID: <15155.29806.145760.832648@guru.mired.org> In-Reply-To: <uae30frqk.fsf@karasik.eu.org> References: <JBEOKPCEMKJLMJAKBECCEEMDDBAA.jwatkins@firstplan.com> <uae30frqk.fsf@karasik.eu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Dmitry Karasik <dmitry@karasik.eu.org> 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. <mike -- Mike Meyer <mwm@mired.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?15155.29806.145760.832648>