On Tue, Feb 28, 2012 at 4:09 PM, Mohammad Nour El-Din < nour.moham...@gmail.com> wrote:
> 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 > > +1 > > > > > > > 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 > -- Best Regards, -- Alex
