Upcoming Releases Schedule...

[Jo Rhett]

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