On Sep 22, 2008, at 1:32 PM, Robert Watson wrote:
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.
Thanks for the detail, and I think we all understand the necessary
vagueness. Is "a person" 40 hours a week? So if I could commit 10
hours a week, I'm 1/4 of a person in this context?
(assuming there was enough trust/etc that I could even do the work --
just for discussion)
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.
That's true. I've never been a huge fan of "release often" in
production systems ;-)
That being said, I was working on Debian when they went through the
Woody/Sarge era, and frankly I think that distinct production/
development tracks work even less well so it's not like I have useful
advice here ;-)
--
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]"
