@jrhett: "I'm going to be offline for a week starting now, so please don't read  
my lack of answers as anything other than "out of town".  Sorry.
For clarity:  I'm not asking for anyone to fix anything.  I honestly  
believe most developers are addressing problems as fast as they can.   
I'd help them in any way I could.
I am suggesting that given that the current bug list for 6.3-RELEASE  
is both (a) too large and (b) breaks things that work fine in 6.2 ...  
that I think pushing 6.2 (the real stable release) into EoL is a bit  
rushed.  I sympathize with the development costs of maintaining old  
versions.  Again, I will help in any way I can.
On my return next week I would happily build and provide 6.3-RELEASE  
systems for any developer who needs a test environment for reported  
bugs that affect hardware I have in my possession.  Free boxes, free  
bandwidth, power, etc.  No problem.  Free my time in whatever way I  
can help.
But until such time as the current bug list for 6.3 hardware reduces  
to somewhere less than 100% likelyhood of experiencing failures after  
an upgrade, there's just no way I can take our production environment  
forward.  Going "bravely forward" to guaranteed failure isn't a great  
way to enjoy your job :-(  Which means I'll be doing our security  
patches by hand.   Because it may be time intensive, but it's less  
likely to cause a production failure.
Jo Rhett
Net Consonance : consonant endings by net philanthropy, open source  
and other randomness"
    @andykosela: "<quote>
This whole discussion is really interesting as it clearly showcases two
common trends in computing (rapid development vs stability) On the one
side we got people (let's call them developers or computer scientists)
who are more interested in development than stabilization of the existing
code base. It's natural for them to think more about new features,
researching new ideas and implementing them. It resembles an
academic project, research project.Those computer scientists do not
care much about stability, they are mainly interested in hacking on the
code for the fun of it. It is open source after all as someone wisely
remarked. From my own experience most if not all community based
projects are more interested in following this trend than stabilization of
the code. Although they do care about stability of their code base, their
focus is more on implementing new features and moving rapidly forward.
In today's quickly changing world we see this trend as prevailing.
On the other hand though, there is a trend which focuses on maximum
long term stabilization of the code base. Usually we see this trend in high
end commercial companies serving the needs of mission critical
businesses where even a minute of downtime can cause loss of
thousands of dollars or even loss of lives of people (imagine stock
exchanges, banks, financial & insurance institutions, army and police
facilities, hospitals, nuclear plants etc.). Those types of
businesses/institutions truly needs a maximum stable operating system.
They really do not care about "new features", but they do care about
maximum stability of the existing code, security, and nonstop business
continuity even in the face of natural disasters. There is only one operating
system I know of that survived 9/11 attacks - this is OpenVMS.
It's not uncommon to see VMS uptimes of more than 10 years (you can ask
Amsterdam police for evidence). Now that is a true stability! On the other
note though, stability is the direct opposition of development and change.
Something which is *stable* cannot change or must change very slowly in
the long term. On the other hand something which is changing rapidly cannot
by the very definition of it be stable but rather is...unstable. Plato said it
very wisely in Timaeus: "What is that which always is and has no becoming;
and what is that which is always becoming and never is?". In other words
one could say - what is that which is always the same and stable and what
is that which is always changing and is unstable? This elaborate thinking
is directly connected even with the trends in todays computing. When the
code base is changing rapidly and quickly you cannot say it's very stable.
Something stable is always something heavy tested and unchanging.
So on the one hand we got users like Jo who wants long term stabilization,
who depends on FreeBSD to run their mission critical systems, and on the
other the developers who are more interested in the *development* than
maintaining and supporting older releases for many years. I got to agree
with the developers -this is open source project with limited resources. In
order to offer long term support the whole focus of the project would have
to be changed - and you can't force people to do something they don't want
to do in the open source world.
It's more fun to work on implementing new code, than squashing bugs or
fanatically audit the code in search of security flaws in old releases. The
open source is moving very rapidly forward and it's not only FreeBSD. castillolatasha@example.org. There is more than 10,000 messages each month on LKML.
Kernel.org peoples also do not care much about stability (recent problems
with vanilla kernels do support my thesis) - they commit so fast and massively
that it becomes real hard to maintain this "beast" even for seasoned hackers.
But someone who is sane will not be using kernel.org kernels in mission critical
production environments but rather commercial distro kernels like Red Hat's
versions. Also they won't be using 8-CURRENT on production systems either.
Those are more research projects than operating environments for data
centers. But when Red Hat is taking kernel.org kernel and put it out as part
of their distro they give 7 (read: seven) years support for that particular
kernel, userland and any third party application they support. They backport
all security and bug fixes to the "so called" stable release during those seven
years. That is a long time in the open source world, as in the general
computing world. They can do this because they have resources for
that - they are operating as a commercial company.
In FreeBSD even if you upgraded cleanly base system (this is very easy
and fast now with freebsd-update(8)) there is always problem with ports.
I'm perfectly aware that developers are more focused on the base system
and ports are served on "as is" basis but most of the production systems
deployed worldwide are using ports and depends on them most of their time.
I also understand ports team in saying that there is no resources to have
many branches of ports tree at the same time, but this little example will
show that in the long term sometimes things are not working very smoothly
for people who are running mission critical systems. Let's say some
hypothetical 6.x-RELEASE comes out in January. The Apache port is
freezed at hypothetical 2.0.40 version. Now in April someone discloses
some very critical security flaw which affects all versions of Apache prior
to 2.0.43. Now what you can do? You can update your Apache port to
2.0.43 fixing a security hole. But at the same time you don't know the
upstream team changed dramatically some internal things in code, added
tons of new features and at the same time introduced a ton of new bugs
and possibly new security flaws which will be founded at a later time.
Those changes in code can also very well break your applications which
depended on the specific code in 2.0.40 version. So you are left with
headaches and backup tapes (of course you would first test the upgrade
process on the test machines). But my issue here is that ports really do
not offer real stability for mission critical systems who often depends for
years on specific versions of particular software (like banks). Red Hat in
that case backports new security patches to those old stable versions and
it seems it is some solution for such businesses. Of course I know there is
no resources for creating supported -SECURITY branch of ports tree which
would backport those patches.
FreeBSD has always been known for its legendary stability and mature
code base which is why many commercial companies depend on it every
day. "The anomaly" as someone said of long term support for 4.x releases
only helped to see FreeBSD as more stable and viable solution than Linux by
many businesses. Mission critical systems needs long term support (read: at
least backporting security patches) and stable systems that can run for years
without interruption. When it comes to stability vs development maybe there is
time to rethink FreeBSD overall strategy and goals. Major companies using
FreeBSD in their infrastructure like Yahoo! or Juniper Networks would
definetly benefit from such moves focused on long term support of stable
releases. I honestly think it is in their interest to support, even financially
Andy Kosela
ora et labora"
    @talon: "... a really beutiful and elaborate post on the subject ...
However, being an ordinary user with few machines running FreeBSD, i
have seen on my limited sample that 2 machines worked better with 6.3
than 6.2 (two old Athlon machines, which work perfectly OK in fact) and
one worked much worse (a P4 which used to be perfectly stable and
suddenly panicked 3 times in a week). So i upgraded this last one to 7.0
and it is now working perfectly well without any trouble. The only
"gotcha" is the slowness of X problem when compiling, but i live with that.
Moral of the story: the developer base of FreeBSD is not large enough to
maintain a large number of releases. In my humble opinion, having 8.0
7.0 and 6.* is even too much. The developers are working on 8.0, they
still have a very good grasp of 7.0 but 6.* becomes old stuff, more or
less forgotten. It then occurs that things are merged to the 6.* branch
which are perhaps susceptible of destabilising it. Personnally i have
seen the same occurring with 6.0, 5.0 and 4.*, for me the last releases
of the 4.* were very poor on my laptop while the early 4.* releases were
perfectly OK.  
I think it is very unreasonable for end users to ask maintaining, e.g.
6.2 ad vitam eternam. The real stable branch is now 7.* and diverting
effort to polish the 6.* is a waste of time. People wanting a very
stable system should simply use something else, like Debian stable,
official RedHat, etc. whose aim is precisely to offer the maximum
stability, with only security and bug fixes, and for extended periods of
time. The price you pay is obsoleted and "unsexy" systems, which is
probably OK for the intended use. On the other hand i have no business
running such a system.
Michel TALON"
{'source': 'USENET', 'other_information': '{"reply_count": 2, "forum_name": "lucky.freebsd.stable.20140829.mbox"}', 'file': 'data/output/usenet-lucky.freebsd.parquet'}