On 2/15/2011 5:33 PM, Niall Pemberton wrote: > On Mon, Feb 14, 2011 at 11:54 PM, William A. Rowe Jr. > <wr...@rowe-clan.net> wrote: >> 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 > > By the letter of the law you're correct, but I disagree. If the only > people who mattered were committee members, then we would just hold > all votes on the private lists. But this is open source and by its > nature it should encourage participation from anyone, whatever their > *status*. If someone who isn't a committee member votes against > something and backs it up with sound arguments, then it would be dumb > PMC that ignored it. I like it when people not on the committee take > part in votes and I think we should encourage it. As Hen said in "were > in the recruiting business" [1]. My pet peeve is people putting > "binding" on their vote - it tells non-PMC-members "you're vote > doesn't count" - we don't need to do that, the person running the vote > can work that out when they tally up. > > [1] https://twitter.com/flamefew/status/36352411593351168# > > Whether code quality/features is part of "Release vote" is up to each > PMC and I have often seen PMCs choose not to release based on that - > and thats their right if they want to manage the project that way.
I don't disagree with any of the above, but made my points above so that the context below can be better understood... >> 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. > > I agree with this, but replace "committee members" with "people" and > lets have an attitude of inclusion. Just because the letter of the law > specifies that only committee members count, doesn't mean we need to > narrow our attitudes to not value other people participating. If the RM subverts the committee's review, the release process is broken, the ASF interests are not protected, and this is one which is even worthy of board review of the committee membership if it is deliberate shortcut by the RM. If the RM allows inadequate time for review by "people", that's simply an inconvenience, perhaps a disservice to the community, but called for in certain cases such as security releases with short voting periods. So I entirely agree and disagree with you above, and believe you misread the point I was trying to make. The released vote timetable MUST be sufficient for review by the committee, and SHOULD be sufficient for review by the community at large who participate in the discussion. --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
