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 14:06:50 GMT
On Wed, Feb 29, 2012 at 3:45 PM, Greg Stein <gstein@gmail.com> 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)
>
>
I was not clear here. I'm merely stating that I don't believe the practice
to be sound. Also I don't think it's a right TLPs should have. I was not
commenting on the current state of the subversion code base :).


> > > 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?
>
>
Nope.


> > 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?
>
>
No, no and no.


> What do you know that the Sqoop devs do not?
>
>
Not suggesting I know anything more about their product and their community
than them. Their aims to maintain backwards compatibility is a good one.
This is not being debated.


> > > 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.
>
>
IMO, the issue is over and done if Cloudera has authorized our use of their
namespace in some written form. This makes it so they cannot come back and
complain for us using the namespace.


> 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.
>
>
No it is not the question at hand. But where do you draw the line is my
point.


> The question is whether we can continue to use the old package name for
> backwards compatibility purposes. Have you asked Cloudera or the community
> if anybody told them, "no, we want our old package name back." No, I bet
> you didn't. I bet you saw com.cloudera and just generalized the issue into
> "somebody else's namespace" without full detail or background, which the
> community already had.
>
>
Foundation wide I see this as a policy that will eventually cause problems.
When the practice created to solve compatibility problems leads to
compatibility problems then ... you see where I'm going with this.

It's just better not to play this game at all. Just play it safe.

In the case of Scoop it's clear. But with the way we're growing you're not
going to be able to make sure collisions don't result. And that can
actually hurt other parties. The namespace mechanism is there to prevent
such collisions.


> You mentioned slippery slope earlier. Don't you see you're already on it?
>

Hahaha, yes actually I do but another slippery slope, the one I pointed out
above also exist. How do we stay off both?


> And this is the reason the Board stays out of technical decisions? Only the
> community knows best. You're on that slope, attempting to apply *your*
> technical mandates upon a project. But they know more than you.
>
>
I don't think I'm here trying to mandate how they're to procede
technically. It would be preposterous of me to do that. They know best, I'm
100% with you on that. But I don't think this is a technical discussion.

-- 
Best Regards,
-- Alex

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