incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ross Gardler (MS OPEN TECH)" <>
Subject RE: What is "The Apache Way"?
Date Tue, 13 Jan 2015 18:30:15 GMT
Thanks for taking my comment the way it was intended (to fuel productive debate) :-)

You are right that VPs don't set policy but they should write policy and submit to the board
for tuning and/or approval/rejection. In turn those VPs will typically consult with their
committee members. It really should be bottom up. This scales well. Looking to a board of
9 overworked directors to do everything for 150+ projects (and potentially adding podlings
based on some IPMC recommendations) does not scale.

That being said, you are correct the release policy is really a legal issue and thus is under
VP Legal, with VP Infra needing to approve any policy since it has impact on what infra needs
to deliver.

Fortunately Jim has indicated he feels he owns much of this as VP Legal so you are off the
hook and made your point well - a good result for you I think :-)

Here's to Jim for stepping up and offering to try to heard the sheep on this one.


-----Original Message-----
From: David Nalley [] 
Sent: Tuesday, January 13, 2015 9:37 AM
Subject: Re: What is "The Apache Way"?

On Tue, Jan 13, 2015 at 11:23 AM, Ross Gardler (MS OPEN TECH) <>
> Well, David, I'm afraid you are the authoritative source on the policy you use as an

:) Well - I suppose I did open myself up for that.

> If it's not documented and that's a problem then it's *your* problem. You could (given
even more time to volunteer to the ASF, solve it however you like (e.g. Write the doc, ask
the community to write it, ask for budget to have a contract write it, something else), but
it's you and the infra team that own this.

So, infra has a number of policies - like not keeping more than the current release on dist,
giving us a heads up if your artifacts are going to be more 1GB, but they are largely centered
around efficient operation of infrastructure, and not Apache Doctrine. Defining (and by extension
enforcing) Apache Doctrine, means that infrastructure becomes the Foundation's policeman,
at least in certain matters.
Infrastructure, derives authority from the office of the President.
Based on my reading of the bylaws, and the almost recent discussion around Brand issues -
I walked away with the fact that the office of the President may not be able to set binding
policy on projects.
(differentiated from binding policy of how you may use resources of the Foundation).

In the specific example I referenced - which came up in May (on board-private because there
was a security issue related to it) I was told to carry the issue to the public board mailing
list after the security issue was dealt with because it needed discussing. It did get discussed
- release policy (which I think was later declared to be a legal issue), which is a board
committee. After that thread revealed that there was no written policy, I explicitly asked
several directors
(individually) if that was within my scope to define, so as to remove the ambiguity and walked
away with the impression that most of them felt it was not within my level of authority.

> I hope you won't take this personally, its not meant that way. As a volunteer you do
a fantastic job and we are all immensely grateful. However, you did feed me a perfect way
to illustrate the point I've been trying to make when highlighting docs and saying "patches

Not at all.
My assumption was that 'setting binding policy on projects' was something specifically excluded
from my level of authority, as an officer derived from the Office of the President. If that
is not the case, I am happy to define and publish such things within the realm of infrastructure.

> Perhaps it is time we hired a contractor to draw up the one document of truth?
> I'm working on the 2015 budget now. Any volunteers to own this? Ownership is ensuring
that the individual gets access to all the appropriate VPs and that those VPs are able to
provide the necessary input.

I think Marvin could manage this well (yes, this is me pushing you in front of the bus, Marvin.
My apologies). Failing that, I'm happy to tackle management of that.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message