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 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'm sure you can rectify that. It was stated that Scoop has a branch to do just that in a couple months. > 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". Sorry to disappoint but this is something relavant. You think I want to point this out and get people all riled up? It's just hard to ignore. I'm speaking my mind and expressing my concerns. > 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. > Your hypersensitivity is not my problem. Oh the other hand, that's certainly NOT my intention either. This is an observation, perhaps a suspicion. Nothing meant to jibe. -- Best Regards, -- Alex
