Snipping this part out since this isn't directly related to Stratos:

Let's start with these point made by Ross, Shane and Jim. I start out
with my interpretation of their sentiments. These are my own. If they
are wrong my bad.

1. pTLPs *are* different.
 
Shane, Jim: pTLPs are different from a brand and community perspective.
Shane says that the "outside" world who arguably doesn't really get what
podlings
are nee see Open Office press releases and pre-media; and also pre-media
for other recent podlings before they became podlings including Flex [2]
and other projects will be more confused by pTLPs since they assume
the whole process of moving through a work flow of

podling->work toward graduation [licensing;releases;new
committers/PMC;diversity]->graduation [or retire]

is something that is known and has been educated to the outside world.
This is
what I think Jim is talking about when he says he likes what the Incubator
does
in terms of growing an Apache community.

Chris: I agree with both of the sentiments above. To me that's the whole
notion of "Incubation,
yes; Incubator no". In other words, why do we need a meta committee of
170+ individuals
to have oversight (ha!) over the above process?? What better example of
the board kicking
the can down the road, and doing it in a ridiculously unsustainable way.
The above *process*
*should* exist. It's great. That's why I say "Incubation *should* exist".
Should the Incubator aka
from a legal perspective, a committee; a home; a brand (if it even has
one?) exist? I say
"Incubator, no". We can do all the above b/c our TLP projects do all of
the above. The 
board does have oversight of those projects, but it disperses that
oversight into 
the great decentralized leadership that our communities have.

2. It's harder to discharge a pTLP rather than a podling

Jim, Ross: It's going to be harder to pick up the pieces if pTLPs are
unsuccessful, than
it would be for a podling.

Chris: Please explain to me how this is? Wouldn't the process work very
similarly:

1. time to get rid of {pTLP|podling}
  - [DISCUSS] threads, to get community involved
  - community leaders jump in (this happens in the Incubator too; see
Mesos)

2. Based on results of #1
  - retire
  - continue with some measurements X months down the road

3. If continued from #2
  - remeasure; if no progress, retire
  - if progress, great, eventually converge to optimality and health again
(or not)

Yes, those are the community aspects. Let's talk infrastructure.
Discharging projects
whether they are pTLP or podling are fairly similar I'd imagine (mailing
lists; SVN, 
archives; perms, etc.) Let's talk brand/IP -- depends on how far along the
pTLP or 
podling got with this, either way this involves some careful work, pTLP or
podling or not.

3. There isn't any benefit to implementing pTLPs
Jim: I see no real benefit to implementing pTLPs.

Chris: The benefits would immediately be that they don't have to go in
front of a 170+ person
committee to get a decision. Those doing the work in the project will have
binding 
VOTEs, and they will operate that way. For oversight they have 3 ASF
members watching 
them (this *should* be the way that podlings work now -- but in reality we
only have
a requirement of 1+ ASF member -- the Champion/Mentor -- that's it -- see
recent
threads in Incubator where Ant and I uncovered this). So, we make pTLPs
have a requirement
of 3 ASF members.

Other benefits would also be in release VOTEs where those doing the
releases could 
have their VOTEs be binding (which they will anyways) -- and we'll have
the benefit
of members who've seen VOTEs before watching them, still having oversight,
and still
having it be distributed. The board isn't responsible -- the pTLP ASF
members are. The
board "reviews" the progress; it doesn't flex its muscle or hammer if it
doesn't have to.

OK hope that summarizes my thoughts and replies in a single email to the
recent replies.

Cheers,
Chris

[1] 
http://www.infoworld.com/d/applications/apache-asserts-openoffice-stewardsh
ip-176140
[2] 
http://www.peterelst.com/blog/2011/12/27/apache-flex-incubator-proposal-is-
up-for-a-vote/

-----Original Message-----

From: Ross Gardler <rgard...@opendirective.com>
Reply-To: "general@incubator.apache.org" <general@incubator.apache.org>
Date: Friday, June 14, 2013 8:38 AM
To: "general@incubator.apache.org" <general@incubator.apache.org>
Subject: Re: [DISCUSS] Accept Stratos as an Apache Incubation Project

