Dmitry Karasik <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message
