Re: [DISCUSS] - Packages renaming and backward compatibility (was: Re: [VOTE] Graduate Sqoop podling from Apache Incubator)

[Leo Simons <ma...@leosimons.com>]

On Wed, Feb 29, 2012 at 3:00 PM, Benson Margulies <bi...@gmail.com> wrote:
> Leo, are you out there?

Hmm? Oh, this again...

Having company names or trademarks in java namespaces is a pretty
stupid convention. It gets us mess like this...

There is no policy that incubating java projects must rename to use an
org.apache namespace. There has never been such a policy. We don't
need such a policy. There's (typically/usually/knock on wood) no
legal/trademark issue. There's ample precedent of keeping 'legacy'
namespaces around 'a while' for backwards compatibility. And that's
fine.

At the same time, (incubating) projects should definitely carefully
consider whether it is reasonable to change their namespaces, how to
go about it, etc. Incubation can be a good time and/or trigger to make
such changes, especially for projects for whom backwards compatibility
isn't a big issue (yet) or that are doing a major revision as part of
coming here.

With my incubator PMC hat on, I like to see that a project community
has thought this situation through, discussed it on their dev list,
and got to some kind of consensus on what to do. I'd imagine such
plans will include a strategy for eventually having all their code end
up in an org.apache namespace or at least not in a com.<company>
namespace.

I'm sure other people said all this already, apologies for the noise,
but hey, I got prodded, so... :-)


cheerio,


Leo

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: [DISCUSS] - Packages renaming and backward compatibility (was: Re: [VOTE] Graduate Sqoop podling from Apache Incubator)

[sebb <se...@gmail.com>]

On 9 March 2012 05:42, Alex Karasulu <ak...@apache.org> wrote:
> On Fri, Mar 9, 2012 at 1:09 AM, Marvin Humphrey <ma...@rectangular.com>wrote:
>
>> On Fri, Mar 09, 2012 at 12:43:47AM +0200, Alex Karasulu wrote:
>> > On Thu, Mar 8, 2012 at 10:57 PM, Doug Cutting <cu...@apache.org>
>> wrote:
>> >
>> > > On 03/07/2012 11:31 PM, Alex Karasulu wrote:
>> > > > Not trying to beat a dead horse to death here but I'm starting to
>> think
>> > > > that we might have had some basis to these package namespace issues.
>> The
>> > > > recent private Lucene-Commons threads show what can happen if this
>> policy
>> > > > is that hmmm liberal. Don't know if that's the right choice of words.
>> > >
>> > > The differences between the cases should inform any policy.
>> > >
>> > > In one case you have the inclusion of an older package name for
>> > > back-compatibility by the same community that created the older API.
>>  In
>> > > the other case you have the inclusion of an API that conflicts with one
>> > > managed by a different, still-active community.
>> >
>> >
>> > Regardless of the situation in which this occurs the potential problem
>> is a
>> > namespace conflict. But I hear ya. The social situation is very
>> different.
>>
>> My impression was that there were two issues.
>>
>> First was the technical issue of a namespace conflict.  It seems as though
>> there may be good reasons why exceptions should be made on a case-by-case
>> basis, as Doug implies.
>>
>>
> +1
>
>
>> The second was the community issue of potentially advantaging a commercial
>> entity; this response seemed to satisfy people:
>>
>>    http://s.apache.org/mz
>>
>>
> +1
>
>
>>    In fact, Sqoop already has a plan in place to completely remove
>>    com.cloudera.* namespace from its contents via the next major revision
>> of
>>    the product. The work for that has already started and currently exists
>>    under the branch sqoop2 [3], tracked by SQOOP-365 [4]. We hope that in a
>>    few months time, we will have feature parity in this branch with the
>>    trunk, which is when we will promote it to the trunk.
>>
>> I would think that any generic policy would need to take both of those
>> issues
>> into account.
>>
>>
> I feel the Cloudera folks have benign concerns in this case and this is not
> an attempt to take advantage. As you reminded us above they're simply
> trying to facilitate compatibility to accomodate their users which is
> admirable. Also as Doug pointed out they're in control of both namespaces
> so they can handle it without conflict.
>
> However my primary point was when you start allowing this practice even
> just a little for benign, positive reasons (as is the case for Scoop), it
> can quickly lead to chaos through misuse, and result in community discord.
> It's not easy to quantify/clarify whether the usage is meant for good, used
> carelessly without consideration, or used explicitly to gain a commercial
> advantage. It's going to start ruffling feathers at some point or another
> when accusations start flying. Some folks are going to be pissed due to
> disruptions, some are going to be on a witch hunt, others are going to have
> valid concerns, some just won't care, while those accused will fight
> vehemently feeling unjustly attacked. In the end, this feels like a
> pandora's box. We just saw how damaging this can be with the recent
> Lucene/Solr incident concerning commons CSV. [Just using a reference here
> to minimise public discussion of a private list thread.]
>
> So is there a way we can allow the practice to occur at a minimal scale
> with positive gains, without the potential negative impact?
>
> My rather weak suggestion of having projects explicitly announce the cases
> where they "infringe" on another project or party's namespace just raises
> awareness and makes it so the potentially "infringing" party exposes it's
> intentions before accusations start flying. I'm sure there are better
> solutions to this problem where we minimize the administrative overhead and
> the negative impact. I just could not think of a better way at this point.

