On Wed, Feb 29, 2012 at 2:06 PM, Greg Stein <gst...@gmail.com> wrote:
> On Feb 29, 2012 4:15 AM, "Alex Karasulu" <akaras...@apache.org> wrote: > > > > On Wed, Feb 29, 2012 at 4:06 AM, Daniel Kulp <dk...@apache.org> wrote: > > > > > On Wednesday, February 29, 2012 1:13:30 AM Mohammad Nour El-Din wrote: > > > > Hi Daniel... > > > > > > > > On Wed, Feb 29, 2012 at 1:07 AM, Daniel Kulp <dk...@apache.org> > wrote: > > > > > We had a very similar discussion about the back word compatibility > > > > > classes/package names when Subversion graduated and we deemed it OK > for > > > > > them. > > > > > In fact, I believe they still of org.tigris packages in their > codebase > > > > > long > > > > > after graduation. See: > > > > > > > > > > > > > > > > > > > http://svn.apache.org/repos/asf/subversion/trunk/subversion/bindings/javah > > > > > l/src/org/ > > > > > > > > > > > > > > > I don't see why we would or should hold Sqoop to a different or > higher > > > > > standard at this point. I agree with Jukka that if we, as a > > > foundation, > > > > > would like to re-address this, fine, take it to trademarks@ and > start > > > a > > > > > discussion. However, from an INCUBATOR standpoint, the precedent > and > > > > > expectations have been set. > > > > > > > > > > That's my $0.02 cents worth. > > > > > > > > Thanks a lot for this, but would you elaborate more on why this has > been > > > > accepted ? My believe is that there is some clarification that should > be > > > > added to documentation so it is more clear for all people in the > future, > > > > your input on this example would help indeed. > > > > > > You could likely read the mail archives if you want all the details. > > > general@incubator in Nov 2009 had a thread, dev@subversion in Jan > 2010 > > > had a > > > thread, and I think the graduation vote in Feb 2010 had more > discussions. > > > > > > Basically, the Subversion had binary compatibility "rules" and there > was no > > > real "legal" requirement to force a huge disruption in the community by > > > changing the package names. The project had a plan to deprecate > > > them/create > > > wrappers/whatever so when it was appropriate to break compatibility > they > > > would. > > > > > > > > Did they remove those packages or did they remain? > > 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. > 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. They can be hosted elsewhere and the backwards compatibility issue can still be handled. > Really. What is the problem with the extra interfaces? > > The package namespace is not ours. It's that simple G. > 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)? -- Best Regards, -- Alex
