incubator-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Incubator Wiki] Update of "AlternativeIncubatorAnalysis" by BensonMargulies
Date Sat, 04 Feb 2012 13:13:56 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Incubator Wiki" for change notification.

The "AlternativeIncubatorAnalysis" page has been changed by BensonMargulies:
http://wiki.apache.org/incubator/AlternativeIncubatorAnalysis

New page:
In response to the current march to the Bastille, IPMC-wise, I wanted to try to organize a
set of thoughts about the existing incubator's purpose, warts, and possible future directions.
This is organized by the major responsibilities of the PMC. There are contrasts to the 'no
more incubator' proposal in here. I think that the upshot of this proposal is to offer 'less
incubator' as an alternative to 'no incubator.' You might also read this as offering some
ideas about details of a no-incubator universe.

= IPMC Responsibilities =

1. Groom & Evaluate Proposals for new Podlings

The IPMC is a the go-to place for incoming projects. Its web site provides a clear target.
It has 'brand presence' in the outside work, and positive brand presence, at that. Just because
we've tired of angry email exchanges (and other more material problems) has not (yet) translated
into the outside world seeing the Incubator as some sort of a crocodile-infested moat around
the ASF.

The IPMC is a resource here. It has a public mailing list, and that list reaches people who
have useful experience. 

This leads to my first major qualm about Chris' proposal: everything good, useful, or necessary
about the existing PMC is dumped upon ComDev. There is, in my mind, some circularity to the
argument here. "The incubator is a cesspit, so we should dismantle it. Oh, *that* essential
function? ComDev can do it."

Writing as a low-intensity ComDev participant, I think that this would be more accurate to
write, "IPMC members of good will can join ComDev." The result, I claim, is to recreate a
very substantial subset of the incubator as we know it under the (more confusing) name of
ComDev.

Evaluating proposals has not been a big topic of controversy. Still, I wonder if we'd have
less problem podlings if we had, well, less podlings. In fact, I'm sure that this is true,
but it doesn't make it a great idea. In any case, board members reacting to Chris' proposal
have asked for someone else than them to evaluate. Personally, I find the 'members@' suggestion
laughable. No public mailing list, no leadership, no track record in making decisions. If
the IPMC is torn down as we know it, *something* else will have to be invented if only for
this job.

= IP Clearance =

The IPMC is the official home of IP clearance. It's a somewhat complex topic that the TLPs
don't deal with all of the time, and new projects do the most of it. Is ComDev to become the
IP Clearance department, too? 

= IP/Release Supervision =

I have listed this separately because it is a problem area. No one, I think, enjoys watching
a podling struggle though seven release candidates as IPMC members randomly identify problems
one at a time. Anger at this process has fueled much recent discussion. However, I perceive
a box on Chris' proposal's blackboard drawing labelled 'a miracle happens here.' 

The underlying problem with the current process is not an oversupply of control freaks or
petty despots, pacé Bill, but rather an undersupply of clear documentation. Pacé Leo, it's
not necessarily lengthy, detailed, picky documentation. If podlings and mentors knew where
to go to find a clear, concise, statement of the requirements, they would be well on the way
to avoiding gauntlets.

That's not the only problem. There's also little to like about the 'throw a rock in the @general
pond and see who crawls out to review the release' process. It would be better if any given
release were to be reviewed by a small, know, group. Like, the mentors of the project? This,
in turn, would require the mentors to include at least one person who understands the policies
and is ready and willing to do the detailed reading. Alternatively, people with special talents
or interests in this area could make themselves available. Critically, once someone signed
up a release reviewer, they would see the process through, so we would drastically reduce
the situation in which each candidate attracts a new reviewer who finds new things to poke
at.

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


Mime
View raw message