Isn't it about who owns and manages the namespace?

If the owner gives permission, then OK, otherwise not OK.

> --
> Best Regards,
> -- Alex

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: [DISCUSS] - Packages renaming and backward compatibility (was: Re: [VOTE] Graduate Sqoop podling from Apache Incubator)

[Alex Karasulu <ak...@apache.org>]

On Fri, Mar 9, 2012 at 1:09 AM, Marvin Humphrey <ma...@rectangular.com>wrote:

> On Fri, Mar 09, 2012 at 12:43:47AM +0200, Alex Karasulu wrote:
> > On Thu, Mar 8, 2012 at 10:57 PM, Doug Cutting <cu...@apache.org>
> wrote:
> >
> > > On 03/07/2012 11:31 PM, Alex Karasulu wrote:
> > > > Not trying to beat a dead horse to death here but I'm starting to
> think
> > > > that we might have had some basis to these package namespace issues.
> The
> > > > recent private Lucene-Commons threads show what can happen if this
> policy
> > > > is that hmmm liberal. Don't know if that's the right choice of words.
> > >
> > > The differences between the cases should inform any policy.
> > >
> > > In one case you have the inclusion of an older package name for
> > > back-compatibility by the same community that created the older API.
>  In
> > > the other case you have the inclusion of an API that conflicts with one
> > > managed by a different, still-active community.
> >
> >
> > Regardless of the situation in which this occurs the potential problem
> is a
> > namespace conflict. But I hear ya. The social situation is very
> different.
>
> My impression was that there were two issues.
>
> First was the technical issue of a namespace conflict.  It seems as though
> there may be good reasons why exceptions should be made on a case-by-case
> basis, as Doug implies.
>
>
+1


> The second was the community issue of potentially advantaging a commercial
> entity; this response seemed to satisfy people:
>
>    http://s.apache.org/mz
>
>
+1


>    In fact, Sqoop already has a plan in place to completely remove
>    com.cloudera.* namespace from its contents via the next major revision
> of
>    the product. The work for that has already started and currently exists
>    under the branch sqoop2 [3], tracked by SQOOP-365 [4]. We hope that in a
>    few months time, we will have feature parity in this branch with the
>    trunk, which is when we will promote it to the trunk.
>
> I would think that any generic policy would need to take both of those
> issues
> into account.
>
>
I feel the Cloudera folks have benign concerns in this case and this is not
an attempt to take advantage. As you reminded us above they're simply
trying to facilitate compatibility to accomodate their users which is
admirable. Also as Doug pointed out they're in control of both namespaces
so they can handle it without conflict.

However my primary point was when you start allowing this practice even
just a little for benign, positive reasons (as is the case for Scoop), it
can quickly lead to chaos through misuse, and result in community discord.
It's not easy to quantify/clarify whether the usage is meant for good, used
carelessly without consideration, or used explicitly to gain a commercial
advantage. It's going to start ruffling feathers at some point or another
when accusations start flying. Some folks are going to be pissed due to
disruptions, some are going to be on a witch hunt, others are going to have
valid concerns, some just won't care, while those accused will fight
vehemently feeling unjustly attacked. In the end, this feels like a
pandora's box. We just saw how damaging this can be with the recent
Lucene/Solr incident concerning commons CSV. [Just using a reference here
to minimise public discussion of a private list thread.]

So is there a way we can allow the practice to occur at a minimal scale
with positive gains, without the potential negative impact?

My rather weak suggestion of having projects explicitly announce the cases
where they "infringe" on another project or party's namespace just raises
awareness and makes it so the potentially "infringing" party exposes it's
intentions before accusations start flying. I'm sure there are better
solutions to this problem where we minimize the administrative overhead and
the negative impact. I just could not think of a better way at this point.

-- 
Best Regards,
-- Alex

