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 Tue, 28 Feb 2012 14:15:51 GMT
On Tue, Feb 28, 2012 at 4:09 PM, Mohammad Nour El-Din <
nour.mohammad@gmail.com> wrote:

> On Tue, Feb 28, 2012 at 3:01 PM, Ate Douma <ate@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<akarasulu@apache.org>**
> >> wrote:
> >>
> >>  On Tue, Feb 28, 2012 at 11:06 AM, Jukka Zitting<jukka.zitting@gmail.**
> >>> com <jukka.zitting@gmail.com>
> >>>
> >>>> wrote:
> >>>>
> >>>
> >>>  Hi,
> >>>>
> >>>> On Tue, Feb 28, 2012 at 9:59 AM, Alex Karasulu<akarasulu@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-unsubscribe@incubator.apache.org>
> > For additional commands, e-mail: general-help@incubator.apache.**org<
> general-help@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

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