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
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
