Upcoming Releases Schedule...
jrhett at netconsonance.com
Mon Sep 15 17:00:22 UTC 2008
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
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
Net Consonance : consonant endings by net philanthropy, open source
and other randomness
More information about the freebsd-stable