>On 14 June 2013 15:42, Mattmann, Chris A (398J)
><chris.a.mattm...@jpl.nasa.gov> wrote:
>> Those are "concerns/issues" with the Incubator. They aren't
>> a proposal of what to do.
> For concrete suggestions about how to address the issues in the wiki
>take a look at the "solutions" section under each issue. All issue
>have at least one suggestion, many have more.
>
>> * pTLP are nothing different than what existed before there was an
>> Incubator.
>
>Sorry Chris, I disagree. It is *very* different. Where it isn't so
>different is in cases where there are plenty of experienced and active
>mentors (I believe Stratos is one such case which is why I proposed it
>as a test case).
>
>> * This is an incremental step in the deconstruction proposal.
>
>Not for me it isn't. It's an incremental step towards finding the
>merits in your proposal for a specific type of project. I have never
>supported the deconstruction proposal and I trust people (including
>the board when the IPMC makes its recommendations) are clear on this.
>My championing of this proposal should not be seen as a championing of
>the whole deconstruction idea.
>
>> Note, Ross was one of the most vocal discussers, seeing both the
>> merit and potential pitfalls of my proposal. In short, if I've got
>> Ross convinced enough to at least try it, then give it a chance.
>
>The only thing you have convinced me of is that there is no
>opportunity to find the merits while this pTLP idea is wrapped up in
>the larger deconstruction proposal.
>
>I made this clear in the initial proposal of the idea and I made it
>clear in my response to Jim. I'm making it clear again here.
>
>I want to expose the merits and avoid the pitfalls of your larger
>proposal. I am *not* adding my weight to your larger proposal. I am
>merely moving past an incomplete wiki page with practical activity. I
>will do the same with many of the other proposals that have merit
>(e.g. Ant has started to build momentum behind his tooling
>suggestions, |I hope to help there too).
>
>Ross


++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.a.mattm...@nasa.gov
WWW:  http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++



>
>>
>> Cheers,
>> Chris
>>
>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> Chris Mattmann, Ph.D.
>> Senior Computer Scientist
>> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
>> Office: 171-266B, Mailstop: 171-246
>> Email: chris.a.mattm...@nasa.gov
>> WWW:  http://sunset.usc.edu/~mattmann/
>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> Adjunct Assistant Professor, Computer Science Department
>> University of Southern California, Los Angeles, CA 90089 USA
>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>
>>
>>
>>
>>
>>
>> -----Original Message-----
>> From: Ross Gardler <rgard...@opendirective.com>
>> Reply-To: "general@incubator.apache.org" <general@incubator.apache.org>
>> Date: Friday, June 14, 2013 6:48 AM
>> To: "general@incubator.apache.org" <general@incubator.apache.org>
>> Subject: Re: [DISCUSS] Accept Stratos as an Apache Incubation Project
>>
>>>On 14 June 2013 14:45, Jim Jagielski <j...@jagunet.com> wrote:
>>>>
>>>> On Jun 14, 2013, at 9:31 AM, Ross Gardler <rgard...@opendirective.com>
>>>>wrote:
>>>>
>>>>> Thanks for your comments Jim.
>>>>>
>>>>> You will see from the archives that I share most of your concerns
>>>>> about probationary TLPs. However a number of IPMC members have argued
>>>>> strongly for the concept.
>>>>>
>>>>
>>>> To be clear, the only info that seems "official" about pTLPs
>>>> is the Wiki page proposal:
>>>>
>>>>     http://wiki.apache.org/incubator/IncubatorDeconstructionProposal
>>>>
>>>> IMO, it simply doesn't provide enough meat, details and rationale
>>>> for me to be able to "commit" to it enough; there's a difference
>>>> between the concept and the implementation of that concept.
>>>
>>>Agreed (and partially discussed elsewhere in this thread).
>>>
>>>Greg outlines a minimum he wants to see from the proposal to the
>>>board. I agree with his minimum and will be looking to two supporters
>>>of the pTLP concept to coordinate delivery of that minimum (I
>>>discussed this with
>>>both of them prior to make this suggestion, both agreed).
>>>
>>>Ross
>>>
>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>>
>
>---------------------------------------------------------------------
>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

Reply via email to