On Tue, Dec 30, 2014 at 2:25 PM, Mattmann, Chris A (3980) <chris.a.mattm...@jpl.nasa.gov> wrote: > Thanks Benson - I would suggest using the Incubator wiki if you > need one (but the point about there not being a Board wiki - interesting, > would be nice to have one). > > At the end of the day the resolution would look like a typical board > resolution after Incubator graduation e.g., “Create Apache X”, so > it would be summarized as you mention in point #3 below.
Chris, I agree that the simplest model of (p)TLP hasn't much of a (p): it would be a normal resolution, and we'll be off to the races. I plan, if the Nifi group is game, to send mail to the board offering that option, and then back off to a more complex proposal if the board wants more (p) -- like PR restrictions, or some sort of policy on how the initial podling group gets incorporated into the PMC. --benson > > Cheers and good luck. > > 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: Benson Margulies <bimargul...@gmail.com> > Reply-To: "general@incubator.apache.org" <general@incubator.apache.org> > Date: Tuesday, December 30, 2014 at 11:12 AM > To: "general@incubator apache. org" <general@incubator.apache.org> > Subject: Re: Running an experiment with pTLP > >>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)" < >>chris.a.mattm...@jpl.nasa.gov> 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: 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 >>> > >>> >>> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
