On 2/12/2011 10:57 AM, Niall Pemberton wrote: > On Fri, Feb 11, 2011 at 10:31 AM, Daniel Shahaf <d...@daniel.shahaf.name> > wrote: >> Phil Steitz wrote on Sat, Feb 05, 2011 at 22:32:24 -0500: >>> On 2/5/11 4:16 PM, Scott O'Bryan wrote: >>>> Bertrand, >>>> >>>> I agree. The good thing about a vibrant community is that they >>>> generally enforce this. All I'm saying is this shouldn't be a "must" >>>> requirement, rather it should be a shall and we can let the individual >>>> communities work out what exceptions they allow. >>> +1 - but so the whole community can follow what is going on, it is >>> best to be open about what the "exceptions" can be and also to >>> include end dates in posts that kick off VOTEs. >>> >>> Phil >>>> On Feb 5, 2011, at 2:13 PM, Bertrand Delacretaz <bdelacre...@apache.org> >>>> wrote: >>>> >>>>> On Sat, Feb 5, 2011 at 2:56 PM, Scott O'Bryan <darkar...@gmail.com> wrote: >>>>>> ...I think it's important to keep things flexible because, as much as we >>>>>> would like everything to fit the same rules, some communities need to >>>>>> be a bit more dynamic and we need to trust the project PMC's and >>>>>> members to do what's best for the project and community. >>>>>> >>>>>> 72 hours is a good suggestion, but it shouldn't be mandatory... >>>>> A PMC that consistently uses voting periods shorter than 72 hours >>>>> would disempower people who cannot check the project lists every day. >>>>> >>>>> So I think 72 hour must be the rule, though exceptions are ok as you >>>>> mention. >>>>> >> >> The rule ought to be that the vote is long enough to let everyone >> interested vote before closing of polls. > > How can you know when *everyone interested* has long enough? *Open > Source* by its definition means you can't.
"Release vote" is not a code quality/features vote, but actually a procedural "this is collectively ASF code" decision by the committee. Yes, it's good to catch bugs and jettison a broken release, but the only *everyone* that is a concern are the committee members who would take the time to review, which is actually an ongoing process throughout the svn history of commit messages. As far as brokenness is concerned, you move on and roll another release if bugs were not noticed during the vote. 72 hours gives most any committee member who's watched the development of that code a chance to raise any "ASF stamp" concerns before it becomes a release. E.g. I was disconnected for near 72 hrs, and if someone had sprung a release at one of the projects I am involved in, I wouldn't have necessarily become aware of it nor voted on it. But over the course of 72 hours, I trust that someone else would have raised concerns we share since most committee folks would have seen the vote. Less than 3 days, you stand a good chance of catching more and more committee members unaware. --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
