On Tue, Feb 28, 2012 at 3:01 PM, Ate Douma <a...@douma.nu> wrote: > On 02/28/2012 01:46 PM, Mohammad Nour El-Din wrote: > >> 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. >> > > I agree. > > And specifically as this seems to concern compatibility support for > Cloudera own API, only needed for Cloudera customers. > Keeping those com.cloudera packages in the code could imply a specific > preference and affiliation with an external and commercial entity, thereby > potentially jeopardizing the project independence. > > While I don't expect there was any intend to do so, even the impression > itself can be considered harmful to the ASF and the project. > > > >> 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. >> > > That sounds reasonable and hopefully easy to do (if not this case might > even be more worrisome then). > I'm not really sure though if Apache Extras is an appropriate location > either. I think Apache Extras intends to convey an affiliation with the ASF > and probably should value project independence high as well. > If this really only concerns a thin layer to provide compatibility only > for Cloudera's API, hosting and maintenance of this should be the > responsibility of Cloudera itself.
Good point, I agree on this > > > Ate > > > >> 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/<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.zitting@gmail.** >>> com <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/<http://svn.apache.org/repos/asf/subversion/trunk/subversion/bindings/javahl/> >>> >>>> [2] >>>> http://svn.apache.org/repos/**asf/geronimo/specs/trunk/<http://svn.apache.org/repos/asf/geronimo/specs/trunk/> >>>> >>>> BR, >>>> >>>> Jukka Zitting >>>> >>>> >>>> -- >>> Best Regards, >>> -- Alex >>> >>> >> >> >> > > ------------------------------**------------------------------**--------- > To unsubscribe, e-mail: > general-unsubscribe@incubator.**apache.org<general-unsubscr...@incubator.apache.org> > For additional commands, e-mail: > general-help@incubator.apache.**org<general-h...@incubator.apache.org> > > -- Thanks - Mohammad Nour ---- "Life is like riding a bicycle. To keep your balance you must keep moving" - Albert Einstein
