On Feb 13, 2009, at 3:46 PM, Joe Bohn wrote:
Thanks for the quick response Kevan.
Kevan Miller wrote:
Hi Joe,
Good questions.
On Feb 13, 2009, at 3:13 PM, Joe Bohn wrote:
I have a few practical questions:
1) Must all affected releases be released before we can announce?
IMO, no. But I think users must have a reasonable upgrade path to
receive the fix. A 2.0.x user could be reasonably expected to
upgrade to 2.1.x to receive the fix. However, I couldn't reasonably
expect a 2.1.x user to downgrade to 2.0.x to receive a fix. I
believe that Tomcat will sometimes delayed releases with security
fixes on their older releases.
I like the emphasis on a reasonable upgrade path. So, based on your
proposal and most recent input, would it be more correct to state
step 10 as:
10. Roll a release for the most current actively maintained branch.
Earlier maintained branches can wait assuming that there is a
reasonable upgrade path to the most current actively maintained
branch. Any unreleased trunk or branch must include the security
fix but can proceed on current plans without any particular urgency
regarding the delivery of the security fix.
2) How long is considered too long between the check-in of code
for any release (which will likely divulge the vulnerability) and
the delivery of a release (or releases) which must precede the
announce in the steps above? It would seem that with this
proposal the time-period is unbounded.
It is unbounded. I'd set a target of 36 hours.
I don't see how this is possible. We have a 72 hour time-frame for
any release vote and attempting to shorten that would just telegraph
that there is a security issue. In addition, there is some
substantial work and validation necessary to generate a release
candidate prior to the vote (even assuming a last minute check-in of
the security fix). I think a more reasonable target (assuming a
flawless release and vote) would be 5 days (120 hours).
I'm ok with saying we'll release "as fast as we can".
We don't have to pre-advertise a short vote... So, I don't think
that's a big issue.
72 hours votes are an Apache guideline. It's not a hard-and-fast rule.
The only *rules* are a simple majority of PMC +1 votes and a minimum
of 3 PMC +1 votes. As long as the PMC feels that we have adequate and
appropriate oversight, then I don't see an issue.
Assuming there is pre-vetting of releases, I'd hope that most votes
will pass on the first RC.
3) Is it acceptable that the release notes will not include any
reference of the security vulnerabilities which are resolved?
IMO, yes.
I think this is a problem and will unnecessarily confuse our users.
Any idea how other projects handle?
--kevan