Re: [DISCUSS] - Packages renaming and backward compatibility (was: Re: [VOTE] Graduate Sqoop podling from Apache Incubator)

[Marvin Humphrey <ma...@rectangular.com>]

On Fri, Mar 09, 2012 at 12:43:47AM +0200, Alex Karasulu wrote:
> On Thu, Mar 8, 2012 at 10:57 PM, Doug Cutting <cu...@apache.org> wrote:
> 
> > On 03/07/2012 11:31 PM, Alex Karasulu wrote:
> > > Not trying to beat a dead horse to death here but I'm starting to think
> > > that we might have had some basis to these package namespace issues. The
> > > recent private Lucene-Commons threads show what can happen if this policy
> > > is that hmmm liberal. Don't know if that's the right choice of words.
> >
> > The differences between the cases should inform any policy.
> >
> > In one case you have the inclusion of an older package name for
> > back-compatibility by the same community that created the older API.  In
> > the other case you have the inclusion of an API that conflicts with one
> > managed by a different, still-active community.
> 
> 
> Regardless of the situation in which this occurs the potential problem is a
> namespace conflict. But I hear ya. The social situation is very different.

My impression was that there were two issues.

First was the technical issue of a namespace conflict.  It seems as though
there may be good reasons why exceptions should be made on a case-by-case
basis, as Doug implies.

The second was the community issue of potentially advantaging a commercial
entity; this response seemed to satisfy people:

    http://s.apache.org/mz

    In fact, Sqoop already has a plan in place to completely remove
    com.cloudera.* namespace from its contents via the next major revision of
    the product. The work for that has already started and currently exists
    under the branch sqoop2 [3], tracked by SQOOP-365 [4]. We hope that in a
    few months time, we will have feature parity in this branch with the
    trunk, which is when we will promote it to the trunk.

I would think that any generic policy would need to take both of those issues
into account.

Marvin Humphrey


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: [DISCUSS] - Packages renaming and backward compatibility (was: Re: [VOTE] Graduate Sqoop podling from Apache Incubator)

[Alex Karasulu <ak...@apache.org>]

On Thu, Mar 8, 2012 at 10:57 PM, Doug Cutting <cu...@apache.org> wrote:

> On 03/07/2012 11:31 PM, Alex Karasulu wrote:
> > Not trying to beat a dead horse to death here but I'm starting to think
> > that we might have had some basis to these package namespace issues. The
> > recent private Lucene-Commons threads show what can happen if this policy
> > is that hmmm liberal. Don't know if that's the right choice of words.
>
> The differences between the cases should inform any policy.
>
> In one case you have the inclusion of an older package name for
> back-compatibility by the same community that created the older API.  In
> the other case you have the inclusion of an API that conflicts with one
> managed by a different, still-active community.


Regardless of the situation in which this occurs the potential problem is a
namespace conflict. But I hear ya. The social situation is very different.

-- 
Best Regards,
-- Alex

Re: [DISCUSS] - Packages renaming and backward compatibility (was: Re: [VOTE] Graduate Sqoop podling from Apache Incubator)

[Doug Cutting <cu...@apache.org>]

On 03/07/2012 11:31 PM, Alex Karasulu wrote:
> Not trying to beat a dead horse to death here but I'm starting to think
> that we might have had some basis to these package namespace issues. The
> recent private Lucene-Commons threads show what can happen if this policy
> is that hmmm liberal. Don't know if that's the right choice of words.

The differences between the cases should inform any policy.

In one case you have the inclusion of an older package name for
back-compatibility by the same community that created the older API.  In
the other case you have the inclusion of an API that conflicts with one
managed by a different, still-active community.

Doug

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: [DISCUSS] - Packages renaming and backward compatibility (was: Re: [VOTE] Graduate Sqoop podling from Apache Incubator)

[Benson Margulies <bi...@gmail.com>]

