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
Re: [VOTE] Graduate Sqoop podling from Apache Incubator
On Wed, Feb 29, 2012 at 4:06 AM, Daniel Kulp dk...@apache.org wrote: On Wednesday, February 29, 2012 1:13:30 AM Mohammad Nour El-Din wrote: Hi Daniel... On Wed, Feb 29, 2012 at 1:07 AM, Daniel Kulp dk...@apache.org wrote: We had a very similar discussion about the back word compatibility classes/package names when Subversion graduated and we deemed it OK for them. In fact, I believe they still of org.tigris packages in their codebase long after graduation. See: http://svn.apache.org/repos/asf/subversion/trunk/subversion/bindings/javah l/src/org/ I don't see why we would or should hold Sqoop to a different or higher standard at this point. I agree with Jukka that if we, as a foundation, would like to re-address this, fine, take it to trademarks@ and start a discussion. However, from an INCUBATOR standpoint, the precedent and expectations have been set. That's my $0.02 cents worth. Thanks a lot for this, but would you elaborate more on why this has been accepted ? My believe is that there is some clarification that should be added to documentation so it is more clear for all people in the future, your input on this example would help indeed. You could likely read the mail archives if you want all the details. general@incubator in Nov 2009 had a thread, dev@subversion in Jan 2010 had a thread, and I think the graduation vote in Feb 2010 had more discussions. Basically, the Subversion had binary compatibility rules and there was no real legal requirement to force a huge disruption in the community by changing the package names. The project had a plan to deprecate them/create wrappers/whatever so when it was appropriate to break compatibility they would. Did they remove those packages or did they remain? -- Best Regards, -- Alex
Re: [VOTE] Graduate Sqoop podling from Apache Incubator
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
[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: [VOTE] Graduate Sqoop podling from Apache Incubator
On Feb 29, 2012 4:15 AM, Alex Karasulu akaras...@apache.org wrote: On Wed, Feb 29, 2012 at 4:06 AM, Daniel Kulp dk...@apache.org wrote: On Wednesday, February 29, 2012 1:13:30 AM Mohammad Nour El-Din wrote: Hi Daniel... On Wed, Feb 29, 2012 at 1:07 AM, Daniel Kulp dk...@apache.org wrote: We had a very similar discussion about the back word compatibility classes/package names when Subversion graduated and we deemed it OK for them. In fact, I believe they still of org.tigris packages in their codebase long after graduation. See: http://svn.apache.org/repos/asf/subversion/trunk/subversion/bindings/javah l/src/org/ I don't see why we would or should hold Sqoop to a different or higher standard at this point. I agree with Jukka that if we, as a foundation, would like to re-address this, fine, take it to trademarks@ and start a discussion. However, from an INCUBATOR standpoint, the precedent and expectations have been set. That's my $0.02 cents worth. Thanks a lot for this, but would you elaborate more on why this has been accepted ? My believe is that there is some clarification that should be added to documentation so it is more clear for all people in the future, your input on this example would help indeed. You could likely read the mail archives if you want all the details. general@incubator in Nov 2009 had a thread, dev@subversion in Jan 2010 had a thread, and I think the graduation vote in Feb 2010 had more discussions. Basically, the Subversion had binary compatibility rules and there was no real legal requirement to force a huge disruption in the community by changing the package names. The project had a plan to deprecate them/create wrappers/whatever so when it was appropriate to break compatibility they would. Did they remove those packages or did they remain? They remain. Keeping them is the right thing for our community and product. That is our determination, and is our Right. Sqoop has determined backwards compatibility is important to their community and wants to keep this (deprecated) interface for a while. So where is the problem here, people? Really. What is the problem with the extra interfaces? There is no legal (trademark or copyright) problem that I'm aware of. There is no technical problem that I'm aware of. So what is it? Why are people all up in Sqoop's face here? Why is there some attempt at imposing technical changes on them? What ASF-wide policy is being broken? If the policy doesn't exist, but you think it *should*, then please state as much, along with a resolution for the Board to consider, in order to make it official policy. And if/when the Board *does* make it official policy, then the graduated/TLP PMC can ensure their code base complies. And please note: this imputed/proposed policy will affect Subversion packaging, too. Your rationale for mandates on Sqoop package names must be able to apply just as well to Subversion. Don't focus on just Sqoop, but the overall Foundation-wide issue. If you send a resolution to the Board, then it better be backed up with an explanation of why the Board should be getting involved in Java package naming for projects across the Foundation. The explanation should state the problem, and how the policy (via the resolution) will solve that problem. I see no reason for the Incubator to reverse a vote that has been completed, and to do so in the name of some nebulous/unstated policy. It is exactly this behavior why projects want to graduate earlier rather than later. To escape random, misplaced imposition on communities. -g
Re: [VOTE] Graduate Sqoop podling from Apache Incubator
On Feb 28, 2012 9:02 AM, Ate Douma a...@douma.nu wrote: ... That sounds reasonable and hopefully easy to do (if not this case might even be more worrisome then). I'm not really sure though if Apache Extras is an appropriate location either. I think Apache Extras intends to convey an affiliation with the ASF and probably should value project independence high as well. If this really only concerns a thin layer to provide compatibility only for Cloudera's API, hosting and maintenance of this should be the responsibility of Cloudera itself. Anybody can put code on Apache Extras. Those projects have no affiliation with the ASF. It is for projects *related* to ours in some way. -g
Re: [VOTE] Graduate Sqoop podling from Apache Incubator
Hi Greg... On Wed, Feb 29, 2012 at 1:06 PM, Greg Stein gst...@gmail.com wrote: On Feb 29, 2012 4:15 AM, Alex Karasulu akaras...@apache.org wrote: On Wed, Feb 29, 2012 at 4:06 AM, Daniel Kulp dk...@apache.org wrote: On Wednesday, February 29, 2012 1:13:30 AM Mohammad Nour El-Din wrote: Hi Daniel... On Wed, Feb 29, 2012 at 1:07 AM, Daniel Kulp dk...@apache.org wrote: We had a very similar discussion about the back word compatibility classes/package names when Subversion graduated and we deemed it OK for them. In fact, I believe they still of org.tigris packages in their codebase long after graduation. See: http://svn.apache.org/repos/asf/subversion/trunk/subversion/bindings/javah l/src/org/ I don't see why we would or should hold Sqoop to a different or higher standard at this point. I agree with Jukka that if we, as a foundation, would like to re-address this, fine, take it to trademarks@ and start a discussion. However, from an INCUBATOR standpoint, the precedent and expectations have been set. That's my $0.02 cents worth. Thanks a lot for this, but would you elaborate more on why this has been accepted ? My believe is that there is some clarification that should be added to documentation so it is more clear for all people in the future, your input on this example would help indeed. You could likely read the mail archives if you want all the details. general@incubator in Nov 2009 had a thread, dev@subversion in Jan 2010 had a thread, and I think the graduation vote in Feb 2010 had more discussions. Basically, the Subversion had binary compatibility rules and there was no real legal requirement to force a huge disruption in the community by changing the package names. The project had a plan to deprecate them/create wrappers/whatever so when it was appropriate to break compatibility they would. Did they remove those packages or did they remain? They remain. Keeping them is the right thing for our community and product. That is our determination, and is our Right. That is what we are trying to figure out here, and that is why we have this discussion :) Sqoop has determined backwards compatibility is important to their community and wants to keep this (deprecated) interface for a while. So where is the problem here, people? Really. What is the problem with the extra interfaces? No body is trying to make any problems to any other one here, we are just trying to make sure that things are done as it should be There is no legal (trademark or copyright) problem that I'm aware of. There is no technical problem that I'm aware of. So what is it? Why are people all up in Sqoop's face here? Why is there some attempt at imposing technical changes on them? What ASF-wide policy is being broken? If the policy doesn't exist, but you think it *should*, then please state as much, along with a resolution for the Board to consider, in order to make it official policy. And if/when the Board *does* make it official policy, then the graduated/TLP PMC can ensure their code base complies. Again and as I started in one of my earlier e-mails, no one is trying to impose anything on Sqoop or any other project, it is something that needs to be discussed and thats all, and the vote neither cancelled nor postponed, we still have time till next board meeting and we here trying to sort things out to see, as you also explained below, if it is a real issue which needs to be raised to the board or not, if not then there is nothing to talk about and thing will go as planned for Sqoop or any other podling will propose for being graduated in the future. So I agree with you it is not a Sqoop thing at all it is more about ASF itself. And please note: this imputed/proposed policy will affect Subversion packaging, too. Your rationale for mandates on Sqoop package names must be able to apply just as well to Subversion. Don't focus on just Sqoop, but the overall Foundation-wide issue. If you send a resolution to the Board, then it better be backed up with an explanation of why the Board should be getting involved in Java package naming for projects across the Foundation. The explanation should state the problem, and how the policy (via the resolution) will solve that problem. Totally agree, and again we are still discussing if it should be raised to the board and then stated and an ASF policy or not, and in the former case sure there must plans for already existing projects how to adapt to that and sure giving them the proper time window, but again there is no reason going into this hassle if there is no consensus on making an issue out of it. I see no reason for the Incubator to reverse a vote that has been completed, and to do so in the name of some nebulous/unstated policy. It is exactly
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: [VOTE] Graduate Sqoop podling from Apache Incubator
On Feb 29, 2012 7:32 AM, Mohammad Nour El-Din nour.moham...@gmail.com wrote: Hi Greg... On Wed, Feb 29, 2012 at 1:06 PM, Greg Stein gst...@gmail.com wrote: ... They remain. Keeping them is the right thing for our community and product. That is our determination, and is our Right. That is what we are trying to figure out here, and that is why we have this discussion :) ... Again and as I started in one of my earlier e-mails, no one is trying to impose anything on Sqoop or any other project, What? I've seen people say the vote should be canceled, that Sqoop needs to yank the code, etc. Those are most certainly impositions. This is no mere discussion; it is some number of people attempting to impose some unstated policy upon Sqoop before allowing them to graduate. ... I gave it more thought and IMO, I think we should raise the issue to the Board to get to some results, Raise what issue? I have not seen a statement of the problem, other than projects sometimes deem it necessary to use package names in addition to org.apache. But I don't see the problem in that. Could you at least explain here before bringing a question to the Board? If it is legal in nature, then it should go to legal-discuss. Cheers, -g
Re: [VOTE] Graduate Sqoop podling from Apache Incubator
On Wed, Feb 29, 2012 at 2:06 PM, Greg Stein gst...@gmail.com wrote: On Feb 29, 2012 4:15 AM, Alex Karasulu akaras...@apache.org wrote: On Wed, Feb 29, 2012 at 4:06 AM, Daniel Kulp dk...@apache.org wrote: On Wednesday, February 29, 2012 1:13:30 AM Mohammad Nour El-Din wrote: Hi Daniel... On Wed, Feb 29, 2012 at 1:07 AM, Daniel Kulp dk...@apache.org wrote: We had a very similar discussion about the back word compatibility classes/package names when Subversion graduated and we deemed it OK for them. In fact, I believe they still of org.tigris packages in their codebase long after graduation. See: http://svn.apache.org/repos/asf/subversion/trunk/subversion/bindings/javah l/src/org/ I don't see why we would or should hold Sqoop to a different or higher standard at this point. I agree with Jukka that if we, as a foundation, would like to re-address this, fine, take it to trademarks@ and start a discussion. However, from an INCUBATOR standpoint, the precedent and expectations have been set. That's my $0.02 cents worth. Thanks a lot for this, but would you elaborate more on why this has been accepted ? My believe is that there is some clarification that should be added to documentation so it is more clear for all people in the future, your input on this example would help indeed. You could likely read the mail archives if you want all the details. general@incubator in Nov 2009 had a thread, dev@subversion in Jan 2010 had a thread, and I think the graduation vote in Feb 2010 had more discussions. Basically, the Subversion had binary compatibility rules and there was no real legal requirement to force a huge disruption in the community by changing the package names. The project had a plan to deprecate them/create wrappers/whatever so when it was appropriate to break compatibility they would. Did they remove those packages or did they remain? They remain. Keeping them is the right thing for our community and product. That is our determination, and is our Right. Sorry but I don't think that's right. Sqoop has determined backwards compatibility is important to their community and wants to keep this (deprecated) interface for a while. So where is the problem here, people? It's fine but those com.cloudera packages don't need to be hosted here. They can be hosted elsewhere and the backwards compatibility issue can still be handled. Really. What is the problem with the extra interfaces? The package namespace is not ours. It's that simple G. There is no legal (trademark or copyright) problem that I'm aware of. There is no technical problem that I'm aware of. OK do we have the right to create any kind of package or class under com.cloudera (or any other companies packages)? -- 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: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: [VOTE] Graduate Sqoop podling from Apache Incubator
Hi Greg... On Wed, Feb 29, 2012 at 2:03 PM, Greg Stein gst...@gmail.com wrote: On Feb 29, 2012 7:32 AM, Mohammad Nour El-Din nour.moham...@gmail.com wrote: Hi Greg... On Wed, Feb 29, 2012 at 1:06 PM, Greg Stein gst...@gmail.com wrote: ... They remain. Keeping them is the right thing for our community and product. That is our determination, and is our Right. That is what we are trying to figure out here, and that is why we have this discussion :) ... Again and as I started in one of my earlier e-mails, no one is trying to impose anything on Sqoop or any other project, What? I've seen people say the vote should be canceled, that Sqoop needs to yank the code, etc. Those are most certainly impositions. I was talking about myself actually here and, sorry for the confusion. But even everybody has freedom to express there *opinions* and *ideas* we are not gods here, so even if some people said that the vote should be cancelled that does not mean it is cancelled or it will be cancelled immediately or in the future, it is still a *discussion* after all. This is no mere discussion; it is some number of people attempting to impose some unstated policy upon Sqoop before allowing them to graduate. ... I gave it more thought and IMO, I think we should raise the issue to the Board to get to some results, Raise what issue? I have not seen a statement of the problem, other than projects sometimes deem it necessary to use package names in addition to org.apache. But I don't see the problem in that. Could you at least explain here before bringing a question to the Board? If it is legal in nature, then it should go to legal-discuss. You got this point wrong, I am not saying to raise an issue immediately, what I am saying is that we discuss that before raising it as an issue to the board *if any*. For the legal-discuss I believe it is a good idea to bring that to them as well. I believe the more input we get the clearer things are. Cheers, -g -- 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 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: [VOTE] Graduate Sqoop podling from Apache Incubator
On 29/02/12 13:07, Alex Karasulu wrote: [snip] 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)? This is a red-herring in my view: no packages or classes are being created if a project leaves a compatibility layer in place. The class/package names are merely not being deleted. Presuming that the original code was part of the inceptional code grant, one can conclude that the company in question doesn't mind their namespace being used by ASF projects *for that purpose*. Ian - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Graduate Sqoop podling from Apache Incubator
On Wed, Feb 29, 2012 at 3:07 PM, Alex Karasulu akaras...@apache.org wrote: On Wed, Feb 29, 2012 at 2:06 PM, Greg Stein gst...@gmail.com wrote: On Feb 29, 2012 4:15 AM, Alex Karasulu akaras...@apache.org wrote: On Wed, Feb 29, 2012 at 4:06 AM, Daniel Kulp dk...@apache.org wrote: On Wednesday, February 29, 2012 1:13:30 AM Mohammad Nour El-Din wrote: Hi Daniel... On Wed, Feb 29, 2012 at 1:07 AM, Daniel Kulp dk...@apache.org wrote: We had a very similar discussion about the back word compatibility classes/package names when Subversion graduated and we deemed it OK for them. In fact, I believe they still of org.tigris packages in their codebase long after graduation. See: http://svn.apache.org/repos/asf/subversion/trunk/subversion/bindings/javah l/src/org/ I don't see why we would or should hold Sqoop to a different or higher standard at this point. I agree with Jukka that if we, as a foundation, would like to re-address this, fine, take it to trademarks@ and start a discussion. However, from an INCUBATOR standpoint, the precedent and expectations have been set. That's my $0.02 cents worth. Thanks a lot for this, but would you elaborate more on why this has been accepted ? My believe is that there is some clarification that should be added to documentation so it is more clear for all people in the future, your input on this example would help indeed. You could likely read the mail archives if you want all the details. general@incubator in Nov 2009 had a thread, dev@subversion in Jan 2010 had a thread, and I think the graduation vote in Feb 2010 had more discussions. Basically, the Subversion had binary compatibility rules and there was no real legal requirement to force a huge disruption in the community by changing the package names. The project had a plan to deprecate them/create wrappers/whatever so when it was appropriate to break compatibility they would. Did they remove those packages or did they remain? They remain. Keeping them is the right thing for our community and product. That is our determination, and is our Right. Sorry but I don't think that's right. Sqoop has determined backwards compatibility is important to their community and wants to keep this (deprecated) interface for a while. So where is the problem here, people? It's fine but those com.cloudera packages don't need to be hosted here. They can be hosted elsewhere and the backwards compatibility issue can still be handled. Really. What is the problem with the extra interfaces? The package namespace is not ours. It's that simple G. There is no legal (trademark or copyright) problem that I'm aware of. There is no technical problem that I'm aware of. OK do we have the right to create any kind of package or class under com.cloudera (or any other companies packages)? Greg's right. Jukka was as well but for some reason I did not immediately get it. We cannot hold Scoop to a standard which we don't apply to other TLPs and this needs to be a Foundation wide policy discussion. I still think the practice of bundling classes and packages which are not in our namespace is a serious issue. I'll take this up the other discussion thread. I am withdrawing my veto and I apologize for any inconvenience this may have caused the Scoop community. -- 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: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: [VOTE] Graduate Sqoop podling from Apache Incubator
On Feb 29, 2012 8:07 AM, Alex Karasulu akaras...@apache.org wrote: On Wed, Feb 29, 2012 at 2:06 PM, Greg Stein gst...@gmail.com wrote: ... 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. Please explain what information you have that states we cannot use org.tigris.subversion for our deprecated APIs. I'm very curious because I wasn't aware of any prohibition on this. You seem to know something the Subversion community does not. Explain, please. (and yes, I know exactly who owns org.tigris.subversion; I'd like to see if you do) 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. The community says it is best for their product to bundle the deprecated APIs. Do you have some information from the community that says otherwise? They can be hosted elsewhere and the backwards compatibility issue can still be handled. They can, but the community feels it best for their users to bundle it as part of the product. Do you know something about the users that leads you to believe they would prefer to get the deprecated interfaces from somewhere else? As a separate download? An extra step? What do you know that the Sqoop devs do not? Really. What is the problem with the extra interfaces? The package namespace is not ours. It's that simple G. Are we allowed to use it? Is the namespace designed/defined for us to use it? Is somebody attempting to recover the deprecated namespace? Do the owners *want* us to continue using it? Those are the questions. I know Subversion is allowed to use org.tigris for its deprecated APIs. Who are you to say otherwise? Why do you assume you know better? How is it you know what package name I can or cannot use? 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 bet they would get pissed if we created arbitrary packages in their namespace, but that is NOT the question at hand. The question is whether we can continue to use the old package name for backwards compatibility purposes. Have you asked Cloudera or the community if anybody told them, no, we want our old package name back. No, I bet you didn't. I bet you saw com.cloudera and just generalized the issue into somebody else's namespace without full detail or background, which the community already had. You mentioned slippery slope earlier. Don't you see you're already on it? And this is the reason the Board stays out of technical decisions? Only the community knows best. You're on that slope, attempting to apply *your* technical mandates upon a project. But they know more than you. -g
Re: [VOTE] Graduate Sqoop podling from Apache Incubator
I'd like the address this and Greg's other email but let's move this over to the other discussion thread so this one can close and Scoop can continue forward. On Wed, Feb 29, 2012 at 3:39 PM, Ian Dickinson i...@epimorphics.com wrote: On 29/02/12 13:07, Alex Karasulu wrote: [snip] 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)? This is a red-herring in my view: no packages or classes are being created if a project leaves a compatibility layer in place. The class/package names are merely not being deleted. Presuming that the original code was part of the inceptional code grant, one can conclude that the company in question doesn't mind their namespace being used by ASF projects *for that purpose*. Ian --**--**- To unsubscribe, e-mail: general-unsubscribe@incubator.**apache.orggeneral-unsubscr...@incubator.apache.org For additional commands, e-mail: general-help@incubator.apache.**orggeneral-h...@incubator.apache.org -- Best Regards, -- Alex
Re: [VOTE] Graduate Sqoop podling from Apache Incubator
On Feb 29, 2012 8:31 AM, Mohammad Nour El-Din nour.moham...@gmail.com wrote: Hi Greg... On Wed, Feb 29, 2012 at 2:03 PM, Greg Stein gst...@gmail.com wrote: ... I gave it more thought and IMO, I think we should raise the issue to the Board to get to some results, Raise what issue? I have not seen a statement of the problem, other than projects sometimes deem it necessary to use package names in addition to org.apache. But I don't see the problem in that. Could you at least explain here before bringing a question to the Board? If it is legal in nature, then it should go to legal-discuss. You got this point wrong, I am not saying to raise an issue immediately, what I am saying is that we discuss that before raising it as an issue to the board *if any*. We're in agreement; I said explain here ... ie. continue the discussion. Cheers, -g
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: [VOTE] Graduate Sqoop podling from Apache Incubator
Hi Alex On Wed, Feb 29, 2012 at 2:39 PM, Alex Karasulu akaras...@apache.org wrote: On Wed, Feb 29, 2012 at 3:07 PM, Alex Karasulu akaras...@apache.org wrote: On Wed, Feb 29, 2012 at 2:06 PM, Greg Stein gst...@gmail.com wrote: On Feb 29, 2012 4:15 AM, Alex Karasulu akaras...@apache.org wrote: On Wed, Feb 29, 2012 at 4:06 AM, Daniel Kulp dk...@apache.org wrote: On Wednesday, February 29, 2012 1:13:30 AM Mohammad Nour El-Din wrote: Hi Daniel... On Wed, Feb 29, 2012 at 1:07 AM, Daniel Kulp dk...@apache.org wrote: We had a very similar discussion about the back word compatibility classes/package names when Subversion graduated and we deemed it OK for them. In fact, I believe they still of org.tigris packages in their codebase long after graduation. See: http://svn.apache.org/repos/asf/subversion/trunk/subversion/bindings/javah l/src/org/ I don't see why we would or should hold Sqoop to a different or higher standard at this point. I agree with Jukka that if we, as a foundation, would like to re-address this, fine, take it to trademarks@ and start a discussion. However, from an INCUBATOR standpoint, the precedent and expectations have been set. That's my $0.02 cents worth. Thanks a lot for this, but would you elaborate more on why this has been accepted ? My believe is that there is some clarification that should be added to documentation so it is more clear for all people in the future, your input on this example would help indeed. You could likely read the mail archives if you want all the details. general@incubator in Nov 2009 had a thread, dev@subversion in Jan 2010 had a thread, and I think the graduation vote in Feb 2010 had more discussions. Basically, the Subversion had binary compatibility rules and there was no real legal requirement to force a huge disruption in the community by changing the package names. The project had a plan to deprecate them/create wrappers/whatever so when it was appropriate to break compatibility they would. Did they remove those packages or did they remain? They remain. Keeping them is the right thing for our community and product. That is our determination, and is our Right. Sorry but I don't think that's right. Sqoop has determined backwards compatibility is important to their community and wants to keep this (deprecated) interface for a while. So where is the problem here, people? It's fine but those com.cloudera packages don't need to be hosted here. They can be hosted elsewhere and the backwards compatibility issue can still be handled. Really. What is the problem with the extra interfaces? The package namespace is not ours. It's that simple G. There is no legal (trademark or copyright) problem that I'm aware of. There is no technical problem that I'm aware of. OK do we have the right to create any kind of package or class under com.cloudera (or any other companies packages)? Greg's right. Jukka was as well but for some reason I did not immediately get it. We cannot hold Scoop to a standard which we don't apply to other TLPs and this needs to be a Foundation wide policy discussion. I still think the practice of bundling classes and packages which are not in our namespace is a serious issue. I'll take this up the other discussion thread. I am withdrawing my veto and I apologize for any inconvenience this may have caused the Scoop community. No need for any apologies at all, we are all one team and such discussions IMHO are important and also healthy cause it helps making things clear and more explicit which IMO makes ASF a better place to live :) -- Best Regards, -- Alex -- Thanks - Mohammad Nour Life is like riding a bicycle. To keep your balance you must keep moving - Albert Einstein
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: [VOTE] Graduate Sqoop podling from Apache Incubator
On Wed, Feb 29, 2012 at 3:45 PM, Greg Stein gst...@gmail.com wrote: On Feb 29, 2012 8:07 AM, Alex Karasulu akaras...@apache.org wrote: On Wed, Feb 29, 2012 at 2:06 PM, Greg Stein gst...@gmail.com wrote: ... 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. Please explain what information you have that states we cannot use org.tigris.subversion for our deprecated APIs. I'm very curious because I wasn't aware of any prohibition on this. You seem to know something the Subversion community does not. Explain, please. (and yes, I know exactly who owns org.tigris.subversion; I'd like to see if you do) I was not clear here. I'm merely stating that I don't believe the practice to be sound. Also I don't think it's a right TLPs should have. I was not commenting on the current state of the subversion code base :). 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. The community says it is best for their product to bundle the deprecated APIs. Do you have some information from the community that says otherwise? Nope. They can be hosted elsewhere and the backwards compatibility issue can still be handled. They can, but the community feels it best for their users to bundle it as part of the product. Do you know something about the users that leads you to believe they would prefer to get the deprecated interfaces from somewhere else? As a separate download? An extra step? No, no and no. What do you know that the Sqoop devs do not? Not suggesting I know anything more about their product and their community than them. Their aims to maintain backwards compatibility is a good one. This is not being debated. Really. What is the problem with the extra interfaces? The package namespace is not ours. It's that simple G. Are we allowed to use it? Is the namespace designed/defined for us to use it? Is somebody attempting to recover the deprecated namespace? Do the owners *want* us to continue using it? Those are the questions. IMO, the issue is over and done if Cloudera has authorized our use of their namespace in some written form. This makes it so they cannot come back and complain for us using the namespace. I know Subversion is allowed to use org.tigris for its deprecated APIs. Who are you to say otherwise? Why do you assume you know better? How is it you know what package name I can or cannot use? 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 bet they would get pissed if we created arbitrary packages in their namespace, but that is NOT the question at hand. No it is not the question at hand. But where do you draw the line is my point. The question is whether we can continue to use the old package name for backwards compatibility purposes. Have you asked Cloudera or the community if anybody told them, no, we want our old package name back. No, I bet you didn't. I bet you saw com.cloudera and just generalized the issue into somebody else's namespace without full detail or background, which the community already had. Foundation wide I see this as a policy that will eventually cause problems. When the practice created to solve compatibility problems leads to compatibility problems then ... you see where I'm going with this. It's just better not to play this game at all. Just play it safe. In the case of Scoop it's clear. But with the way we're growing you're not going to be able to make sure collisions don't result. And that can actually hurt other parties. The namespace mechanism is there to prevent such collisions. You mentioned slippery slope earlier. Don't you see you're already on it? Hahaha, yes actually I do but another slippery slope, the one I pointed out above also exist. How do we stay off both? And this is the reason the Board stays out of technical decisions? Only the community knows best. You're on that slope, attempting to apply *your* technical mandates upon a project. But they know more than you. I don't think I'm here trying to mandate how they're to procede technically. It would be preposterous of me to do that. They know best, I'm 100% with you on that. But I don't think this is a technical discussion. -- 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: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: [VOTE] Graduate Sqoop podling from Apache Incubator
Seems we're continuing the discussion in both threads now. More inline ... On Wed, Feb 29, 2012 at 3:39 PM, Ian Dickinson i...@epimorphics.com wrote: On 29/02/12 13:07, Alex Karasulu wrote: [snip] 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)? This is a red-herring in my view: no packages or classes are being created if a project leaves a compatibility layer in place. The point I'm trying to make is when you do it at all you have to quantify why. That get's tedious and error prone and with the rate of growth we're dealing with that's just unmanageable IMO. The class/package names are merely not being deleted. Presuming that the original code was part of the inceptional code grant, one can conclude that the company in question doesn't mind their namespace being used by ASF projects *for that purpose*. OK I'm completely content if the Co. in question does so in writing freeing us of any responsibility. -- 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: [VOTE] Graduate Sqoop podling from Apache Incubator
On 02/29/2012 02:45 PM, Greg Stein wrote: On Feb 29, 2012 8:07 AM, Alex Karasuluakaras...@apache.org wrote: On Wed, Feb 29, 2012 at 2:06 PM, Greg Steingst...@gmail.com wrote: ... 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. Please explain what information you have that states we cannot use org.tigris.subversion for our deprecated APIs. I'm very curious because I wasn't aware of any prohibition on this. You seem to know something the Subversion community does not. Explain, please. (and yes, I know exactly who owns org.tigris.subversion; I'd like to see if you do) 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. The community says it is best for their product to bundle the deprecated APIs. Do you have some information from the community that says otherwise? They can be hosted elsewhere and the backwards compatibility issue can still be handled. They can, but the community feels it best for their users to bundle it as part of the product. Do you know something about the users that leads you to believe they would prefer to get the deprecated interfaces from somewhere else? As a separate download? An extra step? What do you know that the Sqoop devs do not? Really. What is the problem with the extra interfaces? The package namespace is not ours. It's that simple G. Are we allowed to use it? Is the namespace designed/defined for us to use it? Is somebody attempting to recover the deprecated namespace? Do the owners *want* us to continue using it? Those are the questions. I know Subversion is allowed to use org.tigris for its deprecated APIs. Who are you to say otherwise? Why do you assume you know better? How is it you know what package name I can or cannot use? 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 bet they would get pissed if we created arbitrary packages in their namespace, but that is NOT the question at hand. To me this actually *is* the question at hand, but from a different perspective than you bring up. In my initial response on this I raised this as a question about affiliation and independence of the project towards the community. For all I know Cloudera might not get pissed off at all if arbitrary packages in their namespace are created. There are plenty Cloudera committers on Sqoop which could (legally be allowed to) do this themselves. So to me this is not a legal problem but one of community, diversity and independence of affiliation. How will the community perceive the project independence from Cloudera if it carries, and maintains a 3rd party namespace, to which several committers are commercially affiliated as employee. That IMO should be an concern for the Foundation, not solely a 'Right' of a PMC to decide on themselves. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Graduate Sqoop podling from Apache Incubator
On 02/29/2012 03:52 PM, Ate Douma wrote: On 02/29/2012 02:45 PM, Greg Stein wrote: On Feb 29, 2012 8:07 AM, Alex Karasuluakaras...@apache.org wrote: On Wed, Feb 29, 2012 at 2:06 PM, Greg Steingst...@gmail.com wrote: ... 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. Please explain what information you have that states we cannot use org.tigris.subversion for our deprecated APIs. I'm very curious because I wasn't aware of any prohibition on this. You seem to know something the Subversion community does not. Explain, please. (and yes, I know exactly who owns org.tigris.subversion; I'd like to see if you do) 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. The community says it is best for their product to bundle the deprecated APIs. Do you have some information from the community that says otherwise? They can be hosted elsewhere and the backwards compatibility issue can still be handled. They can, but the community feels it best for their users to bundle it as part of the product. Do you know something about the users that leads you to believe they would prefer to get the deprecated interfaces from somewhere else? As a separate download? An extra step? What do you know that the Sqoop devs do not? Really. What is the problem with the extra interfaces? The package namespace is not ours. It's that simple G. Are we allowed to use it? Is the namespace designed/defined for us to use it? Is somebody attempting to recover the deprecated namespace? Do the owners *want* us to continue using it? Those are the questions. I know Subversion is allowed to use org.tigris for its deprecated APIs. Who are you to say otherwise? Why do you assume you know better? How is it you know what package name I can or cannot use? 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 bet they would get pissed if we created arbitrary packages in their namespace, but that is NOT the question at hand. To me this actually *is* the question at hand, but from a different perspective than you bring up. In my initial response on this I raised this as a question about affiliation and independence of the project towards the community. For all I know Cloudera might not get pissed off at all if arbitrary packages in their namespace are created. There are plenty Cloudera committers on Sqoop which could (legally be allowed to) do this themselves. So to me this is not a legal problem but one of community, diversity and independence of affiliation. How will the community perceive the project independence from Cloudera if it carries, and maintains a 3rd party namespace, to which several committers are commercially affiliated as employee. That IMO should be an concern for the Foundation, not solely a 'Right' of a PMC to decide on themselves. To elaborate a bit more: to me project independence is one of the most important values the ASF stands for. IMO many of our rules and guidelines are founded on that principle. The (required) usage of the org.apache namespace is one way we tell the community: this is Apache, free to use and independent of possible 3rd party donations, claims or direction. While for SOME use-cases there might be valid arguments we MUST use other namespaces (cleanroom spec. implementations for instance), or if a project *itself* needs to decorate a 3rd party dependency, IMO the base principle SHOULD be to stay away from including 3rd party namespaces. I would propose that an ASF project SHOULD not use 3rd party namespaces, unless there is a very strong and logical requirement to do so. I'm explicitly not using the term MUST here. In the case of Sqoop, at least AFAIK, there is no *requirement* to include the com.cloudera namespace, other than as a convenience to the community. To me that doesn't sound as a strong enough argument. Allowing for such use-cases only muddies the water and will dilutes the ASF principle of project independence. Ate - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Graduate Sqoop podling from Apache Incubator
On 29 February 2012 15:39, Ate Douma a...@douma.nu wrote: On 02/29/2012 03:52 PM, Ate Douma wrote: ... I would propose that an ASF project SHOULD not use 3rd party namespaces, unless there is a very strong and logical requirement to do so. I'm explicitly not using the term MUST here. +1 When I championed Jena we discussed this. The team agreed that the change should be made but insisted that doing so as part of a point release would be very difficult for the community. They were concerned that it would hold up graduation if they MUST make the change. I asked the question, I think on general@, but possibly members@. I was assured that it SHOULD be done but that it was recognised this is not always possible during incubation. I'm not going to comment on Sqoop as I have not looked at the specifics. However, I believe Jena have a strong case (which is rooted in supporting a large and pre-existing user community). Furthermore, they have a commitment to move away from the old namespace. I guess one big difference here is that the company represented in the Jena namespace is no longer active in the community. I'll let others figure out the Sqoop case, but I want to show strong support for SHOULD versus MUST as outlined by Ate. Ross - 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)
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: [VOTE] Graduate Sqoop podling from Apache Incubator
On 02/29/2012 01:33 AM, Alex Karasulu wrote: 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. This is not a trademark issue. Package names are subject to fair use. Doug - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Graduate Sqoop podling from Apache Incubator
On 02/29/2012 06:19 AM, Alex Karasulu wrote: The class/package names are merely not being deleted. Presuming that the original code was part of the inceptional code grant, one can conclude that the company in question doesn't mind their namespace being used by ASF projects *for that purpose*. OK I'm completely content if the Co. in question does so in writing freeing us of any responsibility. I don't think this is required. ... the names of the Java language API files, packages, classes, and methods are not protectable as a matter of law ... http://www.groklaw.net/articlebasic.php?story=20110915194531435 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 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: [VOTE] Graduate Sqoop podling from Apache Incubator
On Wed, Feb 29, 2012 at 4:52 PM, Ate Douma a...@douma.nu wrote: On 02/29/2012 02:45 PM, Greg Stein wrote: On Feb 29, 2012 8:07 AM, Alex Karasuluakaras...@apache.org** wrote: On Wed, Feb 29, 2012 at 2:06 PM, Greg Steingst...@gmail.com wrote: ... 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. Please explain what information you have that states we cannot use org.tigris.subversion for our deprecated APIs. I'm very curious because I wasn't aware of any prohibition on this. You seem to know something the Subversion community does not. Explain, please. (and yes, I know exactly who owns org.tigris.subversion; I'd like to see if you do) 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. The community says it is best for their product to bundle the deprecated APIs. Do you have some information from the community that says otherwise? They can be hosted elsewhere and the backwards compatibility issue can still be handled. They can, but the community feels it best for their users to bundle it as part of the product. Do you know something about the users that leads you to believe they would prefer to get the deprecated interfaces from somewhere else? As a separate download? An extra step? What do you know that the Sqoop devs do not? Really. What is the problem with the extra interfaces? The package namespace is not ours. It's that simple G. Are we allowed to use it? Is the namespace designed/defined for us to use it? Is somebody attempting to recover the deprecated namespace? Do the owners *want* us to continue using it? Those are the questions. I know Subversion is allowed to use org.tigris for its deprecated APIs. Who are you to say otherwise? Why do you assume you know better? How is it you know what package name I can or cannot use? 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 bet they would get pissed if we created arbitrary packages in their namespace, but that is NOT the question at hand. To me this actually *is* the question at hand, but from a different perspective than you bring up. In my initial response on this I raised this as a question about affiliation and independence of the project towards the community. For all I know Cloudera might not get pissed off at all if arbitrary packages in their namespace are created. There are plenty Cloudera committers on Sqoop which could (legally be allowed to) do this themselves. So to me this is not a legal problem but one of community, diversity and independence of affiliation. How will the community perceive the project independence from Cloudera if it carries, and maintains a 3rd party namespace, to which several committers are commercially affiliated as employee. That IMO should be an concern for the Foundation, not solely a 'Right' of a PMC to decide on themselves. I completely agree with this position as well. It escaped my focus as I was more worried about the issue of namespace collisions. -- Best Regards, -- Alex
Re: [VOTE] Graduate Sqoop podling from Apache Incubator
On Wed, Feb 29, 2012 at 8:11 PM, Doug Cutting cutt...@apache.org wrote: On 02/29/2012 01:33 AM, Alex Karasulu wrote: 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. This is not a trademark issue. Package names are subject to fair use. It might not be a trademark issue per say, IANAL, but the package namespace of another entity like a corporation belongs to them and at a minimum should be respected. Of course this is not an issue as I said before if that entity gives written permission to use their namespace. That fixes this aspect of the problem. I can't go off and mirror the namespace of Foo Co. without causing some form of damage with the powerful distribution channels the ASF posses. Now no one in their right mind would do that here (I hope) but potentials for collisions are probably going to happen in the future. -- Best Regards, -- Alex
Re: [VOTE] Graduate Sqoop podling from Apache Incubator
On Wed, Feb 29, 2012 at 8:20 PM, Doug Cutting cutt...@apache.org wrote: On 02/29/2012 06:19 AM, Alex Karasulu wrote: The class/package names are merely not being deleted. Presuming that the original code was part of the inceptional code grant, one can conclude that the company in question doesn't mind their namespace being used by ASF projects *for that purpose*. OK I'm completely content if the Co. in question does so in writing freeing us of any responsibility. I don't think this is required. ... the names of the Java language API files, packages, classes, and methods are not protectable as a matter of law ... http://www.groklaw.net/articlebasic.php?story=20110915194531435 Just saw this now. This makes me feel much better. But it does not prevent a negative, and potentially damaging situation from occurring. -- 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: [VOTE] Graduate Sqoop podling from Apache Incubator
Arvind, (Sorry, I missed this discussion.) On Feb 28, 2012, at 10:53 AM, Arvind Prabhakar wrote: Please see [1] for details on why the code is like this. The short summary is that binary compatibility requires us to respect all extension points within the code. [1] https://cwiki.apache.org/confluence/display/SQOOP/Namespace+Migration This might be prior to your involvement with Sqoop, but it was initially part of Apache Hadoop MapReduce as a contrib module prior to being moved out to github. https://issues.apache.org/jira/browse/HADOOP-5815 http://svn.apache.org/viewvc/hadoop/common/branches/branch-0.21-old/mapreduce/src/contrib/sqoop/ Thus, does the Sqoop community also plan to maintain back-compat with org.apache.hadoop.sqoop namespace for older users too? I can't seem to place whether we ever made Apache Hadoop releases which included Sqoop before it got moved out... Arun
Re: [VOTE] Graduate Sqoop podling from Apache Incubator
On Feb 29, 2012, at 11:10 AM, Arun C Murthy wrote: Arvind, (Sorry, I missed this discussion.) On Feb 28, 2012, at 10:53 AM, Arvind Prabhakar wrote: Please see [1] for details on why the code is like this. The short summary is that binary compatibility requires us to respect all extension points within the code. [1] https://cwiki.apache.org/confluence/display/SQOOP/Namespace+Migration This might be prior to your involvement with Sqoop, but it was initially part of Apache Hadoop MapReduce as a contrib module prior to being moved out to github. https://issues.apache.org/jira/browse/HADOOP-5815 http://svn.apache.org/viewvc/hadoop/common/branches/branch-0.21-old/mapreduce/src/contrib/sqoop/ Thus, does the Sqoop community also plan to maintain back-compat with org.apache.hadoop.sqoop namespace for older users too? I can't seem to place whether we ever made Apache Hadoop releases which included Sqoop before it got moved out... Uh, hit 'send' too soon... Never mind - I was looking at the wrong project in ASF jira (HADOOP and not MAPREDUCE). Sqoop was removed via https://issues.apache.org/jira/browse/MAPREDUCE-1644 Turns out we never released Sqoop via Apache Hadoop - so my question is moot. Sorry for the noise. Arun
Re: [VOTE] Graduate Sqoop podling from Apache Incubator
Hi Arun, On Wed, Feb 29, 2012 at 11:11 AM, Arun C Murthy a...@hortonworks.com wrote: On Feb 29, 2012, at 11:10 AM, Arun C Murthy wrote: Arvind, (Sorry, I missed this discussion.) On Feb 28, 2012, at 10:53 AM, Arvind Prabhakar wrote: Please see [1] for details on why the code is like this. The short summary is that binary compatibility requires us to respect all extension points within the code. [1] https://cwiki.apache.org/confluence/display/SQOOP/Namespace+Migration This might be prior to your involvement with Sqoop, but it was initially part of Apache Hadoop MapReduce as a contrib module prior to being moved out to github. https://issues.apache.org/jira/browse/HADOOP-5815 http://svn.apache.org/viewvc/hadoop/common/branches/branch-0.21-old/mapreduce/src/contrib/sqoop/ Thus, does the Sqoop community also plan to maintain back-compat with org.apache.hadoop.sqoop namespace for older users too? I can't seem to place whether we ever made Apache Hadoop releases which included Sqoop before it got moved out... Uh, hit 'send' too soon... Never mind - I was looking at the wrong project in ASF jira (HADOOP and not MAPREDUCE). Sqoop was removed via https://issues.apache.org/jira/browse/MAPREDUCE-1644 Turns out we never released Sqoop via Apache Hadoop - so my question is moot. Sorry for the noise. Correct. This was disclosed at the time the project entered Incubator. Please see the background section in the original proposal below: http://wiki.apache.org/incubator/SqoopProposal Thanks, Arvind Prabhakar Arun - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Graduate Sqoop podling from Apache Incubator
+1 Niall On Fri, Feb 24, 2012 at 9:34 PM, Arvind Prabhakar arv...@apache.org wrote: This is a call for vote to graduate Sqoop podling from Apache Incubator. Sqoop entered Incubator in June of 2011. Since then it has added three new committers from diverse organizations, added two new PPMC members, and made two releases following the ASF policies and guidelines. The community of Sqoop is active, healthy and growing and has demonstrated the ability to self-govern using accepted Apache practices. Sqoop community has voted to proceed with graduation [1] and the result can be found at [2]. Please cast your votes: [ ] +1 Graduate Sqoop podling from Apache Incubator [ ] +0 Indifferent to the graduation status of Sqoop podling [ ] -1 Reject graduation of Sqoop podling from Apache Incubator This vote will be open for 72 hours. Please find the proposed board resolution below. [1] http://markmail.org/thread/xwhjtkik7pgrmypi [2] http://s.apache.org/sqoop Thanks, Arvind Prabhakar X. Establish the Apache Sqoop Project WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software related to efficiently transferring bulk data between Apache Hadoop and structured datastores for distribution at no charge to the public. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the Apache Sqoop Project, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache Sqoop Project be and hereby is responsible for the creation and maintenance of software related to efficiently transferring bulk data between Apache Hadoop and structured datastores; and be it further RESOLVED, that the office of Vice President, Apache Sqoop be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache Sqoop Project, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache Sqoop Project; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache Sqoop Project: * Aaron Kimball kimba...@apache.org * Andrew Bayer aba...@apache.org * Ahmed Radwan ah...@apache.org * Arvind Prabhakar arv...@apache.org * Bilung Lee b...@apache.org * Greg Cottman gcott...@apache.org * Guy le Mar guyle...@apache.org * Jaroslav Cecho jar...@apache.org * Jonathan Hsieh jmhs...@apache.org * Olivier Lamy ol...@apache.org * Paul Zimdars pzimd...@apache.org * Roman Shaposhnik r...@apache.org NOW, THEREFORE, BE IT FURTHER RESOLVED, that Arvind Prabhakar be appointed to the office of Vice President, Apache Sqoop, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the initial Apache Sqoop PMC be and hereby is tasked with the creation of a set of bylaws intended to encourage open development and increased participation in the Apache Sqoop Project; and be it further RESOLVED, that the Apache Sqoop Project be and hereby is tasked with the migration and rationalization of the Apache Incubator Sqoop podling; and be it further RESOLVED, that all responsibilities pertaining to the Apache Incubator Sqoop podling encumbered upon the Apache Incubator Project are hereafter discharged. - 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: [VOTE] Graduate Sqoop podling from Apache Incubator
+1 On Wed, Feb 29, 2012 at 2:39 PM, Niall Pemberton niall.pember...@gmail.com wrote: +1 Niall On Fri, Feb 24, 2012 at 9:34 PM, Arvind Prabhakar arv...@apache.org wrote: This is a call for vote to graduate Sqoop podling from Apache Incubator. Sqoop entered Incubator in June of 2011. Since then it has added three new committers from diverse organizations, added two new PPMC members, and made two releases following the ASF policies and guidelines. The community of Sqoop is active, healthy and growing and has demonstrated the ability to self-govern using accepted Apache practices. Sqoop community has voted to proceed with graduation [1] and the result can be found at [2]. Please cast your votes: [ ] +1 Graduate Sqoop podling from Apache Incubator [ ] +0 Indifferent to the graduation status of Sqoop podling [ ] -1 Reject graduation of Sqoop podling from Apache Incubator This vote will be open for 72 hours. Please find the proposed board resolution below. [1] http://markmail.org/thread/xwhjtkik7pgrmypi [2] http://s.apache.org/sqoop Thanks, Arvind Prabhakar X. Establish the Apache Sqoop Project WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software related to efficiently transferring bulk data between Apache Hadoop and structured datastores for distribution at no charge to the public. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the Apache Sqoop Project, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache Sqoop Project be and hereby is responsible for the creation and maintenance of software related to efficiently transferring bulk data between Apache Hadoop and structured datastores; and be it further RESOLVED, that the office of Vice President, Apache Sqoop be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache Sqoop Project, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache Sqoop Project; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache Sqoop Project: * Aaron Kimball kimba...@apache.org * Andrew Bayer aba...@apache.org * Ahmed Radwan ah...@apache.org * Arvind Prabhakar arv...@apache.org * Bilung Lee b...@apache.org * Greg Cottman gcott...@apache.org * Guy le Mar guyle...@apache.org * Jaroslav Cecho jar...@apache.org * Jonathan Hsieh jmhs...@apache.org * Olivier Lamy ol...@apache.org * Paul Zimdars pzimd...@apache.org * Roman Shaposhnik r...@apache.org NOW, THEREFORE, BE IT FURTHER RESOLVED, that Arvind Prabhakar be appointed to the office of Vice President, Apache Sqoop, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the initial Apache Sqoop PMC be and hereby is tasked with the creation of a set of bylaws intended to encourage open development and increased participation in the Apache Sqoop Project; and be it further RESOLVED, that the Apache Sqoop Project be and hereby is tasked with the migration and rationalization of the Apache Incubator Sqoop podling; and be it further RESOLVED, that all responsibilities pertaining to the Apache Incubator Sqoop podling encumbered upon the Apache Incubator Project are hereafter discharged. - 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 - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Graduate Sqoop podling from Apache Incubator
The vote closed a day or two ago, passing with all +1's. (fyi) On Feb 29, 2012 2:48 PM, Benson Margulies bimargul...@gmail.com wrote: +1 On Wed, Feb 29, 2012 at 2:39 PM, Niall Pemberton niall.pember...@gmail.com wrote: +1 Niall On Fri, Feb 24, 2012 at 9:34 PM, Arvind Prabhakar arv...@apache.org wrote: This is a call for vote to graduate Sqoop podling from Apache Incubator. Sqoop entered Incubator in June of 2011. Since then it has added three new committers from diverse organizations, added two new PPMC members, and made two releases following the ASF policies and guidelines. The community of Sqoop is active, healthy and growing and has demonstrated the ability to self-govern using accepted Apache practices. Sqoop community has voted to proceed with graduation [1] and the result can be found at [2]. Please cast your votes: [ ] +1 Graduate Sqoop podling from Apache Incubator [ ] +0 Indifferent to the graduation status of Sqoop podling [ ] -1 Reject graduation of Sqoop podling from Apache Incubator This vote will be open for 72 hours. Please find the proposed board resolution below. [1] http://markmail.org/thread/xwhjtkik7pgrmypi [2] http://s.apache.org/sqoop Thanks, Arvind Prabhakar X. Establish the Apache Sqoop Project WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software related to efficiently transferring bulk data between Apache Hadoop and structured datastores for distribution at no charge to the public. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the Apache Sqoop Project, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache Sqoop Project be and hereby is responsible for the creation and maintenance of software related to efficiently transferring bulk data between Apache Hadoop and structured datastores; and be it further RESOLVED, that the office of Vice President, Apache Sqoop be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache Sqoop Project, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache Sqoop Project; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache Sqoop Project: * Aaron Kimball kimba...@apache.org * Andrew Bayer aba...@apache.org * Ahmed Radwan ah...@apache.org * Arvind Prabhakar arv...@apache.org * Bilung Leeb...@apache.org * Greg Cottman gcott...@apache.org * Guy le Marguyle...@apache.org * Jaroslav Cechojar...@apache.org * Jonathan Hsiehjmhs...@apache.org * Olivier Lamy ol...@apache.org * Paul Zimdars pzimd...@apache.org * Roman Shaposhnik r...@apache.org NOW, THEREFORE, BE IT FURTHER RESOLVED, that Arvind Prabhakar be appointed to the office of Vice President, Apache Sqoop, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the initial Apache Sqoop PMC be and hereby is tasked with the creation of a set of bylaws intended to encourage open development and increased participation in the Apache Sqoop Project; and be it further RESOLVED, that the Apache Sqoop Project be and hereby is tasked with the migration and rationalization of the Apache Incubator Sqoop podling; and be it further RESOLVED, that all responsibilities pertaining to the Apache Incubator Sqoop podling encumbered upon the Apache Incubator Project are hereafter discharged. - 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)
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: [VOTE] Graduate Sqoop podling from Apache Incubator
Thanks Greg. The vote was closed Feb 27, 2012. The tally of votes was sent out shortly thereafter and can be found at: http://markmail.org/message/vnti4j7kailm4hxb Since consensus on graduation of Sqoop from Apache Incubator has been reached, I will proceed to the next step of submitting the resolution proposal we have voted on for consideration by the board. Thanks to every one who voted and participated in the discussion. Thanks, Arvind Prabhakar On Wed, Feb 29, 2012 at 12:41 PM, Greg Stein gst...@gmail.com wrote: The vote closed a day or two ago, passing with all +1's. (fyi) On Feb 29, 2012 2:48 PM, Benson Margulies bimargul...@gmail.com wrote: +1 On Wed, Feb 29, 2012 at 2:39 PM, Niall Pemberton niall.pember...@gmail.com wrote: +1 Niall On Fri, Feb 24, 2012 at 9:34 PM, Arvind Prabhakar arv...@apache.org wrote: This is a call for vote to graduate Sqoop podling from Apache Incubator. Sqoop entered Incubator in June of 2011. Since then it has added three new committers from diverse organizations, added two new PPMC members, and made two releases following the ASF policies and guidelines. The community of Sqoop is active, healthy and growing and has demonstrated the ability to self-govern using accepted Apache practices. Sqoop community has voted to proceed with graduation [1] and the result can be found at [2]. Please cast your votes: [ ] +1 Graduate Sqoop podling from Apache Incubator [ ] +0 Indifferent to the graduation status of Sqoop podling [ ] -1 Reject graduation of Sqoop podling from Apache Incubator This vote will be open for 72 hours. Please find the proposed board resolution below. [1] http://markmail.org/thread/xwhjtkik7pgrmypi [2] http://s.apache.org/sqoop Thanks, Arvind Prabhakar X. Establish the Apache Sqoop Project WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software related to efficiently transferring bulk data between Apache Hadoop and structured datastores for distribution at no charge to the public. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the Apache Sqoop Project, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache Sqoop Project be and hereby is responsible for the creation and maintenance of software related to efficiently transferring bulk data between Apache Hadoop and structured datastores; and be it further RESOLVED, that the office of Vice President, Apache Sqoop be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache Sqoop Project, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache Sqoop Project; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache Sqoop Project: * Aaron Kimball kimba...@apache.org * Andrew Bayer aba...@apache.org * Ahmed Radwan ah...@apache.org * Arvind Prabhakar arv...@apache.org * Bilung Lee b...@apache.org * Greg Cottman gcott...@apache.org * Guy le Mar guyle...@apache.org * Jaroslav Cecho jar...@apache.org * Jonathan Hsieh jmhs...@apache.org * Olivier Lamy ol...@apache.org * Paul Zimdars pzimd...@apache.org * Roman Shaposhnik r...@apache.org NOW, THEREFORE, BE IT FURTHER RESOLVED, that Arvind Prabhakar be appointed to the office of Vice President, Apache Sqoop, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the initial Apache Sqoop PMC be and hereby is tasked with the creation of a set of bylaws intended to encourage open development and increased participation in the Apache Sqoop Project; and be it further RESOLVED, that the Apache Sqoop Project be and hereby is tasked with the migration and rationalization of the Apache Incubator Sqoop podling; and be it further RESOLVED, that all responsibilities pertaining to the Apache Incubator Sqoop podling encumbered upon the
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
Re: [VOTE] Graduate Sqoop podling from Apache Incubator
The source code in Sqoop still exists in both com.cloudera.sqoop and org.apache.sqoop packages and most of the code appears to include the com.cloudera packages and not the org.apache packages. While in the incubator this seems fine. Are we ok with this in a TLP? I couldn't find any policy statements on it in the Apache pages. Alan. On Feb 24, 2012, at 1:34 PM, Arvind Prabhakar wrote: This is a call for vote to graduate Sqoop podling from Apache Incubator. Sqoop entered Incubator in June of 2011. Since then it has added three new committers from diverse organizations, added two new PPMC members, and made two releases following the ASF policies and guidelines. The community of Sqoop is active, healthy and growing and has demonstrated the ability to self-govern using accepted Apache practices. Sqoop community has voted to proceed with graduation [1] and the result can be found at [2]. Please cast your votes: [ ] +1 Graduate Sqoop podling from Apache Incubator [ ] +0 Indifferent to the graduation status of Sqoop podling [ ] -1 Reject graduation of Sqoop podling from Apache Incubator This vote will be open for 72 hours. Please find the proposed board resolution below. [1] http://markmail.org/thread/xwhjtkik7pgrmypi [2] http://s.apache.org/sqoop Thanks, Arvind Prabhakar X. Establish the Apache Sqoop Project WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software related to efficiently transferring bulk data between Apache Hadoop and structured datastores for distribution at no charge to the public. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the Apache Sqoop Project, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache Sqoop Project be and hereby is responsible for the creation and maintenance of software related to efficiently transferring bulk data between Apache Hadoop and structured datastores; and be it further RESOLVED, that the office of Vice President, Apache Sqoop be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache Sqoop Project, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache Sqoop Project; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache Sqoop Project: * Aaron Kimball kimba...@apache.org * Andrew Bayer aba...@apache.org * Ahmed Radwan ah...@apache.org * Arvind Prabhakar arv...@apache.org * Bilung Leeb...@apache.org * Greg Cottman gcott...@apache.org * Guy le Marguyle...@apache.org * Jaroslav Cechojar...@apache.org * Jonathan Hsiehjmhs...@apache.org * Olivier Lamy ol...@apache.org * Paul Zimdars pzimd...@apache.org * Roman Shaposhnik r...@apache.org NOW, THEREFORE, BE IT FURTHER RESOLVED, that Arvind Prabhakar be appointed to the office of Vice President, Apache Sqoop, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the initial Apache Sqoop PMC be and hereby is tasked with the creation of a set of bylaws intended to encourage open development and increased participation in the Apache Sqoop Project; and be it further RESOLVED, that the Apache Sqoop Project be and hereby is tasked with the migration and rationalization of the Apache Incubator Sqoop podling; and be it further RESOLVED, that all responsibilities pertaining to the Apache Incubator Sqoop podling encumbered upon the Apache Incubator Project are hereafter discharged. - 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: [VOTE] Graduate Sqoop podling from Apache Incubator
On Mon, Feb 27, 2012 at 10:10 PM, Alan Gates ga...@hortonworks.com wrote: The source code in Sqoop still exists in both com.cloudera.sqoop and org.apache.sqoop packages and most of the code appears to include the com.cloudera packages and not the org.apache packages. While in the incubator this seems fine. Are we ok with this in a TLP? I couldn't find any policy statements on it in the Apache pages. Good catch Alan. You are right we are not OK with this situation. It needs to be corrected then another vote can be taken. Thanks, Alex On Feb 24, 2012, at 1:34 PM, Arvind Prabhakar wrote: This is a call for vote to graduate Sqoop podling from Apache Incubator. Sqoop entered Incubator in June of 2011. Since then it has added three new committers from diverse organizations, added two new PPMC members, and made two releases following the ASF policies and guidelines. The community of Sqoop is active, healthy and growing and has demonstrated the ability to self-govern using accepted Apache practices. Sqoop community has voted to proceed with graduation [1] and the result can be found at [2]. Please cast your votes: [ ] +1 Graduate Sqoop podling from Apache Incubator [ ] +0 Indifferent to the graduation status of Sqoop podling [ ] -1 Reject graduation of Sqoop podling from Apache Incubator This vote will be open for 72 hours. Please find the proposed board resolution below. [1] http://markmail.org/thread/xwhjtkik7pgrmypi [2] http://s.apache.org/sqoop Thanks, Arvind Prabhakar X. Establish the Apache Sqoop Project WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software related to efficiently transferring bulk data between Apache Hadoop and structured datastores for distribution at no charge to the public. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the Apache Sqoop Project, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache Sqoop Project be and hereby is responsible for the creation and maintenance of software related to efficiently transferring bulk data between Apache Hadoop and structured datastores; and be it further RESOLVED, that the office of Vice President, Apache Sqoop be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache Sqoop Project, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache Sqoop Project; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache Sqoop Project: * Aaron Kimball kimba...@apache.org * Andrew Bayer aba...@apache.org * Ahmed Radwan ah...@apache.org * Arvind Prabhakar arv...@apache.org * Bilung Leeb...@apache.org * Greg Cottman gcott...@apache.org * Guy le Marguyle...@apache.org * Jaroslav Cechojar...@apache.org * Jonathan Hsiehjmhs...@apache.org * Olivier Lamy ol...@apache.org * Paul Zimdars pzimd...@apache.org * Roman Shaposhnik r...@apache.org NOW, THEREFORE, BE IT FURTHER RESOLVED, that Arvind Prabhakar be appointed to the office of Vice President, Apache Sqoop, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the initial Apache Sqoop PMC be and hereby is tasked with the creation of a set of bylaws intended to encourage open development and increased participation in the Apache Sqoop Project; and be it further RESOLVED, that the Apache Sqoop Project be and hereby is tasked with the migration and rationalization of the Apache Incubator Sqoop podling; and be it further RESOLVED, that all responsibilities pertaining to the Apache Incubator Sqoop podling encumbered upon the Apache Incubator Project are hereafter discharged. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail:
Re: [VOTE] Graduate Sqoop podling from Apache Incubator
Alex, Alan, Thanks for your feedback. Please take a look at SQOOP-369: https://issues.apache.org/jira/browse/SQOOP-369 All of the source code for Sqoop that exists in com.cloudera namespace is deprecated and the actual implementation of the product has been moved under org.apache namespace. The only reason com.cloudera namespace exists is in order to provide backward compatibility with third party code. Thanks, Arvind Prabhakar On Tue, Feb 28, 2012 at 12:39 AM, Alex Karasulu akaras...@apache.org wrote: On Mon, Feb 27, 2012 at 10:10 PM, Alan Gates ga...@hortonworks.com wrote: The source code in Sqoop still exists in both com.cloudera.sqoop and org.apache.sqoop packages and most of the code appears to include the com.cloudera packages and not the org.apache packages. While in the incubator this seems fine. Are we ok with this in a TLP? I couldn't find any policy statements on it in the Apache pages. Good catch Alan. You are right we are not OK with this situation. It needs to be corrected then another vote can be taken. Thanks, Alex On Feb 24, 2012, at 1:34 PM, Arvind Prabhakar wrote: This is a call for vote to graduate Sqoop podling from Apache Incubator. Sqoop entered Incubator in June of 2011. Since then it has added three new committers from diverse organizations, added two new PPMC members, and made two releases following the ASF policies and guidelines. The community of Sqoop is active, healthy and growing and has demonstrated the ability to self-govern using accepted Apache practices. Sqoop community has voted to proceed with graduation [1] and the result can be found at [2]. Please cast your votes: [ ] +1 Graduate Sqoop podling from Apache Incubator [ ] +0 Indifferent to the graduation status of Sqoop podling [ ] -1 Reject graduation of Sqoop podling from Apache Incubator This vote will be open for 72 hours. Please find the proposed board resolution below. [1] http://markmail.org/thread/xwhjtkik7pgrmypi [2] http://s.apache.org/sqoop Thanks, Arvind Prabhakar X. Establish the Apache Sqoop Project WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software related to efficiently transferring bulk data between Apache Hadoop and structured datastores for distribution at no charge to the public. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the Apache Sqoop Project, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache Sqoop Project be and hereby is responsible for the creation and maintenance of software related to efficiently transferring bulk data between Apache Hadoop and structured datastores; and be it further RESOLVED, that the office of Vice President, Apache Sqoop be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache Sqoop Project, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache Sqoop Project; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache Sqoop Project: * Aaron Kimball kimba...@apache.org * Andrew Bayer aba...@apache.org * Ahmed Radwan ah...@apache.org * Arvind Prabhakar arv...@apache.org * Bilung Lee b...@apache.org * Greg Cottman gcott...@apache.org * Guy le Mar guyle...@apache.org * Jaroslav Cecho jar...@apache.org * Jonathan Hsieh jmhs...@apache.org * Olivier Lamy ol...@apache.org * Paul Zimdars pzimd...@apache.org * Roman Shaposhnik r...@apache.org NOW, THEREFORE, BE IT FURTHER RESOLVED, that Arvind Prabhakar be appointed to the office of Vice President, Apache Sqoop, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the initial Apache Sqoop PMC be and hereby is tasked with the creation of a set of bylaws intended to encourage open development and increased participation in the Apache Sqoop Project; and be it further RESOLVED, that the
Re: [VOTE] Graduate Sqoop podling from Apache Incubator
Hi Alex and Alan, we already moved entire logic to org.apache namespace. We're keeping classes in com.cloudera in place only for compatibility with tools that are based on sqoop (for example various connectors). However those classes do not contain any logic, they are just inheriting from org.apache namespace and do nothing. Let me show you what I mean on following example: https://svn.apache.org/repos/asf/incubator/sqoop/trunk/src/java/com/cloudera/sqoop/manager/MySQLManager.java All other files in com.cloudera namespace have similar structure. They are just skeleton code that is in place for compatibility without any logic (additional code). Do we really need to remove entirely com.cloudera namespace or is this state acceptable for graduating? Jarcec On Tue, Feb 28, 2012 at 10:39:35AM +0200, Alex Karasulu wrote: On Mon, Feb 27, 2012 at 10:10 PM, Alan Gates ga...@hortonworks.com wrote: The source code in Sqoop still exists in both com.cloudera.sqoop and org.apache.sqoop packages and most of the code appears to include the com.cloudera packages and not the org.apache packages. While in the incubator this seems fine. Are we ok with this in a TLP? I couldn't find any policy statements on it in the Apache pages. Good catch Alan. You are right we are not OK with this situation. It needs to be corrected then another vote can be taken. Thanks, Alex On Feb 24, 2012, at 1:34 PM, Arvind Prabhakar wrote: This is a call for vote to graduate Sqoop podling from Apache Incubator. Sqoop entered Incubator in June of 2011. Since then it has added three new committers from diverse organizations, added two new PPMC members, and made two releases following the ASF policies and guidelines. The community of Sqoop is active, healthy and growing and has demonstrated the ability to self-govern using accepted Apache practices. Sqoop community has voted to proceed with graduation [1] and the result can be found at [2]. Please cast your votes: [ ] +1 Graduate Sqoop podling from Apache Incubator [ ] +0 Indifferent to the graduation status of Sqoop podling [ ] -1 Reject graduation of Sqoop podling from Apache Incubator This vote will be open for 72 hours. Please find the proposed board resolution below. [1] http://markmail.org/thread/xwhjtkik7pgrmypi [2] http://s.apache.org/sqoop Thanks, Arvind Prabhakar X. Establish the Apache Sqoop Project WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software related to efficiently transferring bulk data between Apache Hadoop and structured datastores for distribution at no charge to the public. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the Apache Sqoop Project, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache Sqoop Project be and hereby is responsible for the creation and maintenance of software related to efficiently transferring bulk data between Apache Hadoop and structured datastores; and be it further RESOLVED, that the office of Vice President, Apache Sqoop be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache Sqoop Project, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache Sqoop Project; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache Sqoop Project: * Aaron Kimball kimba...@apache.org * Andrew Bayer aba...@apache.org * Ahmed Radwan ah...@apache.org * Arvind Prabhakar arv...@apache.org * Bilung Leeb...@apache.org * Greg Cottman gcott...@apache.org * Guy le Marguyle...@apache.org * Jaroslav Cechojar...@apache.org * Jonathan Hsiehjmhs...@apache.org * Olivier Lamy ol...@apache.org * Paul Zimdars pzimd...@apache.org * Roman Shaposhnik r...@apache.org NOW, THEREFORE, BE IT FURTHER RESOLVED, that Arvind Prabhakar be appointed to the office of Vice President, Apache Sqoop, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until
Re: [VOTE] Graduate Sqoop podling from Apache Incubator
Hi, On Tue, Feb 28, 2012 at 9:59 AM, Alex Karasulu akaras...@apache.org wrote: Cloudera's compatibility issues are not our problem. These packages need to go. Citation needed. Without a written policy to that effect these things are up for each project to decide. Jarek's rationale sounds perfectly fine to me. We have plenty of projects that provide such backwards compatibility wrappers or otherwise put stuff in non-apache namespaces for various reasons. See for example [1] or [2]. [1] http://svn.apache.org/repos/asf/subversion/trunk/subversion/bindings/javahl/ [2] http://svn.apache.org/repos/asf/geronimo/specs/trunk/ BR, Jukka Zitting - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Graduate Sqoop podling from Apache Incubator
On Tue, Feb 28, 2012 at 11:06 AM, Jukka Zitting jukka.zitt...@gmail.comwrote: Hi, On Tue, Feb 28, 2012 at 9:59 AM, Alex Karasulu akaras...@apache.org wrote: Cloudera's compatibility issues are not our problem. These packages need to go. Citation needed. I did not think we needed one: nor do I have one. It's common sense to me that this causes issues. It combines the namespace of a foreign mark with our own. We should not be releasing anything in the namespace belonging to another entity. Without a written policy to that effect these things are up for each project to decide. Jarek's rationale sounds perfectly fine to me. I highly respect you opinion here but I disagree regarding this argument provided. There may be no policy to cite, and there may be examples of where this was done before for the sake of backwards compatibility. It still does not justify doing it. We have plenty of projects that provide such backwards compatibility wrappers or otherwise put stuff in non-apache namespaces for various reasons. See for example [1] or [2]. Understood. Examples are solid points supporting the argument but IMHO I think this was a mistake that opens the door to several issues. Maybe we need some clear policy regarding the matter. I'm more than ready to be proven wrong on this matter so long as it does not present problems down the line for us. [1] http://svn.apache.org/repos/asf/subversion/trunk/subversion/bindings/javahl/ [2] http://svn.apache.org/repos/asf/geronimo/specs/trunk/ BR, Jukka Zitting -- Best Regards, -- Alex
Re: [VOTE] Graduate Sqoop podling from Apache Incubator
Good catch On Mon, Feb 27, 2012 at 9:10 PM, Alan Gates ga...@hortonworks.com wrote: The source code in Sqoop still exists in both com.cloudera.sqoop and org.apache.sqoop packages and most of the code appears to include the com.cloudera packages and not the org.apache packages. While in the incubator this seems fine. Are we ok with this in a TLP? I couldn't find any policy statements on it in the Apache pages. No this is not OK with a TLP Alan. On Feb 24, 2012, at 1:34 PM, Arvind Prabhakar wrote: This is a call for vote to graduate Sqoop podling from Apache Incubator. Sqoop entered Incubator in June of 2011. Since then it has added three new committers from diverse organizations, added two new PPMC members, and made two releases following the ASF policies and guidelines. The community of Sqoop is active, healthy and growing and has demonstrated the ability to self-govern using accepted Apache practices. Sqoop community has voted to proceed with graduation [1] and the result can be found at [2]. Please cast your votes: [ ] +1 Graduate Sqoop podling from Apache Incubator [ ] +0 Indifferent to the graduation status of Sqoop podling [ ] -1 Reject graduation of Sqoop podling from Apache Incubator This vote will be open for 72 hours. Please find the proposed board resolution below. [1] http://markmail.org/thread/xwhjtkik7pgrmypi [2] http://s.apache.org/sqoop Thanks, Arvind Prabhakar X. Establish the Apache Sqoop Project WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software related to efficiently transferring bulk data between Apache Hadoop and structured datastores for distribution at no charge to the public. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the Apache Sqoop Project, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache Sqoop Project be and hereby is responsible for the creation and maintenance of software related to efficiently transferring bulk data between Apache Hadoop and structured datastores; and be it further RESOLVED, that the office of Vice President, Apache Sqoop be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache Sqoop Project, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache Sqoop Project; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache Sqoop Project: * Aaron Kimball kimba...@apache.org * Andrew Bayer aba...@apache.org * Ahmed Radwan ah...@apache.org * Arvind Prabhakar arv...@apache.org * Bilung Leeb...@apache.org * Greg Cottman gcott...@apache.org * Guy le Marguyle...@apache.org * Jaroslav Cechojar...@apache.org * Jonathan Hsiehjmhs...@apache.org * Olivier Lamy ol...@apache.org * Paul Zimdars pzimd...@apache.org * Roman Shaposhnik r...@apache.org NOW, THEREFORE, BE IT FURTHER RESOLVED, that Arvind Prabhakar be appointed to the office of Vice President, Apache Sqoop, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the initial Apache Sqoop PMC be and hereby is tasked with the creation of a set of bylaws intended to encourage open development and increased participation in the Apache Sqoop Project; and be it further RESOLVED, that the Apache Sqoop Project be and hereby is tasked with the migration and rationalization of the Apache Incubator Sqoop podling; and be it further RESOLVED, that all responsibilities pertaining to the Apache Incubator Sqoop podling encumbered upon the Apache Incubator Project are hereafter discharged. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Graduate Sqoop podling from Apache Incubator
Hi... 1st of all, and I speaking about myself here, I believe this is partially my fault cause I am one of the mentors of Sqoop and I should have spotted such thing before moving the vote to general@ I totally agree with Alex, more specifically I believe this is easy to solve. There is no problem to support some features or API(s) for backward compatibility but as Alex stated it should not be part of Apache's code, more specifically when it comes to be part of a TLP's code. The solution can be like packaging this code and host it on Cloudera or even Apache Extras [1] and a note is added to Sqoop website that if users want to have backward compatibility they should use that code besides the code of Apache. Now the question is, and I ask this more specifically to the Sqoop people, Can you do this before the next board meeting, at least the extracting that code ? Cause if not I support Alex in that this vote should be cancelled and then we work out another one when Sqoop meets this criteria. Looking forward to your feedback! [1] - http://code.google.com/a/apache-extras.org/hosting/ On Tue, Feb 28, 2012 at 10:44 AM, Alex Karasulu akaras...@apache.orgwrote: On Tue, Feb 28, 2012 at 11:06 AM, Jukka Zitting jukka.zitt...@gmail.com wrote: Hi, On Tue, Feb 28, 2012 at 9:59 AM, Alex Karasulu akaras...@apache.org wrote: Cloudera's compatibility issues are not our problem. These packages need to go. Citation needed. I did not think we needed one: nor do I have one. It's common sense to me that this causes issues. It combines the namespace of a foreign mark with our own. We should not be releasing anything in the namespace belonging to another entity. Without a written policy to that effect these things are up for each project to decide. Jarek's rationale sounds perfectly fine to me. I highly respect you opinion here but I disagree regarding this argument provided. There may be no policy to cite, and there may be examples of where this was done before for the sake of backwards compatibility. It still does not justify doing it. We have plenty of projects that provide such backwards compatibility wrappers or otherwise put stuff in non-apache namespaces for various reasons. See for example [1] or [2]. Understood. Examples are solid points supporting the argument but IMHO I think this was a mistake that opens the door to several issues. Maybe we need some clear policy regarding the matter. I'm more than ready to be proven wrong on this matter so long as it does not present problems down the line for us. [1] http://svn.apache.org/repos/asf/subversion/trunk/subversion/bindings/javahl/ [2] http://svn.apache.org/repos/asf/geronimo/specs/trunk/ BR, Jukka Zitting -- Best Regards, -- Alex -- Thanks - Mohammad Nour Life is like riding a bicycle. To keep your balance you must keep moving - Albert Einstein
Re: [VOTE] Graduate Sqoop podling from Apache Incubator
On 02/28/2012 01:46 PM, Mohammad Nour El-Din wrote: Hi... 1st of all, and I speaking about myself here, I believe this is partially my fault cause I am one of the mentors of Sqoop and I should have spotted such thing before moving the vote to general@ I totally agree with Alex, more specifically I believe this is easy to solve. There is no problem to support some features or API(s) for backward compatibility but as Alex stated it should not be part of Apache's code, more specifically when it comes to be part of a TLP's code. I agree. And specifically as this seems to concern compatibility support for Cloudera own API, only needed for Cloudera customers. Keeping those com.cloudera packages in the code could imply a specific preference and affiliation with an external and commercial entity, thereby potentially jeopardizing the project independence. While I don't expect there was any intend to do so, even the impression itself can be considered harmful to the ASF and the project. The solution can be like packaging this code and host it on Cloudera or even Apache Extras [1] and a note is added to Sqoop website that if users want to have backward compatibility they should use that code besides the code of Apache. That sounds reasonable and hopefully easy to do (if not this case might even be more worrisome then). I'm not really sure though if Apache Extras is an appropriate location either. I think Apache Extras intends to convey an affiliation with the ASF and probably should value project independence high as well. If this really only concerns a thin layer to provide compatibility only for Cloudera's API, hosting and maintenance of this should be the responsibility of Cloudera itself. Ate Now the question is, and I ask this more specifically to the Sqoop people, Can you do this before the next board meeting, at least the extracting that code ? Cause if not I support Alex in that this vote should be cancelled and then we work out another one when Sqoop meets this criteria. Looking forward to your feedback! [1] - http://code.google.com/a/apache-extras.org/hosting/ On Tue, Feb 28, 2012 at 10:44 AM, Alex Karasuluakaras...@apache.orgwrote: On Tue, Feb 28, 2012 at 11:06 AM, Jukka Zittingjukka.zitt...@gmail.com wrote: Hi, On Tue, Feb 28, 2012 at 9:59 AM, Alex Karasuluakaras...@apache.org wrote: Cloudera's compatibility issues are not our problem. These packages need to go. Citation needed. I did not think we needed one: nor do I have one. It's common sense to me that this causes issues. It combines the namespace of a foreign mark with our own. We should not be releasing anything in the namespace belonging to another entity. Without a written policy to that effect these things are up for each project to decide. Jarek's rationale sounds perfectly fine to me. I highly respect you opinion here but I disagree regarding this argument provided. There may be no policy to cite, and there may be examples of where this was done before for the sake of backwards compatibility. It still does not justify doing it. We have plenty of projects that provide such backwards compatibility wrappers or otherwise put stuff in non-apache namespaces for various reasons. See for example [1] or [2]. Understood. Examples are solid points supporting the argument but IMHO I think this was a mistake that opens the door to several issues. Maybe we need some clear policy regarding the matter. I'm more than ready to be proven wrong on this matter so long as it does not present problems down the line for us. [1] http://svn.apache.org/repos/asf/subversion/trunk/subversion/bindings/javahl/ [2] http://svn.apache.org/repos/asf/geronimo/specs/trunk/ BR, Jukka Zitting -- Best Regards, -- Alex - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Graduate Sqoop podling from Apache Incubator
On Tue, Feb 28, 2012 at 3:01 PM, Ate Douma a...@douma.nu wrote: On 02/28/2012 01:46 PM, Mohammad Nour El-Din wrote: Hi... 1st of all, and I speaking about myself here, I believe this is partially my fault cause I am one of the mentors of Sqoop and I should have spotted such thing before moving the vote to general@ I totally agree with Alex, more specifically I believe this is easy to solve. There is no problem to support some features or API(s) for backward compatibility but as Alex stated it should not be part of Apache's code, more specifically when it comes to be part of a TLP's code. I agree. And specifically as this seems to concern compatibility support for Cloudera own API, only needed for Cloudera customers. Keeping those com.cloudera packages in the code could imply a specific preference and affiliation with an external and commercial entity, thereby potentially jeopardizing the project independence. While I don't expect there was any intend to do so, even the impression itself can be considered harmful to the ASF and the project. The solution can be like packaging this code and host it on Cloudera or even Apache Extras [1] and a note is added to Sqoop website that if users want to have backward compatibility they should use that code besides the code of Apache. That sounds reasonable and hopefully easy to do (if not this case might even be more worrisome then). I'm not really sure though if Apache Extras is an appropriate location either. I think Apache Extras intends to convey an affiliation with the ASF and probably should value project independence high as well. If this really only concerns a thin layer to provide compatibility only for Cloudera's API, hosting and maintenance of this should be the responsibility of Cloudera itself. Good point, I agree on this Ate Now the question is, and I ask this more specifically to the Sqoop people, Can you do this before the next board meeting, at least the extracting that code ? Cause if not I support Alex in that this vote should be cancelled and then we work out another one when Sqoop meets this criteria. Looking forward to your feedback! [1] - http://code.google.com/a/**apache-extras.org/hosting/http://code.google.com/a/apache-extras.org/hosting/ On Tue, Feb 28, 2012 at 10:44 AM, Alex Karasuluakaras...@apache.org** wrote: On Tue, Feb 28, 2012 at 11:06 AM, Jukka Zittingjukka.zitting@gmail.** com jukka.zitt...@gmail.com wrote: Hi, On Tue, Feb 28, 2012 at 9:59 AM, Alex Karasuluakaras...@apache.org wrote: Cloudera's compatibility issues are not our problem. These packages need to go. Citation needed. I did not think we needed one: nor do I have one. It's common sense to me that this causes issues. It combines the namespace of a foreign mark with our own. We should not be releasing anything in the namespace belonging to another entity. Without a written policy to that effect these things are up for each project to decide. Jarek's rationale sounds perfectly fine to me. I highly respect you opinion here but I disagree regarding this argument provided. There may be no policy to cite, and there may be examples of where this was done before for the sake of backwards compatibility. It still does not justify doing it. We have plenty of projects that provide such backwards compatibility wrappers or otherwise put stuff in non-apache namespaces for various reasons. See for example [1] or [2]. Understood. Examples are solid points supporting the argument but IMHO I think this was a mistake that opens the door to several issues. Maybe we need some clear policy regarding the matter. I'm more than ready to be proven wrong on this matter so long as it does not present problems down the line for us. [1] http://svn.apache.org/repos/**asf/subversion/trunk/** subversion/bindings/javahl/http://svn.apache.org/repos/asf/subversion/trunk/subversion/bindings/javahl/ [2] http://svn.apache.org/repos/**asf/geronimo/specs/trunk/http://svn.apache.org/repos/asf/geronimo/specs/trunk/ BR, Jukka Zitting -- Best Regards, -- Alex --**--**- To unsubscribe, e-mail: general-unsubscribe@incubator.**apache.orggeneral-unsubscr...@incubator.apache.org For additional commands, e-mail: general-help@incubator.apache.**orggeneral-h...@incubator.apache.org -- Thanks - Mohammad Nour Life is like riding a bicycle. To keep your balance you must keep moving - Albert Einstein
Re: [VOTE] Graduate Sqoop podling from Apache Incubator
On Tue, Feb 28, 2012 at 4:09 PM, Mohammad Nour El-Din nour.moham...@gmail.com wrote: On Tue, Feb 28, 2012 at 3:01 PM, Ate Douma a...@douma.nu wrote: On 02/28/2012 01:46 PM, Mohammad Nour El-Din wrote: Hi... 1st of all, and I speaking about myself here, I believe this is partially my fault cause I am one of the mentors of Sqoop and I should have spotted such thing before moving the vote to general@ I totally agree with Alex, more specifically I believe this is easy to solve. There is no problem to support some features or API(s) for backward compatibility but as Alex stated it should not be part of Apache's code, more specifically when it comes to be part of a TLP's code. I agree. And specifically as this seems to concern compatibility support for Cloudera own API, only needed for Cloudera customers. Keeping those com.cloudera packages in the code could imply a specific preference and affiliation with an external and commercial entity, thereby potentially jeopardizing the project independence. While I don't expect there was any intend to do so, even the impression itself can be considered harmful to the ASF and the project. The solution can be like packaging this code and host it on Cloudera or even Apache Extras [1] and a note is added to Sqoop website that if users want to have backward compatibility they should use that code besides the code of Apache. That sounds reasonable and hopefully easy to do (if not this case might even be more worrisome then). I'm not really sure though if Apache Extras is an appropriate location either. I think Apache Extras intends to convey an affiliation with the ASF and probably should value project independence high as well. If this really only concerns a thin layer to provide compatibility only for Cloudera's API, hosting and maintenance of this should be the responsibility of Cloudera itself. Good point, I agree on this +1 Ate Now the question is, and I ask this more specifically to the Sqoop people, Can you do this before the next board meeting, at least the extracting that code ? Cause if not I support Alex in that this vote should be cancelled and then we work out another one when Sqoop meets this criteria. Looking forward to your feedback! [1] - http://code.google.com/a/**apache-extras.org/hosting/ http://code.google.com/a/apache-extras.org/hosting/ On Tue, Feb 28, 2012 at 10:44 AM, Alex Karasuluakaras...@apache.org** wrote: On Tue, Feb 28, 2012 at 11:06 AM, Jukka Zittingjukka.zitting@gmail.** com jukka.zitt...@gmail.com wrote: Hi, On Tue, Feb 28, 2012 at 9:59 AM, Alex Karasuluakaras...@apache.org wrote: Cloudera's compatibility issues are not our problem. These packages need to go. Citation needed. I did not think we needed one: nor do I have one. It's common sense to me that this causes issues. It combines the namespace of a foreign mark with our own. We should not be releasing anything in the namespace belonging to another entity. Without a written policy to that effect these things are up for each project to decide. Jarek's rationale sounds perfectly fine to me. I highly respect you opinion here but I disagree regarding this argument provided. There may be no policy to cite, and there may be examples of where this was done before for the sake of backwards compatibility. It still does not justify doing it. We have plenty of projects that provide such backwards compatibility wrappers or otherwise put stuff in non-apache namespaces for various reasons. See for example [1] or [2]. Understood. Examples are solid points supporting the argument but IMHO I think this was a mistake that opens the door to several issues. Maybe we need some clear policy regarding the matter. I'm more than ready to be proven wrong on this matter so long as it does not present problems down the line for us. [1] http://svn.apache.org/repos/**asf/subversion/trunk/** subversion/bindings/javahl/ http://svn.apache.org/repos/asf/subversion/trunk/subversion/bindings/javahl/ [2] http://svn.apache.org/repos/**asf/geronimo/specs/trunk/ http://svn.apache.org/repos/asf/geronimo/specs/trunk/ BR, Jukka Zitting -- Best Regards, -- Alex --**--**- To unsubscribe, e-mail: general-unsubscribe@incubator.**apache.org general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-help@incubator.apache.**org general-h...@incubator.apache.org -- Thanks - Mohammad Nour Life is like riding a bicycle. To keep your balance you must keep moving - Albert Einstein -- Best Regards, -- Alex
Re: [VOTE] Graduate Sqoop podling from Apache Incubator
On Tue, Feb 28, 2012 at 1:06 AM, Jukka Zitting jukka.zitt...@gmail.com wrote: On Tue, Feb 28, 2012 at 9:59 AM, Alex Karasulu akaras...@apache.org wrote: Cloudera's compatibility issues are not our problem. These packages need to go. Citation needed. Without a written policy to that effect these things are up for each project to decide. Jarek's rationale sounds perfectly fine to me. We have plenty of projects that provide such backwards compatibility wrappers or otherwise put stuff in non-apache namespaces for various reasons. See for example [1] or [2]. [1] http://svn.apache.org/repos/asf/subversion/trunk/subversion/bindings/javahl/ [2] http://svn.apache.org/repos/asf/geronimo/specs/trunk/ I agree with Jukka on this. There is no such policy. There are examples of well established TLPs doing similar. The files are explicitly deprecated and will be eventually removed, they are for the convenience of users and others building on top of Sqoop who are migrating from the original code base to Apache based packages. It makes total sense to provide a bridge that enables that group to move to the Apache version of the code. Patrick - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Graduate Sqoop podling from Apache Incubator
On Feb 28, 2012, at 9:16 AM, Patrick Hunt wrote: On Tue, Feb 28, 2012 at 1:06 AM, Jukka Zitting jukka.zitt...@gmail.com wrote: On Tue, Feb 28, 2012 at 9:59 AM, Alex Karasulu akaras...@apache.org wrote: Cloudera's compatibility issues are not our problem. These packages need to go. Citation needed. Without a written policy to that effect these things are up for each project to decide. Jarek's rationale sounds perfectly fine to me. We have plenty of projects that provide such backwards compatibility wrappers or otherwise put stuff in non-apache namespaces for various reasons. See for example [1] or [2]. [1] http://svn.apache.org/repos/asf/subversion/trunk/subversion/bindings/javahl/ [2] http://svn.apache.org/repos/asf/geronimo/specs/trunk/ I agree with Jukka on this. There is no such policy. There are examples of well established TLPs doing similar. The files are explicitly deprecated and will be eventually removed, they are for the convenience of users and others building on top of Sqoop who are migrating from the original code base to Apache based packages. It makes total sense to provide a bridge that enables that group to move to the Apache version of the code. I'm not sure that JSR specs are the same as old Cloudera code. JMHO. As for the Tigris/Subversion code I am surprised that they allowed it. I am surprised that the Foundation would allow the Subversion project to allow it. Normally I would be in the same boat as Jukka and Patrick in curbing the usual ad hoc requirements that IPMC members seem to tack on to votes but I think that this problem is quite a different animal, in my opinion. I don't see the technical requirement that this code needs to stay at Apache and not Cloudera. Regards, Alan - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Graduate Sqoop podling from Apache Incubator
On Tue, Feb 28, 2012 at 9:57 AM, Alan D. Cabrera l...@toolazydogs.com wrote: On Feb 28, 2012, at 9:16 AM, Patrick Hunt wrote: On Tue, Feb 28, 2012 at 1:06 AM, Jukka Zitting jukka.zitt...@gmail.com wrote: On Tue, Feb 28, 2012 at 9:59 AM, Alex Karasulu akaras...@apache.org wrote: I'm not sure that JSR specs are the same as old Cloudera code. JMHO. How about phrasing it as old Sqoop code instead. :-) Really it's about respect for existing users and others migrating to Apache. It's also about respect for the people doing the work. That's my understanding from discussions with the team at least. I don't see the technical requirement that this code needs to stay at Apache and not Cloudera. I agree that this potentially could be an issue, but whether it's a technical requirement is up to the team who's doing the work. If Apache feels that there is a requirement that no project releases code/document/etc... under any package other than org.apache.* then that should be clearly defined and communicated. At this point my understanding is there is no such requirement. Patrick - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Graduate Sqoop podling from Apache Incubator
On Tue, Feb 28, 2012 at 8:13 PM, Patrick Hunt ph...@apache.org wrote: On Tue, Feb 28, 2012 at 9:57 AM, Alan D. Cabrera l...@toolazydogs.com wrote: On Feb 28, 2012, at 9:16 AM, Patrick Hunt wrote: On Tue, Feb 28, 2012 at 1:06 AM, Jukka Zitting jukka.zitt...@gmail.com wrote: On Tue, Feb 28, 2012 at 9:59 AM, Alex Karasulu akaras...@apache.org wrote: I'm not sure that JSR specs are the same as old Cloudera code. JMHO. How about phrasing it as old Sqoop code instead. :-) Really it's about respect for existing users and others migrating to Apache. It's also about respect for the people doing the work. That's my understanding from discussions with the team at least. I don't see the technical requirement that this code needs to stay at Apache and not Cloudera. I agree that this potentially could be an issue, but whether it's a technical requirement is up to the team who's doing the work. If Apache feels that there is a requirement that no project releases code/document/etc... under any package other than org.apache.* then that should be clearly defined and communicated. At this point my understanding is there is no such requirement. The Incubator is a work in progress, just like anything else here. I think this is a policy we should adhere too from this point forward. The technical problem is small in comparison to other issues this brings into play. -- Best Regards, -- Alex
Re: [VOTE] Graduate Sqoop podling from Apache Incubator
On Tue, Feb 28, 2012 at 10:20 AM, Alex Karasulu akaras...@apache.org wrote: On Tue, Feb 28, 2012 at 8:13 PM, Patrick Hunt ph...@apache.org wrote: I agree that this potentially could be an issue, but whether it's a technical requirement is up to the team who's doing the work. If Apache feels that there is a requirement that no project releases code/document/etc... under any package other than org.apache.* then that should be clearly defined and communicated. At this point my understanding is there is no such requirement. I think this is a policy we should adhere too from this point forward. Apache wide policy or incubator policy? If it's not Apache wide then any project could just wait till graduation and do as they see fit. The idea of incubation is to ensure that a podling adheres to Apache policy before being let loose to run itself. If we make this an incubator only restriction we're saying that that's not the case. The technical problem is small in comparison to other issues this brings into play. What issues? That people will be confused about whether Apache released/branded code, downloaded from Apache, where the majority of the code is org.apache packaged, but some subset of clearly marked deprecated code, defined as an aid for migration is Apache or not? Doesn't seem like an issue to me. Patrick - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Graduate Sqoop podling from Apache Incubator
On Tue, Feb 28, 2012 at 8:34 PM, Patrick Hunt ph...@apache.org wrote: On Tue, Feb 28, 2012 at 10:20 AM, Alex Karasulu akaras...@apache.org wrote: On Tue, Feb 28, 2012 at 8:13 PM, Patrick Hunt ph...@apache.org wrote: I agree that this potentially could be an issue, but whether it's a technical requirement is up to the team who's doing the work. If Apache feels that there is a requirement that no project releases code/document/etc... under any package other than org.apache.* then that should be clearly defined and communicated. At this point my understanding is there is no such requirement. I think this is a policy we should adhere too from this point forward. Apache wide policy or incubator policy? If it's not Apache wide then any project could just wait till graduation and do as they see fit. The idea of incubation is to ensure that a podling adheres to Apache policy before being let loose to run itself. If we make this an incubator only restriction we're saying that that's not the case. That's a good point. The technical problem is small in comparison to other issues this brings into play. What issues? That people will be confused about whether Apache released/branded code, downloaded from Apache, where the majority of the code is org.apache packaged, but some subset of clearly marked deprecated code, defined as an aid for migration is Apache or not? Doesn't seem like an issue to me. I think the issues were amply expressed in this thread. Just take a look at what Ate, Mo, and I said earlier. -- Best Regards, -- Alex
Re: [VOTE] Graduate Sqoop podling from Apache Incubator
On Feb 28, 2012, at 10:13 AM, Patrick Hunt wrote:
On Tue, Feb 28, 2012 at 9:57 AM, Alan D. Cabrera l...@toolazydogs.com wrote:
On Feb 28, 2012, at 9:16 AM, Patrick Hunt wrote:
On Tue, Feb 28, 2012 at 1:06 AM, Jukka Zitting jukka.zitt...@gmail.com
wrote:
On Tue, Feb 28, 2012 at 9:59 AM, Alex Karasulu akaras...@apache.org
wrote:
I'm not sure that JSR specs are the same as old Cloudera code. JMHO.
How about phrasing it as old Sqoop code instead. :-)
Really it's about respect for existing users and others migrating to
Apache. It's also about respect for the people doing the work. That's
my understanding from discussions with the team at least.
I don't see the technical requirement that this code needs to stay at Apache
and not Cloudera.
I agree that this potentially could be an issue, but whether it's a
technical requirement is up to the team who's doing the work. If
Apache feels that there is a requirement that no project releases
code/document/etc... under any package other than org.apache.* then
that should be clearly defined and communicated. At this point my
understanding is there is no such requirement.
public class MySQLManager
extends org.apache.sqoop.manager.MySQLManager {
public MySQLManager(final SqoopOptions opts) {
super(opts);
}
}
If all the code is like this it is absolutely ridiculous to have this at Apache
and not Cloudera.
Regards,
Alan
Re: [VOTE] Graduate Sqoop podling from Apache Incubator
On Tue, Feb 28, 2012 at 10:39 AM, Alan D. Cabrera l...@toolazydogs.com wrote:
On Feb 28, 2012, at 10:13 AM, Patrick Hunt wrote:
On Tue, Feb 28, 2012 at 9:57 AM, Alan D. Cabrera l...@toolazydogs.com
wrote:
On Feb 28, 2012, at 9:16 AM, Patrick Hunt wrote:
On Tue, Feb 28, 2012 at 1:06 AM, Jukka Zitting jukka.zitt...@gmail.com
wrote:
On Tue, Feb 28, 2012 at 9:59 AM, Alex Karasulu akaras...@apache.org
wrote:
I'm not sure that JSR specs are the same as old Cloudera code. JMHO.
How about phrasing it as old Sqoop code instead. :-)
Really it's about respect for existing users and others migrating to
Apache. It's also about respect for the people doing the work. That's
my understanding from discussions with the team at least.
I don't see the technical requirement that this code needs to stay at
Apache and not Cloudera.
I agree that this potentially could be an issue, but whether it's a
technical requirement is up to the team who's doing the work. If
Apache feels that there is a requirement that no project releases
code/document/etc... under any package other than org.apache.* then
that should be clearly defined and communicated. At this point my
understanding is there is no such requirement.
public class MySQLManager
extends org.apache.sqoop.manager.MySQLManager {
public MySQLManager(final SqoopOptions opts) {
super(opts);
}
}
If all the code is like this it is absolutely ridiculous to have this at
Apache and not Cloudera.
Please see [1] for details on why the code is like this. The short
summary is that binary compatibility requires us to respect all
extension points within the code.
[1] https://cwiki.apache.org/confluence/display/SQOOP/Namespace+Migration
Regards,
Alan
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Graduate Sqoop podling from Apache Incubator
On 02/28/2012 12:59 AM, Alex Karasulu wrote: That namespace is a mark of Cloudera. Package names are not generally considered to be trademarks. Doug - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Graduate Sqoop podling from Apache Incubator
On 02/28/2012 06:01 AM, Ate Douma wrote: And specifically as this seems to concern compatibility support for Cloudera own API, only needed for Cloudera customers. Sqoop was an Apache-licensed open source project at Github before it came to Apache. It's thus safe to assume that it had users who were not Cloudera customers before it came to Apache. Doug - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Graduate Sqoop podling from Apache Incubator
On Tue, Feb 28, 2012 at 10:39 AM, Alan D. Cabrera l...@toolazydogs.com wrote:
On Feb 28, 2012, at 10:13 AM, Patrick Hunt wrote:
On Tue, Feb 28, 2012 at 9:57 AM, Alan D. Cabrera l...@toolazydogs.com
wrote:
On Feb 28, 2012, at 9:16 AM, Patrick Hunt wrote:
On Tue, Feb 28, 2012 at 1:06 AM, Jukka Zitting jukka.zitt...@gmail.com
wrote:
On Tue, Feb 28, 2012 at 9:59 AM, Alex Karasulu akaras...@apache.org
wrote:
public class MySQLManager
extends org.apache.sqoop.manager.MySQLManager {
public MySQLManager(final SqoopOptions opts) {
super(opts);
}
}
If all the code is like this it is absolutely ridiculous to have this at
Apache and not Cloudera.
This is a code issue, which is up the the team
(committers/pmc/community) doing the work. If they want to include
such code it's up to them. They are doing the work.
What's really at issue here is whether all (java) code at Apache MUST
be under org.apache.* package structure or not. afaik there is
currently no such requirement. If Apache decides to make it a
requirement then great, I'm sure the Sqoop team will make the
necessary changes.
We should also give Arvind and the rest of the Sqoop community some
indication how to proceed, given the voting period is completed.
Patrick
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Graduate Sqoop podling from Apache Incubator
On Feb 28, 2012, at 10:53 AM, Arvind Prabhakar wrote:
On Tue, Feb 28, 2012 at 10:39 AM, Alan D. Cabrera l...@toolazydogs.com
wrote:
On Feb 28, 2012, at 10:13 AM, Patrick Hunt wrote:
On Tue, Feb 28, 2012 at 9:57 AM, Alan D. Cabrera l...@toolazydogs.com
wrote:
On Feb 28, 2012, at 9:16 AM, Patrick Hunt wrote:
On Tue, Feb 28, 2012 at 1:06 AM, Jukka Zitting jukka.zitt...@gmail.com
wrote:
On Tue, Feb 28, 2012 at 9:59 AM, Alex Karasulu akaras...@apache.org
wrote:
I'm not sure that JSR specs are the same as old Cloudera code. JMHO.
How about phrasing it as old Sqoop code instead. :-)
Really it's about respect for existing users and others migrating to
Apache. It's also about respect for the people doing the work. That's
my understanding from discussions with the team at least.
I don't see the technical requirement that this code needs to stay at
Apache and not Cloudera.
I agree that this potentially could be an issue, but whether it's a
technical requirement is up to the team who's doing the work. If
Apache feels that there is a requirement that no project releases
code/document/etc... under any package other than org.apache.* then
that should be clearly defined and communicated. At this point my
understanding is there is no such requirement.
public class MySQLManager
extends org.apache.sqoop.manager.MySQLManager {
public MySQLManager(final SqoopOptions opts) {
super(opts);
}
}
If all the code is like this it is absolutely ridiculous to have this at
Apache and not Cloudera.
Please see [1] for details on why the code is like this. The short
summary is that binary compatibility requires us to respect all
extension points within the code.
[1] https://cwiki.apache.org/confluence/display/SQOOP/Namespace+Migration
IIUC, this document merely outlines how the move should be performed. This has
been completed and what's left are bindings for those who wish to use the old
bindings from the old project. There's no technical reason why those bindings
for the old project must be housed here at Apache.
Regards,
Alan
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Graduate Sqoop podling from Apache Incubator
On Tue, Feb 28, 2012 at 11:19 AM, Alan D. Cabrera l...@toolazydogs.com wrote:
On Feb 28, 2012, at 10:53 AM, Arvind Prabhakar wrote:
On Tue, Feb 28, 2012 at 10:39 AM, Alan D. Cabrera l...@toolazydogs.com
wrote:
On Feb 28, 2012, at 10:13 AM, Patrick Hunt wrote:
On Tue, Feb 28, 2012 at 9:57 AM, Alan D. Cabrera l...@toolazydogs.com
wrote:
On Feb 28, 2012, at 9:16 AM, Patrick Hunt wrote:
On Tue, Feb 28, 2012 at 1:06 AM, Jukka Zitting jukka.zitt...@gmail.com
wrote:
On Tue, Feb 28, 2012 at 9:59 AM, Alex Karasulu akaras...@apache.org
wrote:
I'm not sure that JSR specs are the same as old Cloudera code. JMHO.
How about phrasing it as old Sqoop code instead. :-)
Really it's about respect for existing users and others migrating to
Apache. It's also about respect for the people doing the work. That's
my understanding from discussions with the team at least.
I don't see the technical requirement that this code needs to stay at
Apache and not Cloudera.
I agree that this potentially could be an issue, but whether it's a
technical requirement is up to the team who's doing the work. If
Apache feels that there is a requirement that no project releases
code/document/etc... under any package other than org.apache.* then
that should be clearly defined and communicated. At this point my
understanding is there is no such requirement.
public class MySQLManager
extends org.apache.sqoop.manager.MySQLManager {
public MySQLManager(final SqoopOptions opts) {
super(opts);
}
}
If all the code is like this it is absolutely ridiculous to have this at
Apache and not Cloudera.
Please see [1] for details on why the code is like this. The short
summary is that binary compatibility requires us to respect all
extension points within the code.
[1] https://cwiki.apache.org/confluence/display/SQOOP/Namespace+Migration
IIUC, this document merely outlines how the move should be performed. This
has been completed and what's left are bindings for those who wish to use the
old bindings from the old project. There's no technical reason why those
bindings for the old project must be housed here at Apache.
You are right that it outlines how the move should be performed. Along
with that it also describes the motivation and specific technical
requirements to be fulfilled. Following are the relevant quotes from
the document:
[From Overview - Motivation]
Considering that there is a lot of third party code that is developed
on top of/to work with Sqoop, this migration is particularly risky for
backward compatibility and thus requires careful handling. This
document outlines the steps that seem reasonable for such migration.
[From Migration-General Approach - Technical Requirement]
When migrating a class from its previous namespace to the new, the key
requirement to address is that any code written to the old class
should still work at binary compatibility level. This also implies
that such code should be able to recompile with the migrated code base
without any modifications. In order to enable this, the general
approach is as follows:
* Any old public/protected/default access level API should be
preserved as is, but marked deprecated.
* Any logic that exists in this API should be migrated to the new namespace.
Note that API is not just method signatures but includes all aspects
of implementation such as class hierarchies, type compatibility,
static and non-static state etc.
Thanks,
Arvind Prabhakar
Regards,
Alan
-
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: [VOTE] Graduate Sqoop podling from Apache Incubator
On Feb 28, 2012, at 10:56 AM, Patrick Hunt wrote:
On Tue, Feb 28, 2012 at 10:39 AM, Alan D. Cabrera l...@toolazydogs.com
wrote:
On Feb 28, 2012, at 10:13 AM, Patrick Hunt wrote:
On Tue, Feb 28, 2012 at 9:57 AM, Alan D. Cabrera l...@toolazydogs.com
wrote:
On Feb 28, 2012, at 9:16 AM, Patrick Hunt wrote:
On Tue, Feb 28, 2012 at 1:06 AM, Jukka Zitting jukka.zitt...@gmail.com
wrote:
On Tue, Feb 28, 2012 at 9:59 AM, Alex Karasulu akaras...@apache.org
wrote:
public class MySQLManager
extends org.apache.sqoop.manager.MySQLManager {
public MySQLManager(final SqoopOptions opts) {
super(opts);
}
}
If all the code is like this it is absolutely ridiculous to have this at
Apache and not Cloudera.
This is a code issue, which is up the the team
(committers/pmc/community) doing the work. If they want to include
such code it's up to them. They are doing the work.
What's really at issue here is whether all (java) code at Apache MUST
be under org.apache.* package structure or not. afaik there is
currently no such requirement. If Apache decides to make it a
requirement then great, I'm sure the Sqoop team will make the
necessary changes.
Part of Incubation has always been the migration to the org.apache.* package
space. I still don't see why it's a requirement for Apache to house code
whose sole use is to provide backward compatible bindings for Cloudera's old
bindings.
We should also give Arvind and the rest of the Sqoop community some
indication how to proceed, given the voting period is completed.
A concern has been raised by IPMC members and an effort is being made to garner
consensus. The voting period is on hold.
Regards,
Alan
Re: [VOTE] Graduate Sqoop podling from Apache Incubator
On Feb 28, 2012, at 11:29 AM, Arvind Prabhakar wrote:
On Tue, Feb 28, 2012 at 11:19 AM, Alan D. Cabrera l...@toolazydogs.com
wrote:
On Feb 28, 2012, at 10:53 AM, Arvind Prabhakar wrote:
On Tue, Feb 28, 2012 at 10:39 AM, Alan D. Cabrera l...@toolazydogs.com
wrote:
On Feb 28, 2012, at 10:13 AM, Patrick Hunt wrote:
On Tue, Feb 28, 2012 at 9:57 AM, Alan D. Cabrera l...@toolazydogs.com
wrote:
On Feb 28, 2012, at 9:16 AM, Patrick Hunt wrote:
On Tue, Feb 28, 2012 at 1:06 AM, Jukka Zitting
jukka.zitt...@gmail.com wrote:
On Tue, Feb 28, 2012 at 9:59 AM, Alex Karasulu akaras...@apache.org
wrote:
I'm not sure that JSR specs are the same as old Cloudera code. JMHO.
How about phrasing it as old Sqoop code instead. :-)
Really it's about respect for existing users and others migrating to
Apache. It's also about respect for the people doing the work. That's
my understanding from discussions with the team at least.
I don't see the technical requirement that this code needs to stay at
Apache and not Cloudera.
I agree that this potentially could be an issue, but whether it's a
technical requirement is up to the team who's doing the work. If
Apache feels that there is a requirement that no project releases
code/document/etc... under any package other than org.apache.* then
that should be clearly defined and communicated. At this point my
understanding is there is no such requirement.
public class MySQLManager
extends org.apache.sqoop.manager.MySQLManager {
public MySQLManager(final SqoopOptions opts) {
super(opts);
}
}
If all the code is like this it is absolutely ridiculous to have this at
Apache and not Cloudera.
Please see [1] for details on why the code is like this. The short
summary is that binary compatibility requires us to respect all
extension points within the code.
[1] https://cwiki.apache.org/confluence/display/SQOOP/Namespace+Migration
IIUC, this document merely outlines how the move should be performed. This
has been completed and what's left are bindings for those who wish to use
the old bindings from the old project. There's no technical reason why
those bindings for the old project must be housed here at Apache.
You are right that it outlines how the move should be performed. Along
with that it also describes the motivation and specific technical
requirements to be fulfilled. Following are the relevant quotes from
the document:
[From Overview - Motivation]
Considering that there is a lot of third party code that is developed
on top of/to work with Sqoop, this migration is particularly risky for
backward compatibility and thus requires careful handling. This
document outlines the steps that seem reasonable for such migration.
[From Migration-General Approach - Technical Requirement]
When migrating a class from its previous namespace to the new, the key
requirement to address is that any code written to the old class
should still work at binary compatibility level. This also implies
that such code should be able to recompile with the migrated code base
without any modifications. In order to enable this, the general
approach is as follows:
* Any old public/protected/default access level API should be
preserved as is, but marked deprecated.
* Any logic that exists in this API should be migrated to the new namespace.
Note that API is not just method signatures but includes all aspects
of implementation such as class hierarchies, type compatibility,
static and non-static state etc.
I think that it's good to have binary compatibility with Cloudera's old
bindings. I still don't see why it's a requirement for Apache to house code
whose sole use is to provide backward compatible bindings for Cloudera's old
bindings.
Regards,
Alan
Re: [VOTE] Graduate Sqoop podling from Apache Incubator
On Feb 28, 2012, at 11:39 AM, Alan D. Cabrera wrote: We should also give Arvind and the rest of the Sqoop community some indication how to proceed, given the voting period is completed. A concern has been raised by IPMC members and an effort is being made to garner consensus. The voting period is on hold. Opps, I didn't see that Arvind concluded the vote. I still stand by my opinion that there are some things that are not solely up to the people that are doing the work. Complete migration to the the org.apache.* package space is one of them. I ask the Apache Sqoop community to please remove the Cloudera packaged source code at their earliest convenience. Regards, Alan
Re: [VOTE] Graduate Sqoop podling from Apache Incubator
Note that API is not just method signatures but includes all aspects of implementation such as class hierarchies, type compatibility, static and non-static state etc. I think that it's good to have binary compatibility with Cloudera's old bindings. I still don't see why it's a requirement for Apache to house code whose sole use is to provide backward compatible bindings for Cloudera's old bindings. The Sqoop community moved from github where it was ASL licensed to Apache. There is now a Sqoop community at Apache that continues using/developing this code and they felt that having backward compatibility was useful. There is no stated restriction from Apache against doing such. I don't know the cost of just dropping the com.cloudera migration aids, but I suspect it would have been easier to just drop it than spend the time worrying about it and trying to provide a solution. I'm primarily acting as a mentor, Arvind would be in better position to provide insight into that background and why the community felt it was important to carry this forward. Patrick - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Graduate Sqoop podling from Apache Incubator
On Tue, Feb 28, 2012 at 12:24 PM, Alan D. Cabrera a...@toolazydogs.com wrote: On Feb 28, 2012, at 11:39 AM, Alan D. Cabrera wrote: We should also give Arvind and the rest of the Sqoop community some indication how to proceed, given the voting period is completed. A concern has been raised by IPMC members and an effort is being made to garner consensus. The voting period is on hold. Opps, I didn't see that Arvind concluded the vote. I still stand by my opinion that there are some things that are not solely up to the people that are doing the work. Complete migration to the the org.apache.* package space is one of them. No worries. I respect your opinion and if Apache feels that this is important enough to make explicit then certainly Sqoop should make the changes. Short of that I don't see why we should hold Sqoop to a higher standard than is expected of other Apache projects. (that's _my_ opinion ;-) ) Regards! Patrick - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Graduate Sqoop podling from Apache Incubator
On Tue, Feb 28, 2012 at 12:51 PM, Patrick Hunt ph...@apache.org wrote: Note that API is not just method signatures but includes all aspects of implementation such as class hierarchies, type compatibility, static and non-static state etc. I think that it's good to have binary compatibility with Cloudera's old bindings. I still don't see why it's a requirement for Apache to house code whose sole use is to provide backward compatible bindings for Cloudera's old bindings. The Sqoop community moved from github where it was ASL licensed to Apache. There is now a Sqoop community at Apache that continues using/developing this code and they felt that having backward compatibility was useful. There is no stated restriction from Apache against doing such. I don't know the cost of just dropping the com.cloudera migration aids, but I suspect it would have been easier to just drop it than spend the time worrying about it and trying to provide a solution. I'm primarily acting as a mentor, Arvind would be in better position to provide insight into that background and why the community felt it was important to carry this forward. Thanks Patrick. You are absolutely right in stating that it would have been easier for us 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. One thing I want to clarify is that any insinuation that com.cloudera.* packages exist in Sqoop is to somehow help Cloudera and it's customers couldn't be farther from the truth. The fact is that Cloudera will continue to provide support for Sqoop with backward compatibility regardless of whether the com.cloudera.* namespace is retained or removed from Sqoop. If we decided to remove these packages, it is the community that will suffer, not Cloudera. I do believe that if this is only an Incubator policy and not an Apache policy, it will be tantamount to discrimination against the Sqoop community more than anything else. To say that JSR specs are not the same as old Cloudera code, gives me the impression that some communities have more power on how Apache implements its policies for larger communities than on smaller communities. If that is indeed the case, it will help to state that explicitly. Thanks, Arvind Prabhakar Patrick - 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: [VOTE] Graduate Sqoop podling from Apache Incubator
Hi, On Tue, Feb 28, 2012 at 9:53 PM, Patrick Hunt ph...@apache.org wrote: On Tue, Feb 28, 2012 at 12:24 PM, Alan D. Cabrera a...@toolazydogs.com wrote: Opps, I didn't see that Arvind concluded the vote. I still stand by my opinion that there are some things that are not solely up to the people that are doing the work. Complete migration to the the org.apache.* package space is one of them. No worries. I respect your opinion and if Apache feels that this is important enough to make explicit then certainly Sqoop should make the changes. Short of that I don't see why we should hold Sqoop to a higher standard than is expected of other Apache projects. (that's _my_ opinion ;-) ) Right. Basically the graduation vote by the IPMC is about determining whether the PPMC is capable of conducting itself according to the Apache Way and Apache policies on it's own. I didn't have time to look deeper into Sqoop yet, but all the +1s in this vote suggest that the Sqoop PPMC is ready to take on that responsibility. Along with that responsibility comes the right to make value judgements on topics like this where existing policies aren't clearly spelled out. Personally I think we should let the vote result stand with guidance to the new Sqoop PMC to discuss the matter with the branding team at trademarks@ to seek Apache-wide consensus. I encourage anyone who feels strongly about this (the point being made clearly has some merit) make their case to trademarks@ as it's IMHO not really the task of the Incubator to be forming new policy on this, especially with all the recent talk about scaling down the ambitions of the IPMC. BR, Jukka Zitting - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Graduate Sqoop podling from Apache Incubator
On Tue, Feb 28, 2012 at 1:25 PM, Jukka Zitting jukka.zitt...@gmail.com wrote: Hi, On Tue, Feb 28, 2012 at 9:53 PM, Patrick Hunt ph...@apache.org wrote: On Tue, Feb 28, 2012 at 12:24 PM, Alan D. Cabrera a...@toolazydogs.com wrote: Opps, I didn't see that Arvind concluded the vote. I still stand by my opinion that there are some things that are not solely up to the people that are doing the work. Complete migration to the the org.apache.* package space is one of them. No worries. I respect your opinion and if Apache feels that this is important enough to make explicit then certainly Sqoop should make the changes. Short of that I don't see why we should hold Sqoop to a higher standard than is expected of other Apache projects. (that's _my_ opinion ;-) ) Right. Basically the graduation vote by the IPMC is about determining whether the PPMC is capable of conducting itself according to the Apache Way and Apache policies on it's own. I didn't have time to look deeper into Sqoop yet, but all the +1s in this vote suggest that the Sqoop PPMC is ready to take on that responsibility. Along with that responsibility comes the right to make value judgements on topics like this where existing policies aren't clearly spelled out. 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 Personally I think we should let the vote result stand with guidance to the new Sqoop PMC to discuss the matter with the branding team at trademarks@ to seek Apache-wide consensus. I encourage anyone who feels strongly about this (the point being made clearly has some merit) make their case to trademarks@ as it's IMHO not really the task of the Incubator to be forming new policy on this, especially with all the recent talk about scaling down the ambitions of the IPMC. This sounds like a great solution that addresses the concern and does not unduly penalize the Sqoop project. On behalf of Sqoop PMC, I will be happy to take this up with the branding team and trademarks@ to drive a definitive resolution. I also volunteer personally to discuss and seek Apache-wide consensus on this issue for not only the benefit of Sqoop, but for other projects who may be in this state inside or outside of the Incubator. Thanks, Arvind Prabhakar BR, Jukka Zitting - 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: [VOTE] Graduate Sqoop podling from Apache Incubator
On Tue, Feb 28, 2012 at 11:25 PM, Jukka Zitting jukka.zitt...@gmail.comwrote: Hi, On Tue, Feb 28, 2012 at 9:53 PM, Patrick Hunt ph...@apache.org wrote: On Tue, Feb 28, 2012 at 12:24 PM, Alan D. Cabrera a...@toolazydogs.com wrote: Opps, I didn't see that Arvind concluded the vote. I still stand by my opinion that there are some things that are not solely up to the people that are doing the work. Complete migration to the the org.apache.* package space is one of them. No worries. I respect your opinion and if Apache feels that this is important enough to make explicit then certainly Sqoop should make the changes. Short of that I don't see why we should hold Sqoop to a higher standard than is expected of other Apache projects. (that's _my_ opinion ;-) ) Right. It's not that anyone is holding Scoop to a higher standard. We just noticed the issue now. I noticed because I'm a mentor on another project along side Alan and since he posted I paid closer attention. I cannot and don't track every podling. To be honest this is the first real encounter I've had with Scoop. Sounds like something I could use :-) too. I want to see Scoop graduate. I certainly don't want the Scoop guys thinking who's this jerk getting in our way. So I, nor the other's expressing concerns have anything against the Scoop team. It's just chance that this project triggered the discussion. No one is against Cloudera either. I don't know why people are bothering pointing out the project came to the ASF Incubator from Github. Github is just a repository. If you want to know where the code really came from then check who the majority of contributors were before incubation. It makes no difference: Cloudera or Github. The problem for us still persists. Basically the graduation vote by the IPMC is about determining whether the PPMC is capable of conducting itself according to the Apache Way and Apache policies on it's own. I don't understand the rush to graduate. What difference does a month make in the grand scheme of things? The sudden vehement push to include these packages worries me. Graduating should not be more important than addressing valid concerns. I didn't have time to look deeper into Sqoop yet, but all the +1s in this vote suggest that the Sqoop PPMC is ready to take on that responsibility. Rather than crudely drop a -1 we voiced our concerns as IPMC members, and mentors to open up discussion about the matter. It's easy to drop the package and solve the technical problem. If you need a -1 to stop the process then you have mine. Along with that responsibility comes the right to make value judgements on topics like this where existing policies aren't clearly spelled out. Honestly I've begun to be concerned after watching how vehemently the Cloudera people came out of the woodwork to push graduation no matter what concerns were expressed. IMHO that's not in line with the Apache Way as far as our culture goes. So yes the impatience is triggering me to be doubtful of their ability to handle the responsibility. At the end of the day no project is more important than the ASF as a whole. Personally I think we should let the vote result stand with guidance to the new Sqoop PMC to discuss the matter with the branding team at trademarks@ to seek Apache-wide consensus. I encourage anyone who feels strongly about this (the point being made clearly has some merit) make their case to trademarks@ as it's IMHO not really the task of the Incubator to be forming new policy on this, especially with all the recent talk about scaling down the ambitions of the IPMC. That's a good point and to a really large extent I agree with you. However this is one of the last lines of defense we have before it becomes much harder to rectify. While we have the issue on the radar let's take care of it now. That will provide more drive to resolve it quickly. So I'd rather get clarification on this grey area ASAP. I certainly cannot brush it under the rug after noticing it. So let's play it safe, get some resolution, then proceed forward. That's the best approach IMHO. Graduation will occur in the near future so let's not sweat it. -- Best Regards, -- Alex
Re: [VOTE] Graduate Sqoop podling from Apache Incubator
On Tue, Feb 28, 2012 at 11:39 PM, Arvind Prabhakar arv...@apache.orgwrote: On Tue, Feb 28, 2012 at 1:25 PM, Jukka Zitting jukka.zitt...@gmail.com wrote: Hi, On Tue, Feb 28, 2012 at 9:53 PM, Patrick Hunt ph...@apache.org wrote: On Tue, Feb 28, 2012 at 12:24 PM, Alan D. Cabrera a...@toolazydogs.com wrote: Opps, I didn't see that Arvind concluded the vote. I still stand by my opinion that there are some things that are not solely up to the people that are doing the work. Complete migration to the the org.apache.* package space is one of them. No worries. I respect your opinion and if Apache feels that this is important enough to make explicit then certainly Sqoop should make the changes. Short of that I don't see why we should hold Sqoop to a higher standard than is expected of other Apache projects. (that's _my_ opinion ;-) ) Right. Basically the graduation vote by the IPMC is about determining whether the PPMC is capable of conducting itself according to the Apache Way and Apache policies on it's own. I didn't have time to look deeper into Sqoop yet, but all the +1s in this vote suggest that the Sqoop PPMC is ready to take on that responsibility. Along with that responsibility comes the right to make value judgements on topics like this where existing policies aren't clearly spelled out. 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 Personally I think we should let the vote result stand with guidance to the new Sqoop PMC to discuss the matter with the branding team at trademarks@ to seek Apache-wide consensus. I encourage anyone who feels strongly about this (the point being made clearly has some merit) make their case to trademarks@ as it's IMHO not really the task of the Incubator to be forming new policy on this, especially with all the recent talk about scaling down the ambitions of the IPMC. This sounds like a great solution that addresses the concern and does not unduly penalize the Sqoop project. You really should not be seeing this as being penalized. It's not about that. Alex
Re: [VOTE] Graduate Sqoop podling from Apache Incubator
On Tue, Feb 28, 2012 at 2:50 PM, Alex Karasulu akaras...@apache.org wrote: On Tue, Feb 28, 2012 at 11:39 PM, Arvind Prabhakar arv...@apache.orgwrote: On Tue, Feb 28, 2012 at 1:25 PM, Jukka Zitting jukka.zitt...@gmail.com wrote: Hi, On Tue, Feb 28, 2012 at 9:53 PM, Patrick Hunt ph...@apache.org wrote: On Tue, Feb 28, 2012 at 12:24 PM, Alan D. Cabrera a...@toolazydogs.com wrote: Opps, I didn't see that Arvind concluded the vote. I still stand by my opinion that there are some things that are not solely up to the people that are doing the work. Complete migration to the the org.apache.* package space is one of them. No worries. I respect your opinion and if Apache feels that this is important enough to make explicit then certainly Sqoop should make the changes. Short of that I don't see why we should hold Sqoop to a higher standard than is expected of other Apache projects. (that's _my_ opinion ;-) ) Right. Basically the graduation vote by the IPMC is about determining whether the PPMC is capable of conducting itself according to the Apache Way and Apache policies on it's own. I didn't have time to look deeper into Sqoop yet, but all the +1s in this vote suggest that the Sqoop PPMC is ready to take on that responsibility. Along with that responsibility comes the right to make value judgements on topics like this where existing policies aren't clearly spelled out. 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 Personally I think we should let the vote result stand with guidance to the new Sqoop PMC to discuss the matter with the branding team at trademarks@ to seek Apache-wide consensus. I encourage anyone who feels strongly about this (the point being made clearly has some merit) make their case to trademarks@ as it's IMHO not really the task of the Incubator to be forming new policy on this, especially with all the recent talk about scaling down the ambitions of the IPMC. This sounds like a great solution that addresses the concern and does not unduly penalize the Sqoop project. You really should not be seeing this as being penalized. It's not about that. The penalty I reference is for the Sqoop community which will be impacted by incompatible changes you are suggesting. I appreciate your feedback, and request that you keep the discussion relavant to the issue at hand without making references like Cloudera people come out of the woodwork. Please understand that we interact with Apache as individual contributors and committers. Such references undermine our efforts and are honestly insulting to everyone who has spent hours on delivering the product. Thanks, Arvind Prabhakar Alex - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Graduate Sqoop podling from Apache Incubator
Hi all... I don't think that anyone here is trying to underestimate or saying anything bad about Sqoop in general or about Cloudera people in particular. And I agree on the point that this vote was more about evaluating whether the Sqoop community succeeded to adapt to the Apache way of doing open source software or not, and I still believe that they did very good job. So lets not get into this by any how!!! 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!!! Even if there is no explicit rules about that, which is something I really have to look into, again I believe it shouldn't be Apache's problem and if thats the case the relevant documents should be updated and on behalf on others, sorry if I am speaking in name of others here, but I thank the Sqoop team to bring that issue so we know that we need to make things more clear and precise which is also the role of IPMC as part of Apache. IMHO lets be pragmatic and cut into the chase and seek answers and solutions. As I stated before, but I still didn't get any answers, how much of work this needs to get it done ? I will assume two available answers: 1- It can be done before the next board meeting and hence there is no problem at all and the vote still valid. 2- If not, we have two options: 2.1 We still make the vote valid but Mentors they *must* make sure that such issue is resolved as a checklist item of the graduation process steps, which I would prefer 2.2 Vote is cancelled and required changes are discussed by the PPMC preparing for the next vote iteration I would urge all involved to focus on these options or other options if available, the whole purpose here is to make things better, to make Apache way better and more clear which is not only the role of IPMC but it is the role of everyone involved with Apache including Sqoop community itself, which I am sure they are willing to help as much as possible. Sorry for the long e-mail :) Looking forward to your reply! On Wed, Feb 29, 2012 at 12:18 AM, Alex Karasulu akaras...@apache.orgwrote: On Wed, Feb 29, 2012 at 12:59 AM, Arvind Prabhakar arv...@apache.org wrote: On Tue, Feb 28, 2012 at 2:50 PM, Alex Karasulu akaras...@apache.org wrote: On Tue, Feb 28, 2012 at 11:39 PM, Arvind Prabhakar arv...@apache.org wrote: On Tue, Feb 28, 2012 at 1:25 PM, Jukka Zitting jukka.zitt...@gmail.com wrote: Hi, On Tue, Feb 28, 2012 at 9:53 PM, Patrick Hunt ph...@apache.org wrote: On Tue, Feb 28, 2012 at 12:24 PM, Alan D. Cabrera a...@toolazydogs.com wrote: Opps, I didn't see that Arvind concluded the vote. I still stand by my opinion that there are some things that are not solely up to the people that are doing the work. Complete migration to the the org.apache.* package space is one of them. No worries. I respect your opinion and if Apache feels that this is important enough to make explicit then certainly Sqoop should make the changes. Short of that I don't see why we should hold Sqoop to a higher standard than is expected of other Apache projects. (that's _my_ opinion ;-) ) Right. Basically the graduation vote by the IPMC is about determining whether the PPMC is capable of conducting itself according to the Apache Way and Apache policies on it's own. I didn't have time to look deeper into Sqoop yet, but all the +1s in this vote suggest that the Sqoop PPMC is ready to take on that responsibility. Along with that responsibility comes the right to make value judgements on topics like this where existing policies aren't clearly spelled out. 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 Personally I think we should let the vote result stand with guidance to the new Sqoop PMC to discuss the matter with the branding team at trademarks@ to seek Apache-wide consensus. I encourage anyone who feels strongly about this (the point being made clearly has some merit) make their case to trademarks@ as it's IMHO not really the task of the Incubator to be forming new
