Date: Mon, 22 Sep 2008 17:05:43 -0700 From: Jo Rhett <jrhett@netconsonance.com> To: Robert Watson <rwatson@FreeBSD.org> Cc: freebsd-stable <freebsd-stable@FreeBSD.org>, Lowell Gilbert <freebsd-stable-local@be-well.ilk.org> Subject: Re: Upcoming Releases Schedule... Message-ID: <C0E77652-6C95-44CE-AD4A-3592ABA3E465@netconsonance.com> In-Reply-To: <alpine.BSF.1.10.0809222120420.26766@fledge.watson.org> References: <1219409496.10487.22.camel@bauer.cse.buffalo.edu> <alpine.BSF.1.10.0809061159410.28840@fledge.watson.org> <2742CAB1-8FF2-425D-A3B6-0658D7DB8F4D@netconsonance.com> <alpine.BSF.1.10.0809162043380.64176@fledge.watson.org> <0C2C7E9B-61E3-4720-B76F-4745A3C963DA@netconsonance.com> <alpine.BSF.1.10.0809180022580.13100@fledge.watson.org> <658B8861-1E78-4767-8D3D-8B79CC0BD45F@netconsonance.com> <alpine.BSF.1.10.0809181935540.16464@fledge.watson.org> <15F15FD1-3C53-4018-8792-BC63289DC4C2@netconsonance.com> <448wtpcikb.fsf@be-well.ilk.org> <C096D142-4572-48DF-8CCA-053B41003A07@netconsonance.com> <alpine.BSF.1.10.0809191158330.40909@fledge.watson.org> <34C3D54B-C88C-4C36-B1FE-C07FC27F8CB5@netconsonance.com> <alpine.BSF.1.10.0809201102270.22368@fledge.watson.! org> <58B648A5-4F9D-4C02-9A1C-21E1294DEB7A@netconsonance.com> <alpine.BSF.1.10.0809222020050.26766@f! ledge.watson.org> <A33CC6C6-98AB-428C-B78A-71F46839E682@netconsonance.com> <alpine.BSF.1.10.0809222120420.26766@fledg! e.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?C0E77652-6C95-44CE-AD4A-3592ABA3E465>