Re: [DISCUSS] - Packages renaming and backward compatibility (was: Re: [VOTE] Graduate Sqoop podling from Apache Incubator)
On 9 March 2012 05:42, Alex Karasulu akaras...@apache.org wrote: On Fri, Mar 9, 2012 at 1:09 AM, Marvin Humphrey mar...@rectangular.comwrote: On Fri, Mar 09, 2012 at 12:43:47AM +0200, Alex Karasulu wrote: On Thu, Mar 8, 2012 at 10:57 PM, Doug Cutting cutt...@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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] - Packages renaming and backward compatibility (was: Re: [VOTE] Graduate Sqoop podling from Apache Incubator)
On Thu, Mar 8, 2012 at 2:31 AM, Alex Karasulu akaras...@apache.org wrote: On Thu, Mar 1, 2012 at 3:03 AM, Leo Simons m...@leosimons.com wrote: On Wed, Feb 29, 2012 at 3:00 PM, Benson Margulies bimargul...@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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] - Packages renaming and backward compatibility (was: Re: [VOTE] Graduate Sqoop podling from Apache Incubator)
On Thu, Mar 8, 2012 at 6:05 PM, Benson Margulies bimargul...@gmail.comwrote: On Thu, Mar 8, 2012 at 2:31 AM, Alex Karasulu akaras...@apache.org wrote: On Thu, Mar 1, 2012 at 3:03 AM, Leo Simons m...@leosimons.com wrote: On Wed, Feb 29, 2012 at 3:00 PM, Benson Margulies bimargul...@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)
On Thu, Mar 8, 2012 at 11:13 AM, Alex Karasulu akaras...@apache.org wrote: On Thu, Mar 8, 2012 at 6:05 PM, Benson Margulies bimargul...@gmail.comwrote: On Thu, Mar 8, 2012 at 2:31 AM, Alex Karasulu akaras...@apache.org wrote: On Thu, Mar 1, 2012 at 3:03 AM, Leo Simons m...@leosimons.com wrote: On Wed, Feb 29, 2012 at 3:00 PM, Benson Margulies bimargul...@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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] - Packages renaming and backward compatibility (was: Re: [VOTE] Graduate Sqoop podling from Apache Incubator)
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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] - Packages renaming and backward compatibility (was: Re: [VOTE] Graduate Sqoop podling from Apache Incubator)
On Thu, Mar 8, 2012 at 10:57 PM, Doug Cutting cutt...@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)
On Fri, Mar 09, 2012 at 12:43:47AM +0200, Alex Karasulu wrote: On Thu, Mar 8, 2012 at 10:57 PM, Doug Cutting cutt...@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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] - Packages renaming and backward compatibility (was: Re: [VOTE] Graduate Sqoop podling from Apache Incubator)
On Fri, Mar 9, 2012 at 1:09 AM, Marvin Humphrey mar...@rectangular.comwrote: On Fri, Mar 09, 2012 at 12:43:47AM +0200, Alex Karasulu wrote: On Thu, Mar 8, 2012 at 10:57 PM, Doug Cutting cutt...@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)
On Thu, Mar 1, 2012 at 3:03 AM, Leo Simons m...@leosimons.com wrote: On Wed, Feb 29, 2012 at 3:00 PM, Benson Margulies bimargul...@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
[DISCUSS] - Packages renaming and backward compatibility (was: Re: [VOTE] Graduate Sqoop podling from Apache Incubator)
I don't see that this getting to any clear end yet. So I suggest that we take this from a Sqoop instance to be a discussion on rules them selves. I would like to start a [VOTE] about whether it is a *must* for podlings to rename all packages before being a TLP or not over keeping the old package names for backward compatibility. What ever the consensus going to be built we definitely need to update the Incubator documents to clear this kind of issue. But before starting the vote I would like to consider others' opinions. Thoughts ? On Wed, Feb 29, 2012 at 10:33 AM, Alex Karasulu akaras...@apache.orgwrote: On Wed, Feb 29, 2012 at 2:40 AM, Patrick Hunt ph...@apache.org wrote: On Tue, Feb 28, 2012 at 4:02 PM, Mohammad Nour El-Din nour.moham...@gmail.com wrote: On the other hand, I totally respect that Cloudera's interest to support their customers and provide backword compatibility, but this is *not* the point at all, the point is this *should* not, and even allow me to say this is *must* not be the problem of Apache, and yes I agree with the opinion that this is a matter to be decided by Sqoop team but not to make Apache's problem. So also let not get more into this!!! Or course this is Apache's problem. You can't have your cake and eat it too. If you accept code for a project you accept the community as well. Say Apache accepts a project like Open Office, should we ignore the existing community and not concern ourselves with backward compatibility for that project as well, because the original code wasn't birthed at Apache? That's a very slippery slope. Maybe some projects get way too much leeway because of the big flashing lights. Regardless of how big the press headlines are all projects should be held to the same standard. No project should be allowed to graduate without solving all issues pertaining to marks. It's a failure of the incubator in the past for allowing other projects to do so. I'm shocked it was allowed. -- Best Regards, -- Alex -- Thanks - Mohammad Nour Life is like riding a bicycle. To keep your balance you must keep moving - Albert Einstein
Re: [DISCUSS] - Packages renaming and backward compatibility (was: Re: [VOTE] Graduate Sqoop podling from Apache Incubator)
Yes I did, and thanks for clarification :), and please read my as well :). Thanks. On Wed, Feb 29, 2012 at 1:15 PM, Greg Stein gst...@gmail.com wrote: Has nothing to do with incubation. You're talking about Foundation-wide policy. You cannot impose different naming rules on podlings, than what is imposed on TLPs. Please see my response in the original thread. You need a Board resolution and rationale. -g On Feb 29, 2012 5:03 AM, Mohammad Nour El-Din nour.moham...@gmail.com wrote: I don't see that this getting to any clear end yet. So I suggest that we take this from a Sqoop instance to be a discussion on rules them selves. I would like to start a [VOTE] about whether it is a *must* for podlings to rename all packages before being a TLP or not over keeping the old package names for backward compatibility. What ever the consensus going to be built we definitely need to update the Incubator documents to clear this kind of issue. But before starting the vote I would like to consider others' opinions. Thoughts ? On Wed, Feb 29, 2012 at 10:33 AM, Alex Karasulu akaras...@apache.org wrote: On Wed, Feb 29, 2012 at 2:40 AM, Patrick Hunt ph...@apache.org wrote: On Tue, Feb 28, 2012 at 4:02 PM, Mohammad Nour El-Din nour.moham...@gmail.com wrote: On the other hand, I totally respect that Cloudera's interest to support their customers and provide backword compatibility, but this is *not* the point at all, the point is this *should* not, and even allow me to say this is *must* not be the problem of Apache, and yes I agree with the opinion that this is a matter to be decided by Sqoop team but not to make Apache's problem. So also let not get more into this!!! Or course this is Apache's problem. You can't have your cake and eat it too. If you accept code for a project you accept the community as well. Say Apache accepts a project like Open Office, should we ignore the existing community and not concern ourselves with backward compatibility for that project as well, because the original code wasn't birthed at Apache? That's a very slippery slope. Maybe some projects get way too much leeway because of the big flashing lights. Regardless of how big the press headlines are all projects should be held to the same standard. No project should be allowed to graduate without solving all issues pertaining to marks. It's a failure of the incubator in the past for allowing other projects to do so. I'm shocked it was allowed. -- Best Regards, -- Alex -- Thanks - Mohammad Nour Life is like riding a bicycle. To keep your balance you must keep moving - Albert Einstein -- Thanks - Mohammad Nour Life is like riding a bicycle. To keep your balance you must keep moving - Albert Einstein
Re: [DISCUSS] - Packages renaming and backward compatibility (was: Re: [VOTE] Graduate Sqoop podling from Apache Incubator)
strictly -1 for forcing a name change on graduation. That would just cause additional overhead without any benefit. LieGrue, strub - Original Message - From: Greg Stein gst...@gmail.com To: general@incubator.apache.org Cc: Sent: Wednesday, February 29, 2012 1:15 PM Subject: Re: [DISCUSS] - Packages renaming and backward compatibility (was: Re: [VOTE] Graduate Sqoop podling from Apache Incubator) Has nothing to do with incubation. You're talking about Foundation-wide policy. You cannot impose different naming rules on podlings, than what is imposed on TLPs. Please see my response in the original thread. You need a Board resolution and rationale. -g On Feb 29, 2012 5:03 AM, Mohammad Nour El-Din nour.moham...@gmail.com wrote: I don't see that this getting to any clear end yet. So I suggest that we take this from a Sqoop instance to be a discussion on rules them selves. I would like to start a [VOTE] about whether it is a *must* for podlings to rename all packages before being a TLP or not over keeping the old package names for backward compatibility. What ever the consensus going to be built we definitely need to update the Incubator documents to clear this kind of issue. But before starting the vote I would like to consider others' opinions. Thoughts ? On Wed, Feb 29, 2012 at 10:33 AM, Alex Karasulu akaras...@apache.org wrote: On Wed, Feb 29, 2012 at 2:40 AM, Patrick Hunt ph...@apache.org wrote: On Tue, Feb 28, 2012 at 4:02 PM, Mohammad Nour El-Din nour.moham...@gmail.com wrote: On the other hand, I totally respect that Cloudera's interest to support their customers and provide backword compatibility, but this is *not* the point at all, the point is this *should* not, and even allow me to say this is *must* not be the problem of Apache, and yes I agree with the opinion that this is a matter to be decided by Sqoop team but not to make Apache's problem. So also let not get more into this!!! Or course this is Apache's problem. You can't have your cake and eat it too. If you accept code for a project you accept the community as well. Say Apache accepts a project like Open Office, should we ignore the existing community and not concern ourselves with backward compatibility for that project as well, because the original code wasn't birthed at Apache? That's a very slippery slope. Maybe some projects get way too much leeway because of the big flashing lights. Regardless of how big the press headlines are all projects should be held to the same standard. No project should be allowed to graduate without solving all issues pertaining to marks. It's a failure of the incubator in the past for allowing other projects to do so. I'm shocked it was allowed. -- Best Regards, -- Alex -- Thanks - Mohammad Nour Life is like riding a bicycle. To keep your balance you must keep moving - Albert Einstein - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] - Packages renaming and backward compatibility (was: Re: [VOTE] Graduate Sqoop podling from Apache Incubator)
-1 here. On Wed, Feb 29, 2012 at 7:38 AM, Mark Struberg strub...@yahoo.de wrote: strictly -1 for forcing a name change on graduation. That would just cause additional overhead without any benefit. LieGrue, strub - Original Message - From: Greg Stein gst...@gmail.com To: general@incubator.apache.org Cc: Sent: Wednesday, February 29, 2012 1:15 PM Subject: Re: [DISCUSS] - Packages renaming and backward compatibility (was: Re: [VOTE] Graduate Sqoop podling from Apache Incubator) Has nothing to do with incubation. You're talking about Foundation-wide policy. You cannot impose different naming rules on podlings, than what is imposed on TLPs. Please see my response in the original thread. You need a Board resolution and rationale. -g On Feb 29, 2012 5:03 AM, Mohammad Nour El-Din nour.moham...@gmail.com wrote: I don't see that this getting to any clear end yet. So I suggest that we take this from a Sqoop instance to be a discussion on rules them selves. I would like to start a [VOTE] about whether it is a *must* for podlings to rename all packages before being a TLP or not over keeping the old package names for backward compatibility. What ever the consensus going to be built we definitely need to update the Incubator documents to clear this kind of issue. But before starting the vote I would like to consider others' opinions. Thoughts ? On Wed, Feb 29, 2012 at 10:33 AM, Alex Karasulu akaras...@apache.org wrote: On Wed, Feb 29, 2012 at 2:40 AM, Patrick Hunt ph...@apache.org wrote: On Tue, Feb 28, 2012 at 4:02 PM, Mohammad Nour El-Din nour.moham...@gmail.com wrote: On the other hand, I totally respect that Cloudera's interest to support their customers and provide backword compatibility, but this is *not* the point at all, the point is this *should* not, and even allow me to say this is *must* not be the problem of Apache, and yes I agree with the opinion that this is a matter to be decided by Sqoop team but not to make Apache's problem. So also let not get more into this!!! Or course this is Apache's problem. You can't have your cake and eat it too. If you accept code for a project you accept the community as well. Say Apache accepts a project like Open Office, should we ignore the existing community and not concern ourselves with backward compatibility for that project as well, because the original code wasn't birthed at Apache? That's a very slippery slope. Maybe some projects get way too much leeway because of the big flashing lights. Regardless of how big the press headlines are all projects should be held to the same standard. No project should be allowed to graduate without solving all issues pertaining to marks. It's a failure of the incubator in the past for allowing other projects to do so. I'm shocked it was allowed. -- Best Regards, -- Alex -- Thanks - Mohammad Nour Life is like riding a bicycle. To keep your balance you must keep moving - Albert Einstein - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] - Packages renaming and backward compatibility (was: Re: [VOTE] Graduate Sqoop podling from Apache Incubator)
On Wed, Feb 29, 2012 at 2:38 PM, Mark Struberg strub...@yahoo.de wrote: strictly -1 for forcing a name change on graduation. Maybe we have some confusion here. No one is talking about changing the name of the podling. The discussion pertains to the presence of com.cloudera packages in the source code of a podling for the sake of backwards compatibility with Cloudera products. -- Best Regards, -- Alex
Re: [DISCUSS] - Packages renaming and backward compatibility (was: Re: [VOTE] Graduate Sqoop podling from Apache Incubator)
On Wed, Feb 29, 2012 at 2:15 PM, Greg Stein gst...@gmail.com wrote: Has nothing to do with incubation. You're talking about Foundation-wide policy. You cannot impose different naming rules on podlings, than what is imposed on TLPs. Please see my response in the original thread. You need a Board resolution and rationale. I'm glad you phrased it like this. It totally takes us out of the scope of the perceived problem. As you say you have to apply the same rules until policies change, if they change. You're amazingly cogent dude! It's a strong argument that I can't disagree with even though I am convinced the perceived problem is quite serious. I'll withdraw my veto on the other VOTE thread but I really want to evaluate this in this discussion thread. -- Best Regards, -- Alex
Re: [DISCUSS] - Packages renaming and backward compatibility (was: Re: [VOTE] Graduate Sqoop podling from Apache Incubator)
On 29/02/12 10:02, Mohammad Nour El-Din wrote: I don't see that this getting to any clear end yet. So I suggest that we take this from a Sqoop instance to be a discussion on rules them selves. I would like to start a [VOTE] about whether it is a *must* for podlings to rename all packages before being a TLP or not over keeping the old package names for backward compatibility. What ever the consensus going to be built we definitely need to update the Incubator documents to clear this kind of issue. But before starting the vote I would like to consider others' opinions. Thoughts ? In the case of Apache Jena (incubating), we have more than ten years' worth of existence as an open-source project. In that time, there have been countless tutorials, articles, research papers, code snippets, books and add-on tools that make use of Jena code in the com.hp namespace. But Jena was never an HP *product*, it was an output from the HP research lab in the UK. Our intention as Apache project has been much like Sqoop's: to migrate to org.apache names but keep a compatibility layer in place. We had thought that migration wasn't necessary for graduation, but if it is, no biggie. What would be problematic for our community is if we can't host the compatibility layer packages *at all* under Apache. If we have to expunge all references to com.hp.* packages, then all that back-catalogue of tutorials etc will be instantly obsolete ... unless folks know to go and separately download the jena-compatibility package from SourceForge or wherever it would hypothetically end up. Some of the discussion around Sqoop has been that the backwards-compatibility requirement is all about Cloudera's customers so it's Cloudera's problem. In the case of Jena, it has never been about HP's customers, and it definitely isn't HP's problem since none of the current committers work there any more. Ian - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] - Packages renaming and backward compatibility (was: Re: [VOTE] Graduate Sqoop podling from Apache Incubator)
On Wed, Feb 29, 2012 at 2:32 PM, Alex Karasulu akaras...@apache.org wrote: On Wed, Feb 29, 2012 at 2:15 PM, Greg Stein gst...@gmail.com wrote: Has nothing to do with incubation. You're talking about Foundation-wide policy. You cannot impose different naming rules on podlings, than what is imposed on TLPs. Please see my response in the original thread. You need a Board resolution and rationale. I'm glad you phrased it like this. It totally takes us out of the scope of the perceived problem. As you say you have to apply the same rules until policies change, if they change. You're amazingly cogent dude! It's a strong argument that I can't disagree with even though I am convinced the perceived problem is quite serious. I'll withdraw my veto on the other VOTE thread but I really want to evaluate this in this discussion thread. I agree with this, I believe that Sqoop deserve to be graduated for a lot of reasons and even the discussion in hand it is not all their fault it is fault of Mentors and a problem of lacking of clear information about such situation, so IMO as I explained before we proceed with the vote and bring that issue in a more general ASF wide level. -- Best Regards, -- Alex -- Thanks - Mohammad Nour Life is like riding a bicycle. To keep your balance you must keep moving - Albert Einstein
Re: [DISCUSS] - Packages renaming and backward compatibility (was: Re: [VOTE] Graduate Sqoop podling from Apache Incubator)
On Wed, Feb 29, 2012 at 3:35 PM, Mohammad Nour El-Din nour.moham...@gmail.com wrote: On Wed, Feb 29, 2012 at 2:32 PM, Alex Karasulu akaras...@apache.org wrote: On Wed, Feb 29, 2012 at 2:15 PM, Greg Stein gst...@gmail.com wrote: Has nothing to do with incubation. You're talking about Foundation-wide policy. You cannot impose different naming rules on podlings, than what is imposed on TLPs. Please see my response in the original thread. You need a Board resolution and rationale. I'm glad you phrased it like this. It totally takes us out of the scope of the perceived problem. As you say you have to apply the same rules until policies change, if they change. You're amazingly cogent dude! It's a strong argument that I can't disagree with even though I am convinced the perceived problem is quite serious. I'll withdraw my veto on the other VOTE thread but I really want to evaluate this in this discussion thread. I agree with this, I believe that Sqoop deserve to be graduated for a lot of reasons and even the discussion in hand it is not all their fault it is fault of Mentors and a problem of lacking of clear information about such situation, so IMO as I explained before we proceed with the vote and bring that issue in a more general ASF wide level. Yep you did say that at first and you were right. It just takes a while for me to absorb ;). -- Best Regards, -- Alex
Re: [DISCUSS] - Packages renaming and backward compatibility (was: Re: [VOTE] Graduate Sqoop podling from Apache Incubator)
On Wed, Feb 29, 2012 at 3:32 PM, Alex Karasulu akaras...@apache.org wrote: On Wed, Feb 29, 2012 at 2:15 PM, Greg Stein gst...@gmail.com wrote: Has nothing to do with incubation. You're talking about Foundation-wide policy. You cannot impose different naming rules on podlings, than what is imposed on TLPs. Please see my response in the original thread. You need a Board resolution and rationale. I'm glad you phrased it like this. It totally takes us out of the scope of the perceived problem. As you say you have to apply the same rules until policies change, if they change. You're amazingly cogent dude! It's a strong argument that I can't disagree with even though I am convinced the perceived problem is quite serious. I'll withdraw my veto on the other VOTE thread but I really want to evaluate this in this discussion thread. OK to get back on track with this discussion I've taken a snippet from the original thread and pasted it here: 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)? I'd like to approach it by answering this question. Because if we look at it like this then we'll start seeing the issues this could cause. -- Best Regards, -- Alex
Re: [DISCUSS] - Packages renaming and backward compatibility (was: Re: [VOTE] Graduate Sqoop podling from Apache Incubator)
On Feb 29, 2012 8:45 AM, Alex Karasulu akaras...@apache.org wrote: ... OK do we have the right to create any kind of package or class under com.cloudera (or any other companies packages)? I'd like to approach it by answering this question. Because if we look at it like this then we'll start seeing the issues this could cause. My rather snarky reply is in the other thread :-P ... my cut/paste is poor on this tablet, so if you could haul it over here Thanks, -g
Re: [DISCUSS] - Packages renaming and backward compatibility (was: Re: [VOTE] Graduate Sqoop podling from Apache Incubator)
Hi... On Wed, Feb 29, 2012 at 2:44 PM, Alex Karasulu akaras...@apache.org wrote: On Wed, Feb 29, 2012 at 3:32 PM, Alex Karasulu akaras...@apache.org wrote: On Wed, Feb 29, 2012 at 2:15 PM, Greg Stein gst...@gmail.com wrote: Has nothing to do with incubation. You're talking about Foundation-wide policy. You cannot impose different naming rules on podlings, than what is imposed on TLPs. Please see my response in the original thread. You need a Board resolution and rationale. I'm glad you phrased it like this. It totally takes us out of the scope of the perceived problem. As you say you have to apply the same rules until policies change, if they change. You're amazingly cogent dude! It's a strong argument that I can't disagree with even though I am convinced the perceived problem is quite serious. I'll withdraw my veto on the other VOTE thread but I really want to evaluate this in this discussion thread. OK to get back on track with this discussion I've taken a snippet from the original thread and pasted it here: 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)? I'd like to approach it by answering this question. Because if we look at it like this then we'll start seeing the issues this could cause. That is a good question! -- Best Regards, -- Alex -- Thanks - Mohammad Nour Life is like riding a bicycle. To keep your balance you must keep moving - Albert Einstein
Re: [DISCUSS] - Packages renaming and backward compatibility (was: Re: [VOTE] Graduate Sqoop podling from Apache Incubator)
I don't think it's a good question. I think that it is typical of the sort of hypothetical question which leads to heaps of scorn from Sam. I can imagine circumstances where it would make some sense, and some cases where it would be evidence of a serious problem in a TLP. The Foundation is supposed, I claim, to be about basic principles and common sense, not endless picayune legislation. It seems common-sensical that nearly any Java code created at the foundation would be in an org.apache package -- but there's no point to trying to chisel this into tablets as opposed to expecting people to understand the general principles we're about here. Leo, are you out there? - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] - Packages renaming and backward compatibility (was: Re: [VOTE] Graduate Sqoop podling from Apache Incubator)
On Feb 29, 2012 8:34 AM, Ian Dickinson i...@epimorphics.com wrote: On 29/02/12 10:02, Mohammad Nour El-Din wrote: I don't see that this getting to any clear end yet. So I suggest that we take this from a Sqoop instance to be a discussion on rules them selves. I would like to start a [VOTE] about whether it is a *must* for podlings to rename all packages before being a TLP or not over keeping the old package names for backward compatibility. What ever the consensus going to be built we definitely need to update the Incubator documents to clear this kind of issue. But before starting the vote I would like to consider others' opinions. Thoughts ? In the case of Apache Jena (incubating), we have more than ten years' worth of existence as an open-source project. In that time, there have been countless tutorials, articles, research papers, code snippets, books and add-on tools that make use of Jena code in the com.hp namespace. But Jena was never an HP *product*, it was an output from the HP research lab in the UK. Our intention as Apache project has been much like Sqoop's: to migrate to org.apache names but keep a compatibility layer in place. We had thought that migration wasn't necessary for graduation, but if it is, no biggie. What would be problematic for our community is if we can't host the compatibility layer packages *at all* under Apache. If we have to expunge all references to com.hp.* packages, then all that back-catalogue of tutorials etc will be instantly obsolete ... unless folks know to go and separately download the jena-compatibility package from SourceForge or wherever it would hypothetically end up. Some of the discussion around Sqoop has been that the backwards-compatibility requirement is all about Cloudera's customers so it's Cloudera's problem. In the case of Jena, it has never been about HP's customers, and it definitely isn't HP's problem since none of the current committers work there any more. For Subversion, Craig Russell was concentrating on this aspect while we were incubating. He basically said, no problem with graduation, as long as you have a plan in place. He followed up with an email about 18 months after graduation, and I replied, yup, all moved over. Moving to org.apache.subversion gave us an opportunity to revamp our interfaces based on what we had learned from the first go-round in org.tigris.subversion. So we have the new hot interfaces under o.a.s, and the compat layer under o.t.s. Works great. Cheers, -g
Re: [DISCUSS] - Packages renaming and backward compatibility (was: Re: [VOTE] Graduate Sqoop podling from Apache Incubator)
On Wed, Feb 29, 2012 at 3:54 PM, Greg Stein gst...@gmail.com wrote: On Feb 29, 2012 8:45 AM, Alex Karasulu akaras...@apache.org wrote: ... OK do we have the right to create any kind of package or class under com.cloudera (or any other companies packages)? I'd like to approach it by answering this question. Because if we look at it like this then we'll start seeing the issues this could cause. My rather snarky reply is in the other thread :-P Indeed :). ... my cut/paste is poor on this tablet, so if you could haul it over here Done. -- Best Regards, -- Alex
Re: [DISCUSS] - Packages renaming and backward compatibility (was: Re: [VOTE] Graduate Sqoop podling from Apache Incubator)
On Wed, Feb 29, 2012 at 4:00 PM, Benson Margulies bimargul...@gmail.comwrote: I don't think it's a good question. I think that it is typical of the sort of hypothetical question which leads to heaps of scorn from Sam. Please! Don't invoke Sam :). Jokes aside take a look the my last two posts on the original thread. -- Best Regards, -- Alex
Re: [DISCUSS] - Packages renaming and backward compatibility (was: Re: [VOTE] Graduate Sqoop podling from Apache Incubator)
As another point of reference, there is at least one case I'm aware of where we HAD to put some code developed at Apache into non-org.apache namespace in order for the code to work. This was taken up on legal discuss and, at the time, no issues about doing so were raised. See: http://s.apache.org/WzP And the CXF bug: https://issues.apache.org/jira/browse/CXF-1880 In this case, it was new code developed at Apache and in the org.apache.cxf namespace, but in order for the code to actual work, there were shims necessary in com.sun.Now, this is a slightly different case in that no end-users would likely ever call (or really even see) this code. It's just need to plugin into an external tool. So, IMO, code at Apache SHOULD be developed in the org.apache namespace, but projects need to be able to have some flexibility to use their judgment to figure out what is best for the needs of their community. Projects should be encouraged to keep code outside org.apache to a minimum via shims or similar and also encourage end users to migrate to using the code in the org.apache namespace as soon as possible. Dan On Wednesday, February 29, 2012 11:02:33 AM Mohammad Nour El-Din wrote: I don't see that this getting to any clear end yet. So I suggest that we take this from a Sqoop instance to be a discussion on rules them selves. I would like to start a [VOTE] about whether it is a *must* for podlings to rename all packages before being a TLP or not over keeping the old package names for backward compatibility. What ever the consensus going to be built we definitely need to update the Incubator documents to clear this kind of issue. But before starting the vote I would like to consider others' opinions. Thoughts ? On Wed, Feb 29, 2012 at 10:33 AM, Alex Karasulu akaras...@apache.orgwrote: On Wed, Feb 29, 2012 at 2:40 AM, Patrick Hunt ph...@apache.org wrote: On Tue, Feb 28, 2012 at 4:02 PM, Mohammad Nour El-Din nour.moham...@gmail.com wrote: On the other hand, I totally respect that Cloudera's interest to support their customers and provide backword compatibility, but this is *not* the point at all, the point is this *should* not, and even allow me to say this is *must* not be the problem of Apache, and yes I agree with the opinion that this is a matter to be decided by Sqoop team but not to make Apache's problem. So also let not get more into this!!! Or course this is Apache's problem. You can't have your cake and eat it too. If you accept code for a project you accept the community as well. Say Apache accepts a project like Open Office, should we ignore the existing community and not concern ourselves with backward compatibility for that project as well, because the original code wasn't birthed at Apache? That's a very slippery slope. Maybe some projects get way too much leeway because of the big flashing lights. Regardless of how big the press headlines are all projects should be held to the same standard. No project should be allowed to graduate without solving all issues pertaining to marks. It's a failure of the incubator in the past for allowing other projects to do so. I'm shocked it was allowed. -- Best Regards, -- Alex -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] - Packages renaming and backward compatibility (was: Re: [VOTE] Graduate Sqoop podling from Apache Incubator)
On Wed, Feb 29, 2012 at 5:23 AM, Alex Karasulu akaras...@apache.org wrote: The discussion pertains to the presence of com.cloudera packages in the source code of a podling for the sake of backwards compatibility with Cloudera products. Alex this is an incorrect summary of the facts, similar to the FUD you tried to spread on the original thread which Arvind provided detail on. Sqoop was ASL licensed and had an open following long before it was accepted for incubation to Apache. The community is trying to rectify the short term migration requirements against doing the right thing by both Apache and that community. Arvind: ... it would have been easier for us[ sqoop community at apache] to drop any backward compatibility requirements and get releases out quickly. The reason we chose to invest a lot in preserving backward compatibility is for our community. Sqoop has an active community that we care deeply about and we have done our best to make sure continues to use Sqoop effectively. It is this thriving community that was the primary reason for Sqoop to have come into the incubator in the first place. Keep in mind also that this is a short term solution that has a longer term resolution (one already discussed on the other thread as well): Here is Arvind's response to Jukka proposing that Sqoop address the packaging issue post graduation: Thanks Jukka. 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. [3] https://svn.apache.org/repos/asf/incubator/sqoop/branches/sqoop2/ [4] https://issues.apache.org/jira/browse/SQOOP-365 Patrick - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] - Packages renaming and backward compatibility (was: Re: [VOTE] Graduate Sqoop podling from Apache Incubator)
On Wed, Feb 29, 2012 at 6:57 PM, Daniel Kulp dk...@apache.org wrote: As another point of reference, there is at least one case I'm aware of where we HAD to put some code developed at Apache into non-org.apache namespace in order for the code to work. This was taken up on legal discuss and, at the time, no issues about doing so were raised. See: http://s.apache.org/WzP That's certainly a horrible situation to be stuck in. This is a good example for a valid exception IMO. And the CXF bug: https://issues.apache.org/jira/browse/CXF-1880 In this case, it was new code developed at Apache and in the org.apache.cxf namespace, but in order for the code to actual work, there were shims necessary in com.sun.Now, this is a slightly different case in that no end-users would likely ever call (or really even see) this code. It's just need to plugin into an external tool. So, IMO, code at Apache SHOULD be developed in the org.apache namespace, but projects need to be able to have some flexibility to use their judgment to figure out what is best for the needs of their community. Projects should be encouraged to keep code outside org.apache to a minimum via shims or similar and also encourage end users to migrate to using the code in the org.apache namespace as soon as possible. Dan On Wednesday, February 29, 2012 11:02:33 AM Mohammad Nour El-Din wrote: I don't see that this getting to any clear end yet. So I suggest that we take this from a Sqoop instance to be a discussion on rules them selves. I would like to start a [VOTE] about whether it is a *must* for podlings to rename all packages before being a TLP or not over keeping the old package names for backward compatibility. What ever the consensus going to be built we definitely need to update the Incubator documents to clear this kind of issue. But before starting the vote I would like to consider others' opinions. Thoughts ? On Wed, Feb 29, 2012 at 10:33 AM, Alex Karasulu akaras...@apache.org wrote: On Wed, Feb 29, 2012 at 2:40 AM, Patrick Hunt ph...@apache.org wrote: On Tue, Feb 28, 2012 at 4:02 PM, Mohammad Nour El-Din nour.moham...@gmail.com wrote: On the other hand, I totally respect that Cloudera's interest to support their customers and provide backword compatibility, but this is *not* the point at all, the point is this *should* not, and even allow me to say this is *must* not be the problem of Apache, and yes I agree with the opinion that this is a matter to be decided by Sqoop team but not to make Apache's problem. So also let not get more into this!!! Or course this is Apache's problem. You can't have your cake and eat it too. If you accept code for a project you accept the community as well. Say Apache accepts a project like Open Office, should we ignore the existing community and not concern ourselves with backward compatibility for that project as well, because the original code wasn't birthed at Apache? That's a very slippery slope. Maybe some projects get way too much leeway because of the big flashing lights. Regardless of how big the press headlines are all projects should be held to the same standard. No project should be allowed to graduate without solving all issues pertaining to marks. It's a failure of the incubator in the past for allowing other projects to do so. I'm shocked it was allowed. -- Best Regards, -- Alex -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- Best Regards, -- Alex
Re: [DISCUSS] - Packages renaming and backward compatibility (was: Re: [VOTE] Graduate Sqoop podling from Apache Incubator)
Greg, from a legal standpoint I'm not 100% sattisfied. Having a com.cloudera package in any Apache project is imo a show stopper. This should not have been passing the IP clearance at all. Cloudera is a company, and thus a trademark. If we write software and use the com.cloudera package name, then we might breach their trademark, right? This is also true for other projects which have a trademark in their package names. So even if they didn't sue us yet, I guess they could force us to drop those packages at any time. LieGrue, strub - Original Message - From: Greg Stein gst...@gmail.com To: general@incubator.apache.org Cc: Sent: Wednesday, February 29, 2012 3:00 PM Subject: Re: [DISCUSS] - Packages renaming and backward compatibility (was: Re: [VOTE] Graduate Sqoop podling from Apache Incubator) On Feb 29, 2012 8:34 AM, Ian Dickinson i...@epimorphics.com wrote: On 29/02/12 10:02, Mohammad Nour El-Din wrote: I don't see that this getting to any clear end yet. So I suggest that we take this from a Sqoop instance to be a discussion on rules them selves. I would like to start a [VOTE] about whether it is a *must* for podlings to rename all packages before being a TLP or not over keeping the old package names for backward compatibility. What ever the consensus going to be built we definitely need to update the Incubator documents to clear this kind of issue. But before starting the vote I would like to consider others' opinions. Thoughts ? In the case of Apache Jena (incubating), we have more than ten years' worth of existence as an open-source project. In that time, there have been countless tutorials, articles, research papers, code snippets, books and add-on tools that make use of Jena code in the com.hp namespace. But Jena was never an HP *product*, it was an output from the HP research lab in the UK. Our intention as Apache project has been much like Sqoop's: to migrate to org.apache names but keep a compatibility layer in place. We had thought that migration wasn't necessary for graduation, but if it is, no biggie. What would be problematic for our community is if we can't host the compatibility layer packages *at all* under Apache. If we have to expunge all references to com.hp.* packages, then all that back-catalogue of tutorials etc will be instantly obsolete ... unless folks know to go and separately download the jena-compatibility package from SourceForge or wherever it would hypothetically end up. Some of the discussion around Sqoop has been that the backwards-compatibility requirement is all about Cloudera's customers so it's Cloudera's problem. In the case of Jena, it has never been about HP's customers, and it definitely isn't HP's problem since none of the current committers work there any more. For Subversion, Craig Russell was concentrating on this aspect while we were incubating. He basically said, no problem with graduation, as long as you have a plan in place. He followed up with an email about 18 months after graduation, and I replied, yup, all moved over. Moving to org.apache.subversion gave us an opportunity to revamp our interfaces based on what we had learned from the first go-round in org.tigris.subversion. So we have the new hot interfaces under o.a.s, and the compat layer under o.t.s. Works great. Cheers, -g - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] - Packages renaming and backward compatibility (was: Re: [VOTE] Graduate Sqoop podling from Apache Incubator)
On Wed, Feb 29, 2012 at 7:16 PM, Patrick Hunt ph...@apache.org wrote: On Wed, Feb 29, 2012 at 5:23 AM, Alex Karasulu akaras...@apache.org wrote: The discussion pertains to the presence of com.cloudera packages in the source code of a podling for the sake of backwards compatibility with Cloudera products. Alex this is an incorrect summary of the facts, similar to the FUD you tried to spread on the original thread which Arvind provided detail on. No need to degenerate the discussion here. What's not true about the synopsis above? Did I miss something? We're talking about the presence of com.cloudera packages here for backwards compatibility no? Incidentally what exactly is it that you're maintaining backwards compatibility with? I presumed it was a Cloudera product because of the package name. If I'm wrong let me know. Sqoop was ASL licensed and had an open following long before it was accepted for incubation to Apache. The community is trying to rectify the short term migration requirements against doing the right thing by both Apache and that community. OK that does not in any way invalidate my summary. You're just taking swipes for no reason. Do you honestly think I'm trying to spread FUD here? You guys might have had to deal with a lot of nasty jealous types not liking that Cloudera is such a success. I'd like to think there are no people like this here but I may be naive. I'm not one of those people. I like to see Cloudera like commercialization occur but would like some care taken to protect the foundation. The foundation gains through your successes as well. So please don't classify me incorrectly: I'm not one of those types. I read more into Scoop and I think I'm going to be a happy user soon too. And Arvind's comments below are noted but they don't change the existing conditions today. It just means you have a plan for the future: this is good. Arvind: ... it would have been easier for us[ sqoop community at apache] to drop any backward compatibility requirements and get releases out quickly. The reason we chose to invest a lot in preserving backward compatibility is for our community. Sqoop has an active community that we care deeply about and we have done our best to make sure continues to use Sqoop effectively. It is this thriving community that was the primary reason for Sqoop to have come into the incubator in the first place. Keep in mind also that this is a short term solution that has a longer term resolution (one already discussed on the other thread as well): Here is Arvind's response to Jukka proposing that Sqoop address the packaging issue post graduation: Thanks Jukka. 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. [3] https://svn.apache.org/repos/asf/incubator/sqoop/branches/sqoop2/ [4] https://issues.apache.org/jira/browse/SQOOP-365 Patrick - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- Best Regards, -- Alex
Re: [DISCUSS] - Packages renaming and backward compatibility (was: Re: [VOTE] Graduate Sqoop podling from Apache Incubator)
On Wed, Feb 29, 2012 at 10:25 AM, Alex Karasulu akaras...@apache.org wrote: On Wed, Feb 29, 2012 at 7:16 PM, Patrick Hunt ph...@apache.org wrote: On Wed, Feb 29, 2012 at 5:23 AM, Alex Karasulu akaras...@apache.org Sqoop was ASL licensed and had an open following long before it was accepted for incubation to Apache. The community is trying to rectify the short term migration requirements against doing the right thing by both Apache and that community. OK that does not in any way invalidate my summary. You're just taking swipes for no reason. Do you honestly think I'm trying to spread FUD here? You're a smart guy, it was discussed multiple times by multiple people (myself, Arvind, Greg, Jukka, etc...) on the other thread. The basis and rational clearly laid out. What else am I to think. You guys might have had to deal with a lot of nasty jealous types not liking that Cloudera is such a success. I'd like to think there are no people like this here but I may be naive. I'm not one of those people. I like to see Cloudera like commercialization occur but would like some care taken to protect the foundation. The foundation gains through your successes as well. So please don't classify me incorrectly: I'm not one of those types. I don't believe that's the issue at all, at least not for me personally. Arvind and I are careful to wear our Apache hats in these discussions. The Sqoop community is trying it's best to follow established Apache rules and policy. If there's an issue with Sqoop where it's not doing this of course they'll make changes. However at this point there is no such thing. Don't get me wrong here either, I was/am fine with your highlighting this issue (your original point), if you have a concern you need to raise it. Patrick I read more into Scoop and I think I'm going to be a happy user soon too. And Arvind's comments below are noted but they don't change the existing conditions today. It just means you have a plan for the future: this is good. Arvind: ... it would have been easier for us[ sqoop community at apache] to drop any backward compatibility requirements and get releases out quickly. The reason we chose to invest a lot in preserving backward compatibility is for our community. Sqoop has an active community that we care deeply about and we have done our best to make sure continues to use Sqoop effectively. It is this thriving community that was the primary reason for Sqoop to have come into the incubator in the first place. Keep in mind also that this is a short term solution that has a longer term resolution (one already discussed on the other thread as well): Here is Arvind's response to Jukka proposing that Sqoop address the packaging issue post graduation: Thanks Jukka. 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. [3] https://svn.apache.org/repos/asf/incubator/sqoop/branches/sqoop2/ [4] https://issues.apache.org/jira/browse/SQOOP-365 Patrick - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- Best Regards, -- Alex - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] - Packages renaming and backward compatibility (was: Re: [VOTE] Graduate Sqoop podling from Apache Incubator)
Doug referenced a groklaw article in the other thread. Package names are not trademarkable. On Feb 29, 2012 1:04 PM, Mark Struberg strub...@yahoo.de wrote: Greg, from a legal standpoint I'm not 100% sattisfied. Having a com.cloudera package in any Apache project is imo a show stopper. This should not have been passing the IP clearance at all. Cloudera is a company, and thus a trademark. If we write software and use the com.cloudera package name, then we might breach their trademark, right? This is also true for other projects which have a trademark in their package names. So even if they didn't sue us yet, I guess they could force us to drop those packages at any time. LieGrue, strub - Original Message - From: Greg Stein gst...@gmail.com To: general@incubator.apache.org Cc: Sent: Wednesday, February 29, 2012 3:00 PM Subject: Re: [DISCUSS] - Packages renaming and backward compatibility (was: Re: [VOTE] Graduate Sqoop podling from Apache Incubator) On Feb 29, 2012 8:34 AM, Ian Dickinson i...@epimorphics.com wrote: On 29/02/12 10:02, Mohammad Nour El-Din wrote: I don't see that this getting to any clear end yet. So I suggest that we take this from a Sqoop instance to be a discussion on rules them selves. I would like to start a [VOTE] about whether it is a *must* for podlings to rename all packages before being a TLP or not over keeping the old package names for backward compatibility. What ever the consensus going to be built we definitely need to update the Incubator documents to clear this kind of issue. But before starting the vote I would like to consider others' opinions. Thoughts ? In the case of Apache Jena (incubating), we have more than ten years' worth of existence as an open-source project. In that time, there have been countless tutorials, articles, research papers, code snippets, books and add-on tools that make use of Jena code in the com.hp namespace. But Jena was never an HP *product*, it was an output from the HP research lab in the UK. Our intention as Apache project has been much like Sqoop's: to migrate to org.apache names but keep a compatibility layer in place. We had thought that migration wasn't necessary for graduation, but if it is, no biggie. What would be problematic for our community is if we can't host the compatibility layer packages *at all* under Apache. If we have to expunge all references to com.hp.* packages, then all that back-catalogue of tutorials etc will be instantly obsolete ... unless folks know to go and separately download the jena-compatibility package from SourceForge or wherever it would hypothetically end up. Some of the discussion around Sqoop has been that the backwards-compatibility requirement is all about Cloudera's customers so it's Cloudera's problem. In the case of Jena, it has never been about HP's customers, and it definitely isn't HP's problem since none of the current committers work there any more. For Subversion, Craig Russell was concentrating on this aspect while we were incubating. He basically said, no problem with graduation, as long as you have a plan in place. He followed up with an email about 18 months after graduation, and I replied, yup, all moved over. Moving to org.apache.subversion gave us an opportunity to revamp our interfaces based on what we had learned from the first go-round in org.tigris.subversion. So we have the new hot interfaces under o.a.s, and the compat layer under o.t.s. Works great. Cheers, -g - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] - Packages renaming and backward compatibility (was: Re: [VOTE] Graduate Sqoop podling from Apache Incubator)
On Wed, Feb 29, 2012 at 3:00 PM, Benson Margulies bimargul...@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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
