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