Garance A Drosihn napsal/wrote, On 10/11/06 21:33:
Even if no new ports will be compilable on 4.x, even if the
old ports will not be updated with exception of update caused by
security bug, I vote for delaying EOL of 4.11
That's easy to say.
I understand that it's much more work than just "you are on your own -
EOL arrived".
As I'm not commiter, I'm allowed to submit PR and speak. I'm trying
both. This letter is "speak" part.
You can't just keep voting to say "support me forever", and have it
cost nothing. Someone, somewhere, has to put up the time and effort
to actually do that support. And realistically, that someone has to
be the people who are actively running 4.x. Me, I have no desire to
run 4.x. I have become too accustomed to a variety of nice features
which are in 6.x. I'm also in the process of replacing two of my PC's
(because they are having hardware trouble), and once I do that I only
have one PC which will even bootup in 4.x -- and that is a 10-year-old
PC which I hope to replace before the end of the year.
I never call for "support forever". In advance, I didn't accept other's
"I has old hardware, unsupported by 6.x' as strong argument for delaying
of EOL. It's about money only and if you run important production
server, you should be able to obtain money for it's upgrade.
Problem is performance and trust in stability. It's money and hardware
independent problem.
5.x has significant performance hit, so we can't count it as
competitive replacement for 4.x. 6.1 is second release in 6.x tree. 6.0
has stability problem. The 6.1 is sufficiently stable on average use,
but it still has problems in edge situations. The 6.2 become first
RELEASE in 6.x tree acceptable for serious production use. 6.3 will be
candidate for first trustable RELEASE if there will not be significant
problem with 6.2. It's nothing special on major version changes - 3.0
has been buggy, 4.0 has been buggy, 5.0 has been almost unusable. It's
common for other systems also - first usable release of Novell Netware
in 3.x tree has been 3.11 (after buggy 3.0 and 3.1), but stable release
has been 3.12 for example.
At this time, there are about 224 unclosed PRs related to kern/6.x tree
older than three month, 192 of them are untouched (eg. in plain open
state). Nobody knows they are reporting serious problem or they are
reports of nonexistent problems and they are a sort bug of submitter or
hardware or so. IMHO, commiters are hard working on implementing new
features, but has no spare time to polish and repair older parts of code.
So, at the time of EOL of well tested, fast and stable version we have
the only so-so trustable release as replacement. Despite of a money
spent to modern hardware. It's just not so good news. Nothing more. I
understand that FreeBSD is volunteer based project so nobody can push a
commiter to prefer polishing previously implemented features against
implementing new toys. Nobody can force release team to postpone next
RELEASE until previously reported problems are analysed and resolved or
denied (at least most of them).
I respect you are upgrading to 6.x because of nice features which you
need. But I need none of it on most of our infrastructure server
(including those routing to network with more than thousand computer).
In the fact, I'm using IPFW2 only and it's available on 4.11 as well, so
no reason for 6.x for routers, firewals DNS servers. I prefer
performance and stability over new features (it's main reason we
selected FreeBSD instead of Linux as main platform for our networks ten
years ago).
Well. I'm hesitate that my doubt about stability and performance of
current and next 6.x release will not make so much friends for me there.
So, no more words with exception of "thank you" for all volunteers. I'm
sure they do the best they can.
If I can say my humble opinion with no further explanation - the
optimal EOL for 4.11 I see about three months after 6.4-RELEASE. Three
months after 6.3-RELEASE is worse but still acceptable.
It's my $0.02
Dan
P.S. Please note the english isn't my native language.
--
Dan Lukes SISAL MFF UK
AKA: [EMAIL PROTECTED], [EMAIL PROTECTED],[EMAIL PROTECTED]
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"