incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ate Douma <...@douma.nu>
Subject Re: [VOTE] Graduate Sqoop podling from Apache Incubator
Date Wed, 29 Feb 2012 15:39:50 GMT
On 02/29/2012 03:52 PM, Ate Douma 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.

To elaborate a bit more: to me project independence is one of the most important 
values the ASF stands for.
IMO many of our rules and guidelines are founded on that principle.

The (required) usage of the org.apache namespace is one way we tell the 
community: this is Apache, free to use and independent of possible 3rd party 
donations, claims or direction.

While for SOME use-cases there might be valid arguments we MUST use other 
namespaces (cleanroom spec. implementations for instance), or if a project 
*itself* needs to decorate a 3rd party dependency, IMO the base principle SHOULD 
be to stay away from including 3rd party namespaces.

I would propose that an ASF project SHOULD not use 3rd party namespaces, unless 
there is a very strong and logical requirement to do so.
I'm explicitly not using the term MUST here.

In the case of Sqoop, at least AFAIK, there is no *requirement* to include the 
com.cloudera namespace, other than as a convenience to the community.
To me that doesn't sound as a strong enough argument.
Allowing for such use-cases only muddies the water and will dilutes the ASF 
principle of project independence.

Ate

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message