challenge: end of life for 6.2 is premature with buggy 6.3

Greg Byshenk freebsd at byshenk.net
Sun Jun 8 11:37:05 UTC 2008


On Sat, Jun 07, 2008 at 03:11:42PM -0700, Jo Rhett wrote:
> On Jun 7, 2008, at 1:44 PM, Patrick M. Hausen wrote:
 
> >>This is why EoLing 6.2 and forcing people to upgrade to a release
> >>with lots of known issues is a problem.

> >People who have issues with RELENG_6_3 should upgrade to RELENG_6
> >which is perfectly supported.
 
> I'm sorry, but you clearly don't run RELENG_6 on anything.  I run it  
> on two home computers, and grabbing it on any given day and trying to  
> run with it in production is insanity.  Lots and lots of things are  
> committed, reverted, recommitted, reverted and then finally  
> redesigned.  Each of those steps are often committed to the source  
> tree.  The -RELEASE versions prevent this kind of insanity.

I can't speak for Patrick, but I can ad that I very definitely _do_
run RELENG_6 on ~40 machines (web, mail, file, and applications
servers), and do so without any serious problems. Which is not to say
that there are never problems, but that when there have been problems,
they have been uncovered during testing.

Of course it is true that "grabbing" something and "trying to run
with it in production is insanity". But this (at least IMO) has
nothing at all to do with RELENG_X _per_ _se_, as it applies equally
to X-RELEASE, and also to any production systems running any other OS.
Before we roll out a new RELENG_6 build, we test it first to discover
any potential problems -- but this is standard practice for
_everything_ that goes into production, including changes to Linux,
Solaris, and Windows systems, and also changes to samba, apache, or any
other software running on the systems.  My point here is that it is the
"grabbing" something and throwing it into production without testing
that is "insanity", and that this has nothing specifically to do with
RELENG_6.

I might also add that I have machines that "grab" (actually, pretty 
much randomly -- that is, "on a given day" and without particular 
concern from me) RELENG_6 and RELENG_7, and even these machines very
rarely exhibit any problems. Of course, these are just test machines,
and without the full pre-production testing it is possible that there
are some problems in these cases that just don't manifest themselves,
but my experience (and, I suspect, that of many others) indicates that
your description of RELENG_6 as a seething cauldron of uncertainty is
inaccurate. 


> I'm struggling to find a phrase here that can't be taken to be an  
> insult, so forgive me and try to understand when I say that you really  
> should try watching the cvs tree for a bit before making a nonsense  
> comment like that.

You don't seem to have struggled very hard. After all, you could have
mad the same point by noting that you consider it a mistake to run
RELENG_6 in production. And by not doing this, you have undermined
your own position, as it seems clear that there are _many_ people and
organizations who run RELENG_6 in production (by which I mean, some
version of RELENG_6, and not the tracking of daily changes to RELENG_6),
which means that your assertion that such is "nonsense" is itself
mistaken.

Somewhat more generally, this sort of thing may be why you are getting
the amount of push-back you see. That is, what you are claiming seems
to match the experience of few (if any) others.  As you may have
noticed from this thread, the general view (a consensus, seemingly,
apart from yourself) is that 6.3 is _better_ (more stable, etc.) than
6.2.  Given that such is the case (as it seems very much to be), then
the response to your statement that 6.3 isn't good enough of "what 
exactly is wrong?" seems (at least to me) to be entirely reasonable.
When one of my people comes to me and says that something is wrong with
X (and particularly when my experience is that there is nothing wrong
with X), my first response is almost invariably:  "what, specifically,
is wrong with X?"


-- 
greg byshenk  -  gbyshenk at byshenk.net  -  Leiden, NL


More information about the freebsd-stable mailing list