incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benson Margulies <>
Subject Re: Running an experiment with pTLP
Date Tue, 30 Dec 2014 19:12:01 GMT
I plan to:

1. Ask the nifi community if they want to be experimental subjects. Can't
expect IRB approval without it.

2. Write a proposal for the board to read. There are a number of details to
worry over. Any suggestions about where to put it? There in no board wiki.
Is there?

3. Submit a board resolution when I think there is a consensus.
On Dec 30, 2014 12:24 PM, "Mattmann, Chris A (3980)" <> wrote:

> 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.
> Cheers,
> Chris
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 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
> Email:
> WWW:
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 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
> >liberalizing
> >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
> >fight
> >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
> >our
> >policies are, such as provenance documentation requirements for
> >contributions
> >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
> >hate
> >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
> >sprawling,
> >incoherent policy and policy documentation.
> >
> >Marvin Humphrey
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail:
> >For additional commands, e-mail:
> >

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