Personally, I was detached from the preparation until Monday. When no one else was able to roll the release, I cleared my schedule, and did it myself. I didn't think of making it an "ASAP" release until I was preparing the email.
If I had it to do over again, I'd probably suggest submitting the bits for mirroring as soon as we had a positive vote (at least three binding +1 votes and more +1s than -1s), and then scheduling the announcement for 24 hours after that, should the vote remain positive. Let's keep in mind that quality votes are not a final judgment. In fact, we should be considering whether to downgrade Struts 2.0.6 and Struts 2.0.8. Personally, I would no longer call either release GA, and, under separate cover, I'm changing my own vote on 2.0.6 from GA to Beta, and casting a Beta vote for 2.0.8. -Ted. BTW, as to mirroring, the current advice is to submit any release for mirroring, regardless of whether it's labeled alpha, beta, or GA. If we vote on it, it should be mirrored. On 7/28/07, Niall Pemberton <[EMAIL PROTECTED]> wrote: > I don't have a problem with shorter periods for votes for good reason, > as in this case - I didn't like the "this vote will pass as soon as I > get 3 +1s" - every vote IMO should have a stated timescale. Also there > was no need to waste 3 more days to ask the PMC to change the usual > practice since it could easily have been done in advance - the issue > has been ongoing for 2-3 weeks and from what I can see organising the > release took several days - and a quick "btw does anyone object to a > vote lasting x hours for the security fix?" beforehand would have been > much better. > > Niall --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
