On Sep 6, 2008, at 4:06 AM, Robert Watson wrote:
Unfortunately, it's a little hard to tell at time-of-release whether
a particular release will become extended life or not. This is
because extended support status is dependent on the success of the
release ...
from earlier branch adopters. How long we keep release 6.x releases
will depend entirely on how successful 7.x is; I think there's a
reasonable expectation that 6.4 or 6.5 will be the last 6.x release,
in which case we would want to grant it extended support status.
But what happens depends a lot on how successful 7.1 is. My hopes
are high, but there's nothing like real-world deployment to shed
light on things :-).
Robert, I'd like to point out to you that when I complained about
6.2's accelerated EoL, I was soundly boxed around the ears and told
that I should have been paying attention to the projected EoL date
when we decided to roll out 6.2 across the business.
I was also told that I should have been more active in the release
cycle process for 6.3, etc.
Now you are saying that expected EoL will be determined at some random
point in the future based on gut feelings about how well a completely
different branch is doing.
How can I reconcile these disparate points of view? How does one
focus on testing and upgrade cycle for an "appropriately supported
release" when the decision for the support cycle is completely up in
the air?
How does one talk to management about getting resources assigned to
help with the freebsd release testing process, when one cannot make
any valid predictions for that release will even be supported long
enough to justify the effort involved in upgrading?
What you are saying is completely reasonable from a developers point
of view. But those of us who use freebsd in an environment which
requires extensive testing and long-term planning for support have
trouble with this. In short, I can't imagine how I could possibly
make any business case to get support for helping the freebsd dev/rel
process at all. Why? Because frankly we're going to be forced to run
our own internal release management process instead.
I guess this is not surprising, as this appears to be what every other
business using significant amounts of freebsd in production are doing
today. My point to you is that if this wasn't being forced upon every
company that uses FreeBSD, those companies could commit more resources
to help the core (main branch, whatever - not "Core") freebsd
development.
--
Jo Rhett
Net Consonance : consonant endings by net philanthropy, open source
and other randomness
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
