Hi... 1st of all, and I speaking about myself here, I believe this is partially my fault cause I am one of the mentors of Sqoop and I should have spotted such thing before moving the vote to general@
I totally agree with Alex, more specifically I believe this is easy to solve. There is no problem to support some features or API(s) for backward compatibility but as Alex stated it should not be part of Apache's code, more specifically when it comes to be part of a TLP's code. The solution can be like packaging this code and host it on Cloudera or even Apache Extras [1] and a note is added to Sqoop website that if users want to have backward compatibility they should use that code besides the code of Apache. Now the question is, and I ask this more specifically to the Sqoop people, Can you do this before the next board meeting, at least the extracting that code ? Cause if not I support Alex in that this vote should be cancelled and then we work out another one when Sqoop meets this criteria. Looking forward to your feedback! [1] - http://code.google.com/a/apache-extras.org/hosting/ On Tue, Feb 28, 2012 at 10:44 AM, Alex Karasulu <akaras...@apache.org>wrote: > On Tue, Feb 28, 2012 at 11:06 AM, Jukka Zitting <jukka.zitt...@gmail.com > >wrote: > > > Hi, > > > > On Tue, Feb 28, 2012 at 9:59 AM, Alex Karasulu <akaras...@apache.org> > > wrote: > > > Cloudera's compatibility issues are not our problem. These packages > need > > to > > > go. > > > > Citation needed. > > > I did not think we needed one: nor do I have one. It's common sense to me > that this causes issues. It combines the namespace of a foreign mark with > our own. We should not be releasing anything in the namespace belonging to > another entity. > > > > Without a written policy to that effect these things > > are up for each project to decide. Jarek's rationale sounds perfectly > > fine to me. > > > > > I highly respect you opinion here but I disagree regarding this argument > provided. There may be no policy to cite, and there may be examples of > where this was done before for the sake of backwards compatibility. It > still does not justify doing it. > > > > We have plenty of projects that provide such backwards compatibility > > wrappers or otherwise put stuff in non-apache namespaces for various > > reasons. See for example [1] or [2]. > > > > > Understood. Examples are solid points supporting the argument but IMHO I > think this was a mistake that opens the door to several issues. Maybe we > need some clear policy regarding the matter. I'm more than ready to be > proven wrong on this matter so long as it does not present problems down > the line for us. > > > > [1] > > > http://svn.apache.org/repos/asf/subversion/trunk/subversion/bindings/javahl/ > > [2] http://svn.apache.org/repos/asf/geronimo/specs/trunk/ > > > > BR, > > > > Jukka Zitting > > > > > -- > Best Regards, > -- Alex > -- Thanks - Mohammad Nour ---- "Life is like riding a bicycle. To keep your balance you must keep moving" - Albert Einstein
