incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <>
Subject Re: Nomination of Chris Mattman for the IPMC Chair (was: Re: NOMINATIONS for Incubator PMC Chair)
Date Sat, 04 Feb 2012 00:41:02 GMT
Sent from my mobile device, please forgive errors and brevity.
On Feb 3, 2012 4:27 PM, "Mattmann, Chris A (388J)" <> wrote:
> Hi Greg,
> On Feb 3, 2012, at 1:44 AM, Greg Stein wrote:
> > On Fri, Feb 3, 2012 at 00:58, Mattmann, Chris A (388J)
> > <> wrote:
> >> ...


> "Oh, we have these sets of projects that are related, let's create a
> meta committee that will [wrangle] them together, and then report
> out on their status, share MLs, etc. etc."
> Each and every time the above is presented, the argument against
> (besides maintaining the status quo, which I honestly think is being
> pushed here) is that there is no need for such a meta committee
> (and by transitivity) a meta VP role. That's what the Incubator VP
> is. A meta VP. We don't need the role.

This ignored a great many suggestions. Including my own (which I've not got
sufficient time to flesh out right now, but you seem to be making
significant assumptions about what flesh there would be on those bones).

> > As I
> > mentioned before, I believe there are aspects to incubation that
> > require a supportive group which cannot simply be shifted to the
> > podling-TLP
> I don't agree with this. It's shifted to the project TLP. That's OK.
> Why is this not?

The incubator had demonstrated that relying on mentors is not always
sufficient. The incubator has failed in it's guidance rule. It has turned
to oversight and interference. Your proposal, in it's current form, will
remove the interference but will not revive the guidance.

The ASF is not just a place to host open source. It is a community
learning how to do community is hard. The incubator was created to help
that learning. Your proposal, as it stands will remove the interference but
will not revive the learning.

> > The Board has enough to do without trying to
> > *also* verify release processes, check on podling branding and press,
> > etc.
> You guys don't do that for projects, why would you do it in this case?

TLPs are self governing, podling TLPs could be, but your proposal assumes
they alwats will be, from day one. Yet the incubator demonstrates mentors
often fail in this regard. I am not involved in a single poddling that can
mystery three binding votes on a release today. The IPMC fills the gap, but
it also generates interference. Your proposal, as it stands, will remove
the interference but will not maintain the necessary oversight.

> To summarize in a sentence my proposal:
> "Get rid of the Incubator PMC, its VP, etc and just start treating
> projects like Apache projects, day 1."

Most incoming projects are not Apache infects on day 1. Your proposal, as
it stands, will result in a new kind of Apache. One in which the average
standard of IP management is reduced. One in which the strength of the
average community is reduced.

Despite all this I like you're proposal. It has a great deal of merit, but
it is incomplete. All that is required for me to like it is to say, this is
the starting point, lets identify suitable projects that can survive in
this format. Work with them and address the issues that emerge. Later we
can move the more complex projects into this format.


> Cheers,
> Chris
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Chris Mattmann, Ph.D.
> Senior Computer Scientist
> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
> Office: 171-266B, Mailstop: 171-246
> Email:
> WWW:
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Adjunct Assistant Professor, Computer Science Department
> University of Southern California, Los Angeles, CA 90089 USA
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message