On 8/2/07, Ted Husted <[EMAIL PROTECTED]> wrote: > So to sum up the post-mortem, > > Security Releases > > * When a serious security issue arises, we should try to create a > #.#.#.1 branch on the last GA release, and apply to that branch only > the security patch.
+1. Surgical. > * If the patch first applies to WebWork, or some other dependency, > beg the other group to do the same, to avoid side-effects from other > changes. +1. 'beg' = 'lean strongly'. > Fast-Tack Votes > > If the release manager would like to "fast track" a vote, so as to > make a security fix available quickly, one suggestion is to This might be a correct solution, but I've not seen a problem that it solves hit Struts yet. If a security issues showed up (publicly or privately) and the release manager on that release immediately rushed through a fix, I'm all for your fast track solution. I'd be more for it if it was the work of the release manager and the chair together - I'd not even care about the vote if that was the chair's call. Gotta be a serious security issue. In this case, it's not a new bug that had just shown up. It was kicking around the issue tracker for a fair while. I'd much rather see a normal vote happening, and am happy with a vote on private@ if it's for a security release and the issue is not yet public (this one was, but we get others that aren't). Definitely not a 'as soon as we have 2 other +1s then we'll release'. Maybe a 24hr or 48hr vote, probably with a cc to private@ as a heads up. I'm agreed with Niall on 'hitting the mirrors' equaling a release. Announcements are just marketing. Hen --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
