On 02/29/2012 02:45 PM, Greg Stein wrote:
On Feb 29, 2012 8:07 AM, "Alex Karasulu"<akaras...@apache.org> wrote:
On Wed, Feb 29, 2012 at 2:06 PM, Greg Stein<gst...@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 unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
