incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mattmann, Chris A (3980)" <>
Subject Re: Running an experiment with pTLP
Date Tue, 30 Dec 2014 17:20:22 GMT
Marvin, I completely agree with you - to sum it up - my take on your point
that Apache has a lot of information and guidelines for new podlings
that is somewhat inconsistently brought down to new generations and
those after them of incoming projects. Have a mentor that’s a stickler
for release candidates - you will see projects come out believing that
is the end-all be-all for Apache (“gah, Apache is the communist release
foundation!”). Have a mentor that is a stickler for diversity on incoming
projects, podlings will come out believing there is some rule that a
committee can’t have a majority of contributors from a single organization
(“Ahh _that_ company is taking over an _Apache_ project! Gasp!”). Have
a mentor that’s a stickler for adding anyone that drops by on the mailing
list that says hi (ahem..ducks) you’ll have podlings coming in and new
committees believing in low barriers to committership and PMCship.

Regardless the above is the ethos of Apache and by and far, it will exist,
IPMC or not. There is no reason that the current f_active(IPMC) = [some
# less than 20] couldn’t simply still exist either in official committee
form (its own; or on the ComDev PMC), and continue to do the same thing.
It’s my belief that the genetic makeup of active IPMC members includes
a few mentors cut from each of the important incoming new project areas
that are important to pass down - legal, release review, community and
participation, etc - and that we should as best as possible try and
have a set of 3 that represents some nice representative cross section of
those skills for the new projects.

Furthermore, there is nothing stopping anyone from:

1. Making ASF members out of anyone that’s part of that active IPMC
list that’s not already a member
2. Having those ASF members vote in new board members that represent
their views and ethos (including themselves as new board members)
3. Having those board members be part of checks and bounds to *care*
and review these projects part of our foundation

Or some subset of the above.

My point being - IPMC or not - the things you cite below as important
will still exist, since this foundation and its people will, hopefully
for the next 50+ years.


Chris Mattmann, Ph.D.
Chief Architect
Instrument Software and Science Data Systems Section (398)
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 168-519, Mailstop: 168-527
Adjunct Associate Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA

-----Original Message-----
From: Marvin Humphrey <>
Reply-To: "" <>
Date: Tuesday, December 30, 2014 at 8:03 AM
To: "" <>
Subject: Re: Running an experiment with pTLP

>On Mon, Dec 29, 2014 at 9:01 PM, Mattmann, Chris A (3980)
><> wrote:
>> The structure would still be there - my hypothesis is that the
>> mentors + the board will both uplift structure, and help to identify
>> (more quickly) situations like no report, lack of mentors, etc.
>I am skeptical that Apache policies will be applied evenly under such a
>regime.  For example, release candidates routinely make it to the full
>vote with binary dependencies embedded in source.  Regardless of intent,
>removing final review by the wider IPMC will have the effect of
>the policy on bundled binary dependencies for those pTLPs who do not
>count any
>sticklers among their Mentors.
>Rather than change effective release policy for a minority through
>administrative laxity, the Board should grapple with the full
>implications of
>changing it explicitly for everyone.  (Yes, that will turn a huge, gory
>considering liability, etc.)
>Atomizing the IPMC will also yield inconsistency in other areas where
>there is
>either confusion or honest disagreement among the Membership as to what
>policies are, such as provenance documentation requirements for
>arriving via Github, or whether PMC chairs are "special".
>Nevertheless, +1 to move forward with the "pTLP experiment" (whatever that
>means).  Odds are that any given pTLP will work out OK, especially if they
>land one of our better Mentors.  But when one messes up, maybe we'll get a
>clarifying post-mortem with the Board in the hot seat and the Incubator
>unavailable as a convenient scapegoat.
>No matter how much progress the Incubator makes, people will continue to
>on it because it's a teacher and front-line enforcer of contentious and
>frustratingly complex Foundation policies.  I'm not sure that's a solvable
>problem, because it seems that The Apache Way inherently produces
>incoherent policy and policy documentation.
>Marvin Humphrey
>To unsubscribe, e-mail:
>For additional commands, e-mail:

View raw message