On Thu, Mar 8, 2012 at 11:13 AM, Alex Karasulu <ak...@apache.org> wrote:
> On Thu, Mar 8, 2012 at 6:05 PM, Benson Margulies <bi...@gmail.com>wrote:
>
>> On Thu, Mar 8, 2012 at 2:31 AM, Alex Karasulu <ak...@apache.org>
>> wrote:
>> > On Thu, Mar 1, 2012 at 3:03 AM, Leo Simons <ma...@leosimons.com> wrote:
>> >
>> >> On Wed, Feb 29, 2012 at 3:00 PM, Benson Margulies <
>> bimargulies@gmail.com>
>> >> wrote:
>> >> > Leo, are you out there?
>> >>
>> >> Hmm? Oh, this again...
>> >>
>> >> Having company names or trademarks in java namespaces is a pretty
>> >> stupid convention. It gets us mess like this...
>> >>
>> >> There is no policy that incubating java projects must rename to use an
>> >> org.apache namespace. There has never been such a policy. We don't
>> >> need such a policy. There's (typically/usually/knock on wood) no
>> >> legal/trademark issue. There's ample precedent of keeping 'legacy'
>> >> namespaces around 'a while' for backwards compatibility. And that's
>> >> fine.
>> >>
>> >> At the same time, (incubating) projects should definitely carefully
>> >> consider whether it is reasonable to change their namespaces, how to
>> >> go about it, etc. Incubation can be a good time and/or trigger to make
>> >> such changes, especially for projects for whom backwards compatibility
>> >> isn't a big issue (yet) or that are doing a major revision as part of
>> >> coming here.
>> >>
>> >> With my incubator PMC hat on, I like to see that a project community
>> >> has thought this situation through, discussed it on their dev list,
>> >> and got to some kind of consensus on what to do. I'd imagine such
>> >> plans will include a strategy for eventually having all their code end
>> >> up in an org.apache namespace or at least not in a com.<company>
>> >> namespace.
>> >>
>> >> I'm sure other people said all this already, apologies for the noise,
>> >> but hey, I got prodded, so... :-)
>> >>
>> >>
>> >> cheerio,
>> >>
>> >>
>> >> Leo
>> >>
>> >>
>> >
>> > Not trying to beat a dead horse to death here but I'm starting to think
>> > that we might have had some basis to these package namespace issues. The
>> > recent private Lucene-Commons threads show what can happen if this policy
>> > is that hmmm liberal. Don't know if that's the right choice of words.
>>
>> Alex, there's an educational opportunity out there, yes.
>>
>
> Indeed. It might be a good idea perhaps to have every project at a minimum
> publish an informative section on their site listing any kind of intrusion
> into package spaces that are not "owned" by the project.
>
> This way at a minimum there is some awareness.

The first problem we have here is that various well-meaning people
don't understand the interactions of maven publication, TLP turf, and
classpath management. Policy/practical advice on this could come out
of commdev and then the incubator could merely be in the business of
pushing people to it.



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

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: [DISCUSS] - Packages renaming and backward compatibility (was: Re: [VOTE] Graduate Sqoop podling from Apache Incubator)

[Alex Karasulu <ak...@apache.org>]

On Thu, Mar 8, 2012 at 6:05 PM, Benson Margulies <bi...@gmail.com>wrote:

> On Thu, Mar 8, 2012 at 2:31 AM, Alex Karasulu <ak...@apache.org>
> wrote:
> > On Thu, Mar 1, 2012 at 3:03 AM, Leo Simons <ma...@leosimons.com> wrote:
> >
> >> On Wed, Feb 29, 2012 at 3:00 PM, Benson Margulies <
> bimargulies@gmail.com>
> >> wrote:
> >> > Leo, are you out there?
> >>
> >> Hmm? Oh, this again...
> >>
> >> Having company names or trademarks in java namespaces is a pretty
> >> stupid convention. It gets us mess like this...
> >>
> >> There is no policy that incubating java projects must rename to use an
> >> org.apache namespace. There has never been such a policy. We don't
> >> need such a policy. There's (typically/usually/knock on wood) no
> >> legal/trademark issue. There's ample precedent of keeping 'legacy'
> >> namespaces around 'a while' for backwards compatibility. And that's
> >> fine.
> >>
> >> At the same time, (incubating) projects should definitely carefully
> >> consider whether it is reasonable to change their namespaces, how to
> >> go about it, etc. Incubation can be a good time and/or trigger to make
> >> such changes, especially for projects for whom backwards compatibility
> >> isn't a big issue (yet) or that are doing a major revision as part of
> >> coming here.
> >>
> >> With my incubator PMC hat on, I like to see that a project community
> >> has thought this situation through, discussed it on their dev list,
> >> and got to some kind of consensus on what to do. I'd imagine such
> >> plans will include a strategy for eventually having all their code end
> >> up in an org.apache namespace or at least not in a com.<company>
> >> namespace.
> >>
> >> I'm sure other people said all this already, apologies for the noise,
> >> but hey, I got prodded, so... :-)
> >>
> >>
> >> cheerio,
> >>
> >>
> >> Leo
> >>
> >>
> >
> > Not trying to beat a dead horse to death here but I'm starting to think
> > that we might have had some basis to these package namespace issues. The
> > recent private Lucene-Commons threads show what can happen if this policy
> > is that hmmm liberal. Don't know if that's the right choice of words.
>
> Alex, there's an educational opportunity out there, yes.
>

