ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!

[Christopher Schulte]

> -----Original Message-----
> From: owner-freebsd-stable at freebsd.org 
> [mailto:owner-freebsd-stable at freebsd.org] On Behalf Of Patrick J Okui
> Sent: Sunday, September 10, 2006 10:22 AM
> To: Karl Denninger
> Cc: freebsd-stable at freebsd.org
> Subject: Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
> 
> You can track changes to a particular release - say by using
> RELENG_6_1 rather than RELENG_6. In which case, would you 
> still say you are tracking STABLE?

Well, that depends.

For security and "critical fixes" (as the handbook phrases it) you can
track RELENG_6_1 (in the case of 6.1-RELEASE) and be happy.

But what happens if the needed fix isn't security or "critical" in the
minds of the FreeBSD developers?  At that point you either need to wait
for the next RELEASE, manually merge fixes into your production source
(which depending on the fix(s) could be non-trivial) or cross your
fingers and follow -STABLE.

This problem isn't specific to FreeBSD (or unix in general) by Any
means, of course.

Sure, we could broaden the scope of RELENG_X_Y.  Or introduce a new
branch that's closer to -STABLE yet tuned for something like, "security,
critical and major fixes" for production systems.  I'm not sure either
of those options are preferable, would be effective in alleviating the
problem, or even workable in the first place.

Personally, I've been served quite well for many years with the current
configuration.  Since I don't track -STABLE on anything important (or
more accurately have yet NEEDED to do so), I've never been hit by any of
these transient issues that crop up from time to time and can elicit
loud complaints.

--Chris