Upcoming Releases Schedule...

Robert Watson rwatson at FreeBSD.org
Mon Sep 22 20:32:14 UTC 2008

On Mon, 22 Sep 2008, Jo Rhett wrote:

> On Sep 22, 2008, at 12:41 PM, Robert Watson wrote:
>> Lack of human resources, to use a vile term, is currently the limiting 
>> factor. What happens when that is cleared is another question, but in the 
>> end there aren't a whole lot of paths to greater efficiency here:
> ...
>> This is an inherently manual process because security patches touch a 
>> variety of parts of the system and each has different implications, the 
>> tendency for vulnerabilities to come in classes, etc.
> Great, thanks.  Do we have any idea how much additional human resources 
> would be necessary to extend the support period?

Short answer: no.

Long answer: we're under-manned for our current commitments, and have seen 
longer advisory cycles than we would like.  My guess is that we could eat the 
first 25% of a person just catching up on current obligations so as to reduce 
latency on advisories, handle back-analysis of reports that don't appear to be 
vulnerabilities but we'd like to be sure, etc.

Another hand-wave: 50%-75% of a person would allow us to move into extending 
our obligations as well as put more resources into proactive work.  You don't 
have to be on the security team to work on security work (and many people who 
do aren't), but certainly one obligation that comes with being on the team is 
to try to proactively address vulnerability classes and improve infrastructure 
for issuing advisories, providing updates, etc.

All hand-waving, understand.  Depends a lot on the person, the season (reports 
don't arrive at a constant rate), etc.

>> because there was significant divergence and maintaining three active 
>> development branches at once (5.x, 6.x, and 7.x) was a serious stretch.
> I've never suggested maintaining 3 different release versions, and I 
> wouldn't suggest trying.  When Sun, Microsoft, et al decide that they don't 
> have the resources to support 3 major revisions, it's a pretty good reason 
> to think that FreeBSD can't either ;-)

Tricky balance -- if you cut a major release every 18-24 months, you have a 
24-month support cycle on the final point release on each branch, and you 
continue to release minor releases after the .0 of the next branch in order to 
allow .0's to settle for a bit before forcing migration forward, it's hard not 
to end up in the many-branch support game.

Robert N M Watson
Computer Laboratory
University of Cambridge

More information about the freebsd-stable mailing list