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:25:43 GMT
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.

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
Mime
View raw message