Return-Path: Delivered-To: apmail-incubator-general-archive@www.apache.org Received: (qmail 81485 invoked from network); 14 Feb 2011 23:54:44 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 14 Feb 2011 23:54:44 -0000 Received: (qmail 68380 invoked by uid 500); 14 Feb 2011 23:54:43 -0000 Delivered-To: apmail-incubator-general-archive@incubator.apache.org Received: (qmail 68198 invoked by uid 500); 14 Feb 2011 23:54:43 -0000 Mailing-List: contact general-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: general@incubator.apache.org Delivered-To: mailing list general@incubator.apache.org Received: (qmail 68190 invoked by uid 99); 14 Feb 2011 23:54:41 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 14 Feb 2011 23:54:41 +0000 X-ASF-Spam-Status: No, hits=0.7 required=5.0 tests=SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [64.202.165.235] (HELO smtpout10.prod.mesa1.secureserver.net) (64.202.165.235) by apache.org (qpsmtpd/0.29) with SMTP; Mon, 14 Feb 2011 23:54:33 +0000 Received: (qmail 25280 invoked from network); 14 Feb 2011 23:54:11 -0000 Received: from unknown (76.252.112.72) by smtpout10.prod.mesa1.secureserver.net (64.202.165.235) with ESMTP; 14 Feb 2011 23:54:11 -0000 Message-ID: <4D59C0A0.6070503@rowe-clan.net> Date: Mon, 14 Feb 2011 17:54:08 -0600 From: "William A. Rowe Jr." User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: general@incubator.apache.org Subject: Re: Voting waiting period References: <2D129343-168F-4900-A4C9-AAE76240BA4C@toolazydogs.com> <25941_1296888513_4D4CF2C1_25941_279_1_4D4CF2C9.7010808@apache.org> <3028227656224141417@unknownmsgid> <2711522243378825923@unknownmsgid> <4D4E1648.2050000@gmail.com> <20110211103114.GA14873@daniel3.local> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org On 2/12/2011 10:57 AM, Niall Pemberton wrote: > On Fri, Feb 11, 2011 at 10:31 AM, Daniel Shahaf 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 wrote: >>>> >>>>> On Sat, Feb 5, 2011 at 2:56 PM, Scott O'Bryan 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-unsubscribe@incubator.apache.org For additional commands, e-mail: general-help@incubator.apache.org