incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mattmann, Chris A (388J)" <>
Subject Re: [DISCUSS] eliminate vetoes on personnel votes
Date Tue, 31 Jan 2012 23:05:12 GMT
Hi Roy,

On Jan 31, 2012, at 1:28 PM, Roy T. Fielding wrote:

> On Jan 31, 2012, at 12:52 PM, Doug Cutting wrote:
>> On 01/30/2012 05:12 PM, Greg Stein wrote:
>>> I've never liked vetoes for this. One person can hold an entire PMC hostage
>>> simply for disliking someone (or worse: subtle corporate concerns masked
>>> otherwise). People have said in the past, "you should have veto so you're
>>> not forced to work with somebody you dislike." I respond, "grow up. we work
>>> with annoying people all the time, and the majority says they *can* work
>> When this question came up in another context, Roy's concern, as I
>> recall it, was something to the effect that if you don't allow vetoes of
>> proposed PMC members then you might create a dysfunctional PMC.  (Roy,
>> please correct me if I miss-recall.)
> Well, it boils down to the fact that making someone a PMC member gives
> them veto power over the changes you make.  The only way that works
> socially is if everyone currently on the PMC agrees that person is a peer.
> Having said that, I should note that the context of Incubator is
> significantly different than a normal PMC.  If incubator wants to structure
> itself more like a board and less like a project, I really don't have
> much to say against that.  Note that it should effect all of the decision
> guidelines that give veto power, not just personnel decisions.

Isn't that the problem right now though? Like it or not, the Incubator PMC
has evolved into a mini-board, in the worse sense of the word. You guys
have a monthly meeting via telecon; an agenda; a set of action items, and 
you still don't get everything that you want to get done, done.

A very small percentage of folks within the IPMC actually maintain that type
of board-like oversight over its podlings. And thus, because of that, the more
I think about it, quite honestly, I don't know what the Incubator PMC is doing
other than delay the inveitable eventuality that many of these projects will 
graduate and become TLPs and thus "the board's problem"; whereas many 
of them will not graduate, and become "not Apache's problem". We have an 
Attic for projects that make it to TLP for that. Heck, we have SVN and could
even reboot Incubator dead projects if a group of individuals came along
and wanted to maintain the code.

My conclusion from all the ruckus recently has been that the Incubator "PMC"
is nothing more than an Incubator "mailing list" where many ASF veterans 
and those that care about the foundation discuss (and sometimes argue)
about the foundation's policies and interpretations of law that not even lawyers
are perfect at -- we're all human yet we try and get on our high horse here
and act like we speak in absolutes and the will of one or a small subset is
the will of the many when we all know that in the end, if it's not fun anymore,
we wouldn't be here. 

What would be so bad about saying that the Incubator, over its existence, 
has served its purpose and has devolved into an umbrella project of the type
that we are looking to get rid of at the Foundation. I agree with Bill on the 
perspective that I'm sure at some point (and it's probably already happened), 
we will experience Jakarta type symptoms and potentially may go down that
road. Instead of couching it as "scary HUGE" change that several Apache 
vets have expressed to me that the Foundation doesn't like, how about we 
don't call it a "change" at all; and simply a "success". IOW, the Incubator itself
has "graduated" and it's time for it to be "Attic'ed".

In replacement, I propose the following concrete actions:

1. Move the Incubator process/policy/documentation, etc., to ComDev - I 
agree with gstein on this. I think it could be maintained by the ASF community
folks there, and updated over time. But it's not vastly or rapidly changing really

2. Discharge the Incubator PMC and the role of Incubator VP -- pat everyone on 
the back, go have a beer, watch the big game together, whatever. Call it a 
success, not a failure.

3. Suggest at the board level that an Incubation "process" still exists at Apache, 
in the same way that it exists today. New projects write a proposal, the proposal
is VOTEd on by the board at the board's next monthly meeting, and those 
that cannot be are QUEUED for the next meeting, or VOTEd on during out of 
board inbetween time on board@. Refer those wanting to "Incubate" at Apache
to the existing Incubator documentation maintained by the ComDev community.
Tell them to ask questions there, about the process, about what to do, or if
ideas make sense. But *not* to VOTE on whether they are accepted or not. 

4. Require every podling to have at least 3 ASF members on it, similar to the
current Incubator process. 

5. Operate podlings *exactly the same* as a TLP. There is a chair. There is a
committee. Committee members have binding VOTEs on releases. 

I'm sure folks will argue this is blasphemy or that it will just add to the board's
work, or that .... I'm ugly ... whatever. The fact of the matter is we kick spinning
around in circle's trying to fix process issues that have been band-aided for 
years and that are now leaking like a sieve whenever we decide it's time to 
shine a light on them. When things are going "well" in the Incubator, it's not 
because they are well. It's because no one is asking questions and they've
chosen to ignore some of the gaping holes on the poor wounded body that
remains. And then when some folks go and point out the gaping holes, we 
get these huge song and dances that don't amount to anything other than
the old mantra "incremental change; don't rock the boat too much; XXX board
member won't go for it; not here at Apache". Whatever.

I think the board knows there is an issue with the Incubator. A lot of IPMC
members do too. Some of us have spoken up; others haven't. I present
above what I feel are concrete steps that could be actioned upon that 
I believe would improve the overall process and bring to light what is
already occuring:

1. podlings are themselves distinct communities and will interpret our 
human laws and Apache doctrine the same as any other human when you
put 10 of them in a room -- in 10 different ways. 

2. podlings are more and more able to pick up on the basic principles of
the Incubator documentation; its legal oversight and its processes. They 
aren't perfect, but neither are any of us. It's pretty good and we've got plenty
of RMs (as evidenced by other discussions) that can produce an Apache
release that hasn't gotten us sued yet.

3. mentors encourage their podlings to operate autonomously. general@ is
often labeled "the wild west" and for good reason. If I went over to HTTPD
and started spewing my OODT nonsense, many of you would scream foul
and blasphemy just like I'd do if you guys came over into OODT and started
flexing "your specific interpretations" of our commonly agreed upon mantra.
That's what general@ is like. I don't think it makes sense, and I think those
mentors who are doing a good job on their projects and those projects
that are doing well would do well the same as TLPs. Many of the other
side conversations around this issue are suggesting that -- why nominate
folks for the IPMC when we could simply graduate the podlings?

Anyways I could type more but I think I've beat this horse to death. I appeal
to you and to the rest of the board members reading this thread will consider
my proposal. Thanks for reading.

--Chris, who I'll note *does* care about the IPMC and *does* care a ton about Apache
and the folks here and our hallowed status as an awesome open source organization.

Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA

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

View raw message