incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ross Gardler (MS OPEN TECH)" <>
Subject RE: Practical next steps for pTLP experiment
Date Tue, 24 Feb 2015 09:06:22 GMT
Ok let me try again.

I am in support of pTLP where it is clear it will work for a given project. Sam makes a good
point that if we are sure it will work why bother. Just make it a TLP and be done with it.
This version of orthogonal to the IPMC. I agree and I think its a great idea.

My own concern is not projects that can become a pTLP or even a TLP. Such projects are not
a problem for the Incubator.. They graduate and don't have growing pains once graduated (or
at least no more than if they were to go straight to TLP). This is because they have, by definition,
active people in their community that will ensure the project will graduate

My concern, which is an IPMC concern, is the few projects that don't have that starting point.
The pTLP doesn't solve that problem. It moves it. I've been consistent with that feedback

I'm not sure how Roman interpreted my repeat of that, and a desire to try something else,
as me saying pTLP had to happen in the incubator. I didn't say that, at least not intentionally.
And in the summary of my position at the start of this thread, a summary I didn't write (that
is other people seen to understand my point).

So there you have it, I am taking a position.

PTLP is fine. Go do it (actually I'm with Sam, drop the "p" and thus drop the confusion)

PTLP doesn't solve the problems identified in the wiki. So whilst it can reduce unnecessary
work in the IPMC it wont since the problem.

Am I being clear?

One more point of clarity. If anyone wants to claim pTLP is all we need, and the IPMC can
be dissolved then I have a problem with that. And if someone does claim this then the two
things are not orthogonal.


Sent from my Windows Phone
From: Greg Stein<>
Sent: ‎2/‎24/‎2015 12:32 AM
Subject: Re: Practical next steps for pTLP experiment

"if we accept" ... take a position, Ross.

The two problems *are* orthogonal. The IPMC can do whatever it likes. A
pTLP is a proposal to the Board.

Bertrand would like to see discussion on general@incubator, but that is
merely a handy location. It actually has zero to do with the Incubator.

Ross: if you believe that a pTLP is somehow tied to the Incubator, then
state that. Otherwise, please STOP throwing uncertainty into the waters.


On Mon, Feb 23, 2015 at 7:29 PM, Ross Gardler (MS OPEN TECH) <> wrote:

> Fair enough. I don't think I ever agreed they are orthogonal. In fact the
> only concern I have consistently stated, and is reflected on the summary
> below, is that it, potentially, moves the problem rather than solves it.
> That being said, if we accept its orthogonal then your point is a good one.
> Sent from my Windows Phone
> ________________________________
> From: Roman Shaposhnik<>
> Sent: 2/23/2015 4:49 PM
> To:<>
> Subject: Re: Practical next steps for pTLP experiment
> On Mon, Feb 23, 2015 at 4:11 PM, Ross Gardler (MS OPEN TECH)
> <> wrote:
> > It's not unfair. I deliberately tried to say i don't want to distract
> from the handover process.
> I though we all agreed that whatever pTLP is -- it is absolutely 100%
> orthogonal to
> the process that Incubator is in business of managing. There will be
> some overlap
> of people involved in both, but we don't need to wait on Incubator to
> proceed with
> pTLP any more than we'd need to wait on Incubator to do something in
> Hadoop land
> (although quite a few Hadoop folks are on IPMC).
> > I don't think its productive to make someone's support or otherwise of
> an experiment
> > to distract from getting the right chair to replace you.
> That would be a fair point if we didn't try as hard as we can to
> decouple the two.
> If what you're saying is: currently there's no way for Incubator NOT
> to be involved
> in pTLP AND if that's the opinion shared by the majority on the board,
> I'd have to
> re-evaluate things on my end.
> I thought Greg convinced you all that it must be de-coupled. That's what I
> based
> my calculations on.
> Thanks,
> Roman.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message