incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mohammad Nour El-Din <nour.moham...@gmail.com>
Subject Re: [VOTE] Graduate Sqoop podling from Apache Incubator
Date Wed, 29 Feb 2012 13:58:39 GMT
Hi Alex

On Wed, Feb 29, 2012 at 2:39 PM, Alex Karasulu <akarasulu@apache.org> wrote:

> On Wed, Feb 29, 2012 at 3:07 PM, Alex Karasulu <akarasulu@apache.org>
> wrote:
>
> > On Wed, Feb 29, 2012 at 2:06 PM, Greg Stein <gstein@gmail.com> wrote:
> >
> >> On Feb 29, 2012 4:15 AM, "Alex Karasulu" <akarasulu@apache.org> wrote:
> >> >
> >> > On Wed, Feb 29, 2012 at 4:06 AM, Daniel Kulp <dkulp@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 <dkulp@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)?
> >
>
> Greg's right. Jukka was as well but for some reason I did not immediately
> get it.
>
> We cannot hold Scoop to a standard which we don't apply to other TLPs and
> this needs to be a Foundation wide policy discussion. I still think the
> practice of bundling classes and packages which are not in our namespace is
> a serious issue. I'll take this up the other discussion thread.
>
> I am withdrawing my veto and I apologize for any inconvenience this may
> have caused the Scoop community.
>

No need for any apologies at all, we are all one team and such discussions
IMHO are important and also healthy cause it helps making things clear and
more explicit which IMO makes ASF a better place to live :)


>
> --
> Best Regards,
> -- Alex
>



-- 
Thanks
- Mohammad Nour
----
"Life is like riding a bicycle. To keep your balance you must keep moving"
- Albert Einstein

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