Mailing-List: contact general-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: general@incubator.apache.org
Received-SPF: neutral (herse.apache.org: local policy)
Mime-Version: 1.0 (Apple Message framework v752.2)
In-Reply-To: <1295E8B8-9804-4136-BE46-37684F3D180A@maven.org>
References: <487a994c0612100547p7c275f58yae40ab67495cac23@mail.gmail.com>
 <628A59A6-354D-4EC3-BFE6-E827D4625832@gmail.com>
 <F09CC75F-C24E-4D75-95F2-0F6AD072E798@maven.org>
 <16d6c6200612101702r37b2693jb1fe252a7e1457a6@mail.gmail.com>
 <1295E8B8-9804-4136-BE46-37684F3D180A@maven.org>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <DCEC8F4A-767A-4107-B2A8-6E93CA799F9B@gbiv.com>
Content-Transfer-Encoding: 7bit
From: "Roy T. Fielding" <fielding@gbiv.com>
Subject: release voting
Date: Mon, 11 Dec 2006 14:33:08 -0800
To: general@incubator.apache.org

On Dec 10, 2006, at 5:11 PM, Jason van Zyl wrote:
> On 10 Dec 06, at 8:02 PM 10 Dec 06, Martin Cooper wrote:
>> On 12/10/06, Jason van Zyl <jason@maven.org> wrote:
>>> On 10 Dec 06, at 6:40 PM 10 Dec 06, Roy T. Fielding wrote:
>>>
>>> > On Dec 10, 2006, at 5:47 AM, Karl Pauls wrote:
>>> >
>>> >> We ask that you please vote to approve this release:
>>> >>
>>> >> [ ] +1 Approve the Felix 0.8.0-incubator release.
>>> >> [ ] -1 Veto the release (please provide specific comments)
>>> >
>>> > BTW, this Veto thing is wrong.  I've been meaning to mention it
>>> > since several podlings have used this template.  It is not  
>>> possible
>>> > to veto a release -- all releases are majority votes.  +1 just  
>>> means
>>> > yes and -1 means no.
>>> >
>>>
>>> Really?
>>>
>>> I thought that would be considered a technical thing? If you know a
>>> release is getting pushed out when it shouldn't because it's
>>> premature that on technical grounds you could say that it doesn't
>>> meet the requirements of a beta say? Or that it has know flaws and
>>> shouldn't be released?

No.  The only things that can be vetoed are specific changes, and the
veto must have a technical reason that is valid for that change.
Otherwise, one stubborn person can effectively kill a project simply
by vetoing every choice made by the group.

>> See the section on "Votes on Package Releases" here:
>>
>> http://www.apache.org/foundation/voting.html

Yow, more hopelessly vague wordings.  Look at the original httpd voting
guidelines for a better picture.

> Can a PMC chair veto a release?

No.  A chair only counts as one vote.  A chair's only special powers
are to receive things officially and ensure that the PMC does vote.
They can stop a package from being published if it has not yet been
released by vote of the PMC, but they can't unilaterally decide to
release or unrelease a given package.  If a chair wants such a thing,
they need to convince a majority of those voting to support their
position, just like any other majority decision.

Under no circumstances does a chair have any other special powers.
We burden the chair with infrastructure tasks just because we need
to delegate some of that work, not because we think they are making
decisions for the PMC.  A project decision must be made by the project.
The responsibility assigned to the chair by the bylaws is to give one
person the responsibility to ensure that decisions are made by the
project and maintain communication with the board -- it is the PMC
that is given authority to make project decisions, not the chair.

An RM can choose not to upload a release, but the package is released
if the project votes to release it.  Infrastructure or the Board can
remove a release from our websites if that is in the ASF's best  
interests.

There is no "legal veto".  If a legal problem is found with a package,
the ASF expects the responsible PMC members to change their own votes
in response to that discovery.  If for some odd reason that does not
occur, the Board can direct infrastructure to do anything needed,
but it can't rewrite history -- the package has been released and
the most the ASF can do is make it hard to obtain by stopping our
own distribution mechanisms.

....Roy

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org