Indeed. It might be a good idea perhaps to have every project at a minimum
publish an informative section on their site listing any kind of intrusion
into package spaces that are not "owned" by the project.

This way at a minimum there is some awareness.

-- 
Best Regards,
-- Alex

Re: [DISCUSS] - Packages renaming and backward compatibility (was: Re: [VOTE] Graduate Sqoop podling from Apache Incubator)

[Benson Margulies <bi...@gmail.com>]

On Thu, Mar 8, 2012 at 2:31 AM, Alex Karasulu <ak...@apache.org> wrote:
> On Thu, Mar 1, 2012 at 3:03 AM, Leo Simons <ma...@leosimons.com> wrote:
>
>> On Wed, Feb 29, 2012 at 3:00 PM, Benson Margulies <bi...@gmail.com>
>> wrote:
>> > Leo, are you out there?
>>
>> Hmm? Oh, this again...
>>
>> Having company names or trademarks in java namespaces is a pretty
>> stupid convention. It gets us mess like this...
>>
>> There is no policy that incubating java projects must rename to use an
>> org.apache namespace. There has never been such a policy. We don't
>> need such a policy. There's (typically/usually/knock on wood) no
>> legal/trademark issue. There's ample precedent of keeping 'legacy'
>> namespaces around 'a while' for backwards compatibility. And that's
>> fine.
>>
>> At the same time, (incubating) projects should definitely carefully
>> consider whether it is reasonable to change their namespaces, how to
>> go about it, etc. Incubation can be a good time and/or trigger to make
>> such changes, especially for projects for whom backwards compatibility
>> isn't a big issue (yet) or that are doing a major revision as part of
>> coming here.
>>
>> With my incubator PMC hat on, I like to see that a project community
>> has thought this situation through, discussed it on their dev list,
>> and got to some kind of consensus on what to do. I'd imagine such
>> plans will include a strategy for eventually having all their code end
>> up in an org.apache namespace or at least not in a com.<company>
>> namespace.
>>
>> I'm sure other people said all this already, apologies for the noise,
>> but hey, I got prodded, so... :-)
>>
>>
>> cheerio,
>>
>>
>> Leo
>>
>>
>
> Not trying to beat a dead horse to death here but I'm starting to think
> that we might have had some basis to these package namespace issues. The
> recent private Lucene-Commons threads show what can happen if this policy
> is that hmmm liberal. Don't know if that's the right choice of words.

Alex, there's an educational opportunity out there, yes.


>
> Best,
> Alex

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: [DISCUSS] - Packages renaming and backward compatibility (was: Re: [VOTE] Graduate Sqoop podling from Apache Incubator)

[Alex Karasulu <ak...@apache.org>]

On Thu, Mar 1, 2012 at 3:03 AM, Leo Simons <ma...@leosimons.com> wrote:

> On Wed, Feb 29, 2012 at 3:00 PM, Benson Margulies <bi...@gmail.com>
> wrote:
> > Leo, are you out there?
>
> Hmm? Oh, this again...
>
> Having company names or trademarks in java namespaces is a pretty
> stupid convention. It gets us mess like this...
>
> There is no policy that incubating java projects must rename to use an
> org.apache namespace. There has never been such a policy. We don't
> need such a policy. There's (typically/usually/knock on wood) no
> legal/trademark issue. There's ample precedent of keeping 'legacy'
> namespaces around 'a while' for backwards compatibility. And that's
> fine.
>
> At the same time, (incubating) projects should definitely carefully
> consider whether it is reasonable to change their namespaces, how to
> go about it, etc. Incubation can be a good time and/or trigger to make
> such changes, especially for projects for whom backwards compatibility
> isn't a big issue (yet) or that are doing a major revision as part of
> coming here.
>
> With my incubator PMC hat on, I like to see that a project community
> has thought this situation through, discussed it on their dev list,
> and got to some kind of consensus on what to do. I'd imagine such
> plans will include a strategy for eventually having all their code end
> up in an org.apache namespace or at least not in a com.<company>
> namespace.
>
> I'm sure other people said all this already, apologies for the noise,
> but hey, I got prodded, so... :-)
>
>
> cheerio,
>
>
> Leo
>
>

Not trying to beat a dead horse to death here but I'm starting to think
that we might have had some basis to these package namespace issues. The
recent private Lucene-Commons threads show what can happen if this policy
is that hmmm liberal. Don't know if that's the right choice of words.

Best,
Alex