You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by "Roy T. Fielding" <fi...@gbiv.com> on 2006/12/11 23:33:08 UTC
release voting
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 <ja...@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
Re: release voting
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Dec 20, 2006, at 3:12 PM, Roy T. Fielding wrote:
>
> If an officer believes that a release package should be "vetoed"
> for legal reasons, then they should inform infrastructure to remove
> the release from distribution. However, that doesn't change the
> fact that a release was cut, a version number assigned, and a decision
> made by the project to release. It may seem like a small twist on
> semantics, but I believe it to be an important one.
>
++1.
There's no such thing, really, as an un-released release :)
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: release voting
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Roy T. Fielding wrote:
>
> If an officer believes that a release package should be "vetoed"
> for legal reasons, then they should inform infrastructure to remove
> the release from distribution.
Take that one step further...
s/officer/officer or member/
Any PMC member who discovers a legal violation should take immediate action,
inform the PMC, and inform the board that the situation had existed and how
it has been remedied.
Usually, if a package has an issue, infra will just move it from the web site
over to the creator's home directory. Likewise with svn, we do an rm, although
if we discover a major IP violation it's sometimes also necessary to remove the
offending code later from the history. You are a PMC member/committer so there
is nothing standing in your way from correcting the problem.
It's easy enough to restore if the 'issue' wasn't a problem.
I agree with Roy - a package can be taken down by the Chairman, but this is not
a VETO. If the chair raises a legal issue during a release vote, we trust most
PMC members will simply nod their heads and the vote doesn't pass (we also trust
the RM will do the same and the vote would never be tallied.)
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: release voting
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
On Dec 20, 2006, at 3:20 AM, Niclas Hedhman wrote:
> On Wednesday 20 December 2006 18:04, Roy T. Fielding wrote:
>> On Dec 19, 2006, at 8:02 PM, Greg Stein wrote:
>>> That's how it works.
>
>> No, that's not how it works.
>
> Isn't it a bit scary that two of the most respected members of ASF
> don't agree
> on how ASF operates "when push come to shove" ?
No, it only proves that we aren't machines. The exact details of how
it all works are not written down because people are expected to use
their own judgement to handle exceptions gracefully and make the process
more fluid when there is clear agreement. For example, most of the PMC
decisions are not made by vote -- PMC members simply go along with what
the other members are doing until there is a disagreement, and the
formal
process only kicks in when consensus is unclear or when the legal risk
requires that a formal decision be recorded (as in release votes).
In any case, the board does have the ability to delegate additional
powers to an officer when that is believed to be good for the ASF.
The process can also change over time if needed. However, I think
we should operate on the principle that the power to make decisions
is vested in the committees, and it is only the power to implement
those decisions that the officers can wield as needed.
If an officer believes that a release package should be "vetoed"
for legal reasons, then they should inform infrastructure to remove
the release from distribution. However, that doesn't change the
fact that a release was cut, a version number assigned, and a decision
made by the project to release. It may seem like a small twist on
semantics, but I believe it to be an important one.
....Roy
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: release voting
Posted by Yoav Shapira <yo...@apache.org>.
Hi,
On 12/20/06, Niclas Hedhman <ni...@hedhman.org> wrote:
> On Wednesday 20 December 2006 18:04, Roy T. Fielding wrote:
> > On Dec 19, 2006, at 8:02 PM, Greg Stein wrote:
> > > That's how it works.
>
> > No, that's not how it works.
>
> Isn't it a bit scary that two of the most respected members of ASF don't agree
> on how ASF operates "when push come to shove" ?
To me this debate is the opposite of scary: it's good. I like this
discussion for two reasons. Firstis that it's well thought-out, it's
clear both these guys are well-informed and well-intentioned, which
makes for an educational debate for all the readers. Second is that
it shows our organization is robust enough to thrive in the
flexibility we gave such an important role as VP/PMC Chair.
Yoav
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: release voting
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Wednesday 20 December 2006 18:04, Roy T. Fielding wrote:
> On Dec 19, 2006, at 8:02 PM, Greg Stein wrote:
> > That's how it works.
> No, that's not how it works.
Isn't it a bit scary that two of the most respected members of ASF don't agree
on how ASF operates "when push come to shove" ?
Cheers
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: release voting
Posted by Jim Jagielski <ji...@jaguNET.com>.
>
> The chair is not delegated authority over the projects -- only
> responsibility to manage the committee, and thus the only decisions
> that a chair can go hog-wild on are the establishment of unusual
> project bylaws or appointment and removal of committee members
> (which requires an ACK by a board member).
Considering that:
1. One of the most "legal" things a PMC does is
to release software and -
2. That the PMC is task with overseeing that and -
3. The Chair is tasked with managing the PMC and -
4. The Chair is an officer of the foundation
I would think that *with very VERY VERY* good reason,
the Chair could, if absolutely required, veto a release,
but it would only be for legal reasons and not
technical ones.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: release voting
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
On Dec 19, 2006, at 8:02 PM, Greg Stein wrote:
> On 12/11/06, Roy T. Fielding <fi...@gbiv.com> wrote:
>> ...
>> > 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.
>
> Euh... no. Nowhere is that stated in the ASF Bylaws. They're quite mum
> on what the Chair can do.
Yes, but Bylaws are subject to the General Corporation Law of the
State of Delaware
http://www.state.de.us/corp/DElaw.shtml
and committees, unless explicitly stated otherwise, are expected to
govern themselves under generally accepted codes of procedure. Like,
for example, "The Standard Code of Parliamentary Procedure, 4th ed."
or some variation on Robert's Rules. Both of them disagree with
your interpretation.
Officers can be delegated certain duties by the board, and once
delegated the officer has the implied power to do whatever is
necessary to carry out the functions and duties of that office.
But those duties must be specifically delegated in the resolution
or bylaws that create the office.
> The Chair *is* an officer of the corporation, though, and that implies
> a lot more than what you've stated. An officer can make binding
> decisions for the corporation. In the case of a project VP (the
> Chair), they can effectively do anything necessary within the realm of
> their project that is appropriate for that project. Consider:
>
> RESOLVED, that the office of Vice President, Apache Labs be and
> hereby is created, the person holding such office to serve at
> the direction of the Board of Directors as the chair of the
> Labs PMC, and to have primary responsibility for management of
> the projects within the scope of responsibility of the Apache
> Labs PMC; and be it further
The VP is delegated the duty of chair of a committee and primary
responsibility for management of the projects. *Everyone* knows that
the chair of a committee does not make decisions *for* the committee.
The resolution does not say that the VP makes project decisions or is
delegated authority over the project as a whole. The only reason for
the four paragraphs above it is to state that the board is delegating
that authority to a committee, not to a single person.
NOW, THEREFORE, BE IT RESOLVED, that a Project Management
Committee (PMC), to be known as Apache Labs, be
and hereby is established pursuant to Bylaws of the Foundation;
and be it further
That is the operative authority and it is not vested in the chair.
This specific type of delegation is defined by our Bylaws and is
specifically intended to be in the form of a committee, which
means that the decisions are made by committee decision.
The chair is not delegated authority over the projects -- only
responsibility to manage the committee, and thus the only decisions
that a chair can go hog-wild on are the establishment of unusual
project bylaws or appointment and removal of committee members
(which requires an ACK by a board member). The only way that the
VP can make unilateral decisions for the project is by first
removing the rest of the PMC -- otherwise, it is the committee
that is given authority to make project decisions, not the VP.
Putting it another way: there would be no reason to establish a
committee if decisions are to be made by the officer alone. Any
officer is capable of creating their own committees to delegate
their own duties (though not their responsibilities), so the board
resolution to do what you indicate would just appoint an officer
with both responsibility and authority and be done. The whole
reason for appointing a committee, and further to retain control
over the membership of the committee, is to have a committee duly
consider and act on project decisions rather than an individual.
> All of our TLP resolutions have that paragraph. With that paragraph,
> and VP status, I consider the Chairs to be able to do just about
> anything that is in the best interests of their project (and not
> counter to other interests of the ASF).
*shrug* I don't think that consideration is supported by either.
We'd probably have to get Drew Wright to judge what it means,
since he wrote the original paragraphs.
> The ASF Bylaws basically restate the above:
>
> "...the chairman of each Project Management Committee shall be
> primarily responsible for project(s) managed by such committee,
> and he or she shall establish rules and procedures for the day
> to day management of project(s) for which the committee is
> responsible."
>
> I've always interpreted the VP as the one to define the rules of the
> PMC. They are the actual "hand of power", but the Board expects them
> to operate that power in a certain way. If they misuse it... well,
> that's the end of that. Those expectations are things like voting
> procedures, consensus rules, blah blah blah. There is a cultural
> definition of *how* the VP should act, but when push comes to shove,
> I've told Chairs on a number of occasions, "dood. you're an officer of
> the corporation. *you* make it work. you have extremely wide leeway
> when it comes to handling your problems."
Those are all matters of project bylaws (how the committee operates),
not project decisions. Yes, the VP does have the power to act when
it comes to managing the committee.
This thread was not about managing the committee -- it was about
a release decision. A purely technical decision over which authority
has been specifically assigned to a committee. No chair has the right
to override decisions of the committee.
> When Ken dumped the entire Geronimo PMC, he did that under his rights
> as a VP of that project. He felt that was the appropriate action at
> the time. I believe he had every right/ability to do that, and the
> Board backed his right to do so. Now... if we saw Chairs doing that
> every other week, there'd be hell to pay. Again, there is an
> expectation of behavior, but there is actually very few written
> rules/restrictions.
>
> In this case, if we saw a Chair taking unilateral actions within a
> project, we'd call him to the carpet and demand an explanation. If he
> had a good one, then alright. That's how it works.
No, that's not how it works. If a chair makes a unilateral decision
for a project on a technical issue, then our project guidelines are
a bunch of rubbish. We have PMCs for a reason. It isn't pretty and
isn't the most efficient form of governance, but it balances the
powers sufficiently to keep our officers (and our board) from
getting too high off the fumes of power and wreaking havoc on the
long-term viability of our projects.
Checks, balances, and the principle of least authority are all
part of good governance. Probably the only way I could kill the
httpd project would be to start making decisions for it, even if
they all seem like good decisions at the time. Heck, even if
they all happen to be the best decisions possible, it would still
kill the project if others stopped thinking critically about the
products and simply waited for me to decide: death by atrophy.
....Roy
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: release voting
Posted by Greg Stein <gs...@gmail.com>.
On 12/11/06, Roy T. Fielding <fi...@gbiv.com> wrote:
>...
> > 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.
Euh... no. Nowhere is that stated in the ASF Bylaws. They're quite mum
on what the Chair can do.
The Chair *is* an officer of the corporation, though, and that implies
a lot more than what you've stated. An officer can make binding
decisions for the corporation. In the case of a project VP (the
Chair), they can effectively do anything necessary within the realm of
their project that is appropriate for that project. Consider:
RESOLVED, that the office of Vice President, Apache Labs be and
hereby is created, the person holding such office to serve at
the direction of the Board of Directors as the chair of the
Labs PMC, and to have primary responsibility for management of
the projects within the scope of responsibility of the Apache
Labs PMC; and be it further
All of our TLP resolutions have that paragraph. With that paragraph,
and VP status, I consider the Chairs to be able to do just about
anything that is in the best interests of their project (and not
counter to other interests of the ASF).
The ASF Bylaws basically restate the above:
"...the chairman of each Project Management Committee shall be
primarily responsible for project(s) managed by such committee,
and he or she shall establish rules and procedures for the day
to day management of project(s) for which the committee is
responsible."
I've always interpreted the VP as the one to define the rules of the
PMC. They are the actual "hand of power", but the Board expects them
to operate that power in a certain way. If they misuse it... well,
that's the end of that. Those expectations are things like voting
procedures, consensus rules, blah blah blah. There is a cultural
definition of *how* the VP should act, but when push comes to shove,
I've told Chairs on a number of occasions, "dood. you're an officer of
the corporation. *you* make it work. you have extremely wide leeway
when it comes to handling your problems."
When Ken dumped the entire Geronimo PMC, he did that under his rights
as a VP of that project. He felt that was the appropriate action at
the time. I believe he had every right/ability to do that, and the
Board backed his right to do so. Now... if we saw Chairs doing that
every other week, there'd be hell to pay. Again, there is an
expectation of behavior, but there is actually very few written
rules/restrictions.
In this case, if we saw a Chair taking unilateral actions within a
project, we'd call him to the carpet and demand an explanation. If he
had a good one, then alright. That's how it works.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org