incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mattmann, Chris A (3980)" <chris.a.mattm...@jpl.nasa.gov>
Subject Re: Running an experiment with pTLP
Date Tue, 30 Dec 2014 19:59:20 GMT
+1 thanks Benson, totally agree.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
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.mattmann@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 <bimargulies@gmail.com>
Reply-To: "general@incubator.apache.org" <general@incubator.apache.org>
Date: Tuesday, December 30, 2014 at 11:50 AM
To: "general@incubator.apache.org" <general@incubator.apache.org>
Subject: Re: Running an experiment with pTLP

>On Tue, Dec 30, 2014 at 2:25 PM, Mattmann, Chris A (3980)
><chris.a.mattmann@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.mattmann@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 <bimargulies@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.mattmann@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.mattmann@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 <marvin@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.mattmann@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-unsubscribe@incubator.apache.org
>>>> >For additional commands, e-mail: general-help@incubator.apache.org
>>>> >
>>>>
>>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>For additional commands, e-mail: general-help@incubator.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Mime
View raw message