Re: CLARITY re: challenge: end of life for 6.2 is premature with buggy6.3

Picking one of the many posts from the OP in this thread...

On Wed, 04 Jun 2008, 22:33 -0700, Jo Rhett wrote:
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.

It seems to me that the underlying grievance may be lack of faith in the
latest RELEASEs; promtping the suggestion that $FAVOURITE_RELEASE support be
extended.

I believe that the best way to acquire confidence in the FreeBSD RELEASEs is
to participate in the release cycles. Those of us who are not developers can
make a significant contribution by taking the time to build the BETA and RC
builds on our own systems with our own peculiar mix of CPU's, motherboards
and peripherals. If we find problems we can feed them back to the team and
improve the quality of the release; and then we'll be confident about
deploying RELEASE on our systems rather than regarding it with suspicion.

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.

This is the system which should have been used for building the 6.3 BETAs
and RCs. Offering it for others to use for debugging, while a generous
gesture and no doubt greatly appreciated, is a bit like shutting the gate
after the horse has bolted. This will not achieve a better 6.3-RELEASE. The
release has already happened.

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.

6.3-RELEASE will never improve. Since the OP emphasised deploying only
RELEASEs, I suggest that his effort should go into making sure that 7.1
meets his requirements BEFORE it is released.

For the record, I am running 6.3-RELEASE on hosted systems interstate and
internationally and have had no problems at all: locally I am running a
mixture of 6.3-RELEASE and 7.0-RELEASE with no problem.

I hope this discussion provides a catalyst for more of us to become more
involved in pre-RELEASE testing to ensure an even higher standard of
RELEASEs from the FreeBSD project.

--
John Marshall

Attachment: pgpOnvbwGa7ug.pgp
Description: PGP signature

Relevant Pages

  • CLARITY re: challenge: end of life for 6.2 is premature with buggy 6.3
    ... I honestly believe most developers are addressing problems as fast as they can. ... 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. ... Net Consonance: consonant endings by net philanthropy, ...
    (freebsd-stable)
  • Re: Physical Firewall Configuration
    ... but never in a production environment. ... *nix firewalls / routers with multiple paths in some sort of configuration ... there are plenty of single points of failure between ... the SONET ring and you that will probably fail at some point. ...
    (comp.security.firewalls)