incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@gmail.com>
Subject Re: [VOTE] Graduate Sqoop podling from Apache Incubator
Date Wed, 29 Feb 2012 12:06:04 GMT
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.

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?

Really. What is the problem with the extra interfaces?

There is no legal (trademark or copyright) problem that I'm aware of. There
is no technical problem that I'm aware of. So what is it? Why are people
all up in Sqoop's face here? Why is there some attempt at imposing
technical changes on them? What ASF-wide policy is being broken? If the
policy doesn't exist, but you think it *should*, then please state as much,
along with a resolution for the Board to consider, in order to make it
official policy. And if/when the Board *does* make it official policy, then
the graduated/TLP PMC can ensure their code base complies.

And please note: this imputed/proposed policy will affect Subversion
packaging, too. Your rationale for mandates on Sqoop package names must be
able to apply just as well to Subversion. Don't focus on just Sqoop, but
the overall Foundation-wide issue. If you send a resolution to the Board,
then it better be backed up with an explanation of why the Board should be
getting involved in Java package naming for projects across the Foundation.
The explanation should state the problem, and how the policy (via the
resolution) will solve that problem.

I see no reason for the Incubator to reverse a vote that has been
completed, and to do so in the name of some nebulous/unstated policy. It is
exactly this behavior why projects want to graduate earlier rather than
later. To escape random, misplaced imposition on communities.

-g

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