incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <akaras...@apache.org>
Subject Re: [VOTE] Graduate Sqoop podling from Apache Incubator
Date Wed, 29 Feb 2012 18:29:52 GMT
On Wed, Feb 29, 2012 at 4:52 PM, Ate Douma <ate@douma.nu> wrote:

> On 02/29/2012 02:45 PM, Greg Stein wrote:
>
>> On Feb 29, 2012 8:07 AM, "Alex Karasulu"<akarasulu@apache.org**>  wrote:
>>
>>>
>>> On Wed, Feb 29, 2012 at 2:06 PM, Greg Stein<gstein@gmail.com>  wrote:
>>> ...
>>>
>>>> They remain.
>>>>
>>>> Keeping them is the right thing for our community and product. That is
>>>>
>>> our
>>
>>> determination, and is our Right.
>>>>
>>>>
>>>>  Sorry but I don't think that's right.
>>>
>>
>> Please explain what information you have that states we cannot use
>> org.tigris.subversion for our deprecated APIs. I'm very curious because I
>> wasn't aware of any prohibition on this. You seem to know something the
>> Subversion community does not. Explain, please.
>>
>> (and yes, I know exactly who owns org.tigris.subversion; I'd like to see
>> if
>> you do)
>>
>>  Sqoop has determined backwards compatibility is important to their
>>>> community and wants to keep this (deprecated) interface for a while. So
>>>> where is the problem here, people?
>>>>
>>>>
>>>>  It's fine but those com.cloudera packages don't need to be hosted here.
>>>
>>
>> The community says it is best for their product to bundle the deprecated
>> APIs. Do you have some information from the community that says otherwise?
>>
>>  They can be hosted elsewhere and the backwards compatibility issue can
>>> still be handled.
>>>
>>
>> They can, but the community feels it best for their users to bundle it as
>> part of the product. Do you know something about the users that leads you
>> to believe they would prefer to get the deprecated interfaces from
>> somewhere else? As a separate download? An extra step?
>>
>> What do you know that the Sqoop devs do not?
>>
>>  Really. What is the problem with the extra interfaces?
>>>>
>>>>
>>>>  The package namespace is not ours. It's that simple G.
>>>
>>
>> Are we allowed to use it? Is the namespace designed/defined for us to use
>> it? Is somebody attempting to recover the deprecated namespace? Do the
>> owners *want* us to continue using it?
>>
>> Those are the questions.
>>
>> I know Subversion is allowed to use org.tigris for its deprecated APIs.
>> Who
>> are you to say otherwise? Why do you assume you know better? How is it you
>> know what package name I can or cannot use?
>>
>>  There is no legal (trademark or copyright) problem that I'm aware of.
>>>>
>>> There
>>
>>> is no technical problem that I'm aware of.
>>>>
>>>
>>>
>>> OK do we have the right to create any kind of package or class under
>>> com.cloudera (or any other companies packages)?
>>>
>>
>> I bet they would get pissed if we created arbitrary packages in their
>> namespace, but that is NOT the question at hand.
>>
>
> To me this actually *is* the question at hand, but from a different
> perspective than you bring up.
> In my initial response on this I raised this as a question about
> affiliation and independence of the project towards the community.
>
> For all I know Cloudera might not get pissed off at all if arbitrary
> packages in their namespace are created. There are plenty Cloudera
> committers on Sqoop which could (legally be allowed to) do this themselves.
>
> So to me this is not a legal problem but one of community, diversity and
> independence of affiliation.
>
> How will the community perceive the project independence from Cloudera if
> it carries, and maintains a 3rd party namespace, to which several
> committers are commercially affiliated as employee.
>
> That IMO should be an concern for the Foundation, not solely a 'Right' of
> a PMC to decide on themselves.
>
>
I completely agree with this position as well. It escaped my focus as I was
more worried about the issue of namespace collisions.

-- 
Best Regards,
-- Alex

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