Hi Benson,
On 2/26/13 2:58 PM, "Benson Margulies" <bimargul...@gmail.com> wrote:
>>[..snip..]
>>>
>>>I think that there are several hairs worth splitting here.
>>>
>>>1. Merging into a TLP is a possible outcome for a podling, even when
>>>the initial intention is to graduate independently. Even if we
>>>eliminate this as a starting intention, we should clarify how we
>>>expect this to happen. My prior email suggested a very low-overhead
>>>view of such events.
>>
>> It's my intention that that *should not be a possible outcome for a
>> podling*.
>> And just because we never said it explicitly (or maybe we did), that
>> doesn't
>> mean it was universally accepted either. You can gauge this by pure
>> numbers of
>> how many podlings have went this route (comparatively few).
>
>
>Chris, I am now confused. If a podling bogs down, and then finds that
>there is a congenial home for the code in an existing project, what's
>your desire? My suggestion that the existing project just adopt them
>with no formal graduation? Something else?
If a podling bogs down, and then finds there is a congenial home in an
existing project, I would have the following questions:
To the TLP and to the Incubator community:
0. What does "bogged down" mean? Needs specific definition.
1. Did the podling propose to assimilate into TLP?
a. If so, why did it have to bog down before getting TLP interested?
b. If not, then why show up as a TLP when the podling bogged down and
then assimilate? I would hope it's not for skirting IP issues, or
something else like that? Also, to borrow from Sam Ruby, I prefer
not to speak in hypotheticals, but to speak from actual examples, so
can you point to a situation when this has happened either recently or
at all? (I'll use a specific one below)
To the TLP
1. Do you care about the size of the podling? If it's a fairly substantial
contribution,
I would wonder how the TLP could "assimilate" the codebase, and would
worry about putting
that type of burden on the PMCs. We don't ask our PMCS to take on code
clearing, and IP.
And to be honest, if we are asking our PMCs to do that, why do we have the
"meta" committee
of the Incubator again?
To the podling
1. Why choose the TLP now? I would imagine if a podling got bogged down
then the act of choosing a TLP to accept it would have been premeditated
and not out of the blue.
So, yes, with those questions above, I still don't think that
Incubator->existing TLP is a valid exit.
Let's take HCatalog as an example. I don't support that for many of the
reasons previously stated.
I see that not as them "getting bogged down", but simply that's what they
had planned from the beginning.
However, what I questioned (and still question to this day) was the
"means" of executing that plans. They didn't
intersect (or union) the PMC of Hive and the PPMC of HCatalog. They
induced bylaws to deal with it in Hive,
and then went their separate way into Hive.
Greg and the board discussed this on the last board call. I don't think
that this specific example is a good
one to set -- I was on the board call for the first 30 mins, but I missed
this part of the discussion. So,
I'm not going to speak for those on the board call RE: this subject. My
personal opinion is that that specific
example should *not* be allowed to happen anymore and that the
Hive/HCatalog integration should also be watched to
make sure those PMCs are unioned (or intersected) very soon.
Let's take Curator as an example now. Put simply if the intention of
Curator is to form a *new* TLP, I'm +1 on its
entry into the Incubator. If there is some contingent that thinks Curator
can become part of the ZK project as a
product or some other form of the community, then I am -1 on Incubation
for Curator.
Cheers,
Chris
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
