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: chris.a.mattm...@nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Adjunct Associate Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -----Original Message----- From: Marvin Humphrey <mar...@rectangular.com> Reply-To: "general@incubator.apache.org" <general@incubator.apache.org> Date: Tuesday, December 30, 2014 at 8:03 AM To: "general@incubator.apache.org" <general@incubator.apache.org> Subject: Re: Running an experiment with pTLP >On Mon, Dec 29, 2014 at 9:01 PM, Mattmann, Chris A (3980) ><chris.a.mattm...@jpl.nasa.gov> 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 >IPMC >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: general-unsubscr...@incubator.apache.org >For additional commands, e-mail: general-h...@incubator.apache.org >
