On Wed, Jun 1, 2016 at 11:29 AM, Mike Percy <mpe...@apache.org> wrote:
> Yeah the typical thing to use is the subdomain (in this case > org.apache.kudu). > > A few thoughts about package naming: > > 1. While using the apache subdomain for Java package names is encouraged, > and often the most obvious thing to do (i.e. when you're starting from > scratch), it's not required. If we don't do it then a few people will ask > why, and complain about it, and make a big deal out of it accusing the > project of some nefarious intent, but I think ultimately we wouldn't have > to change the package names since it's not a licensing issue. > 2. If it's not too much effort to do it in a backwards-compatible way, it's > probably worth doing for (a) branding and (b) to avoid the distraction of > the above argument. > 3. IMHO it would be preferable to get sign-off on the Apache Kudu name ( > see https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-93 ) before we > spend effort on something that we might have to change again later (imagine > having to maintain 2 sets of facade classes). > Oh yeah that one's a big deal, thanks for bringing this up! So, in your opinion Mike, should we do the change if PODLINGNAMESEARCH-93 is solved within a reasonable time frame before 1.0? > > Mike > > On Tue, May 31, 2016 at 10:57 AM, Dan Burkert <d...@cloudera.com> wrote: > > > I'm an apache noob as well, but I assume it should be "org.apache.kudu", > > since our official apache project name is 'kudu'. I think we settled on > > kududb.io since we couldn't get kudu.io way back when. > > > > - Dan > > > > On Tue, May 31, 2016 at 10:55 AM, Adar Dembo <a...@cloudera.com> wrote: > > > > > I'm +1 to changing it provided Kudu isn't kicked out of Apache. :) As > an > > > Apache newbie, is there any danger of that happening? That is, of the > > > project being declared not fit for TLP? It'd be a shame if we changed > > > package names only to have that happen. > > > > > > Also, shouldn't it be "org.apache.kududb", not "org.apache.kudu"? > > > > > > Separately, how can this be done without breaking compatibility? I > > thought > > > package name changes were, by definition, breaking changes. > > > > > > > > > > > > On Tue, May 31, 2016 at 10:48 AM, Dan Burkert <d...@cloudera.com> > wrote: > > > > > > > I'm +1 to changing the package prior to 1.0. Sooner the better, in > my > > > > opinion. I'm -0 to trying to do it in a backwards compatible way, I > > > don't > > > > think the upside is worth any effort. > > > > > > > > - Dan > > > > > > > > On Tue, May 31, 2016 at 10:45 AM, Jean-Daniel Cryans < > > > jdcry...@apache.org> > > > > wrote: > > > > > > > > > Hey devs, > > > > > > > > > > I'd like to start a discussion around package names. > > > > > > > > > > Right now our packages are prefixed with "org.kududb", a domain > that > > > > AFAIK > > > > > is owned by Cloudera with a plan to transfer it to the ASF. In a > > > perfect > > > > > world they should be named "org.apache.kudu" but it's not a > > > requirement. > > > > > Many projects like Apache Netty and Apache OpenOffice use their own > > > > package > > > > > prefixes. > > > > > > > > > > The main impact of doing this is mostly on the Java side, and it > can > > be > > > > > done without breaking existing but it would be quite a big effort. > > > OTOH, > > > > if > > > > > the community generally agrees that it should be done, then now's a > > > good > > > > > time since we're releasing 1.0 in a little over 2 months. > > > > > > > > > > Thoughts? > > > > > > > > > > J-D > > > > > > > > > > > > > > >
