Re: [VOTE] Release Apache SPOT 1.0-incubating

[John D. Ament]

Its very hard to understand this release.  How do I build it?  How do I run
RAT?

John

On Fri, Jul 28, 2017 at 11:50 AM Raymundo Panduro 
wrote:

> Dear IPMC team,
>
> This is the vote for *Apache SPOT 1.0 (incubating) release*. This is
> the first release of SPOT.
>
>
> The PPMC Vote Threads can be found here:
>
>
> https://lists.apache.org/thread.html/69dfe2626c7b803e2a3f26e4d348be8d1941003f0e8166fb8e0e9679@%3Cdev.spot.apache.org%3E
>
>
>
> The PPMC vote results can be found here:
>
>
> https://lists.apache.org/thread.html/a88ef44e0dcda9013781eeca363ad9b3439f6c34a698c6eaa50fb314@%3Cdev.spot.apache.org%3E
>
>
>
> Release Notes (Jira generated):
>  *
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12320637=12340668
> <
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12320637=12340668
> >
> *Git Branch and Tag for the release:
>  *https://github.com/apache/incubator-spot/tree/branch-1.0
> 
> ** https://github.com/apache/incubator-spot/tree/v1.0-incubating
> *
>
> Source code for the release:
>  *
> https://dist.apache.org/repos/dist/dev/incubator/spot/1.0-incubating/apache-spot-1.0-incubating.tar.gz
> <
> https://dist.apache.org/repos/dist/dev/incubator/spot/1.0-incubating/apache-spot-1.0-incubating.tar.gz
> >*
>
> Source release verification:
>
>  PGP Signature:
>  *
> https://dist.apache.org/repos/dist/dev/incubator/spot/1.0-incubating/apache-spot-1.0-incubating.tar.gz.asc
> <
> https://dist.apache.org/repos/dist/dev/incubator/spot/1.0-incubating/apache-spot-1.0-incubating.tar.gz.asc
> >*
>
>
>  MD5/SHA512 Hash:
>
> *
> https://dist.apache.org/repos/dist/dev/incubator/spot/1.0-incubating/apache-spot-1.0-incubating.tar.gz.md5
> <
> https://dist.apache.org/repos/dist/dev/incubator/spot/1.0-incubating/apache-spot-1.0-incubating.tar.gz.md5
> >
>
> https://dist.apache.org/repos/dist/dev/incubator/spot/1.0-incubating/apache-spot-1.0-incubating.tar.gz.sha512
> <
> https://dist.apache.org/repos/dist/dev/incubator/spot/1.0-incubating/apache-spot-1.0-incubating.tar.gz.sha512
> >*
>
> RAT license Verification:*
>
> https://dist.apache.org/repos/dist/dev/incubator/spot/1.0-incubating/apache-spot-1.0-incubating-rat-results.txt
> <
> https://dist.apache.org/repos/dist/dev/incubator/spot/1.0-incubating/apache-spot-1.0-incubating-rat-results.txt
> >*
>
>
>
> *Keys to verify the signature of the release artifact are available
> at: https://dist.apache.org/repos/dist/dev/incubator/spot/KEYS
> *
>
>
> The artifact(s) have been signed with Key :
> *06B82CAEDB5B280349E75D5533CD9431141E946C
> *Download the release candidate and evaluate the necessary items.
>
>
> Please vote accordingly:
>
> *[ ] +1, approve as the official Apache SPOT 1.0-incubating release*
>
> *[ ] -1, do not accept as the official **as the official Apache SPOT
> 1.0-incubating release because...*
>
>
> *The vote will run for at least 72 hours or until necessary number of
> votes are reached.*
>
>
> =
> DISCLAIMER
>
> Apache SPOT (incubating) is an effort undergoing incubation at the
> Apache Software Foundation (ASF), sponsored by the Apache Incubator
> PMC.
>
> Incubation is required of all newly accepted projects until a further
> review indicates that the infrastructure, communications, and decision
> making process have stabilized in a manner consistent with other
> successful ASF projects.
>
> While incubation status is not necessarily a reflection of the
> completeness or stability of the code, it does indicate that
> theproject has yet to be fully endorsed by the ASF.
>
> =
>
>
> *--*
>
> Best Regards!
>
> ---
>
> *Ray Panduro
> *http://spot.apache.org/
>
> ---
>

[VOTE] Apache Pulsar 1.19.0-incubating Release Candidate 0

[Matteo Merli]

This is the first release candidate for Apache Pulsar, version
1.19.0-incubating.

Pulsar is a highly scalable, low latency messaging platform running on
commodity hardware. It provides simple pub-sub semantics over topics,
guaranteed at-least-once delivery of messages, automatic cursor management
for subscribers, and cross-datacenter replication.

Link to the voting thread from the dev@pulsar mailing list:
https://lists.apache.org/thread.html/396ffc9c8fe171bc272691414a39307e0929d40639d9ec631ea3aa15@%3Cdev.pulsar.apache.org%3E

Major changes included in this release are:
 * Added stateless Pulsar proxy
 * Support for non-persistent topics
 * Upgraded RocksDB to comply with ASF policy
 * Instrumentation of ZooKeeper client to expose metrics
 * Fixes for TLS auth in WebSocket proxy

Complete list of changes can be found at:
https://github.com/apache/incubator-pulsar/milestone/8?closed=1

Note that we are voting upon the source (tag), binaries are provided for
convenience.

Source and binary files:
https://dist.apache.org/repos/dist/dev/incubator/pulsar/pulsar-1.19.0-incubating-candidate-0/

Maven staging repo:
https://repository.apache.org/content/repositories/orgapachepulsar-1000/

The tag to be voted upon:
v1.19.0-incubating-candidate-0 (5125279b50f7a3da8c211b698580e1d2f4dd65e2)

Pulsar's KEYS file containing PGP keys we use to sign the release:
https://dist.apache.org/repos/dist/release/incubator/pulsar/KEYS

Please download the the source package, and follow the README to build
and run the Pulsar standalone service.

This vote will stay open for at least 72 hours.

Thanks!
Matteo

--
Matteo Merli

-- 
Matteo Merli

Re: Urgent: Regarding Java package name change to org.apache.*

[P. Taylor Goetz]

When Storm was incubating, our package names started with backtype.* and 
storm.* and it stayed that way through graduation and there was never any 
mention of a need to change. In fact, Storm only moved to org.apache.* with the 
1.0 release in April 2016, about 1.5 years after graduation.

There are implications for Heron since it maintains backtype.* and storm.* 
packages presumably for backward compatibility with older versions of Storm. 
I’m not sure what that means.

I think it would be prudent to better clarify and document the policy around 
this.

-Taylor

> On Aug 3, 2017, at 12:34 PM, John D. Ament  wrote:
> 
> One caveat - if your packages are "com.theoldcompany.someproject" they
> should be renamed to "org.apache.someproject" before graduation.  If you
> have "org.someproject" already or just "someproject" as your package names,
> that's not a naming issue so I don't see that ever blocking graduation.
> 
> John
> 
> On Thu, Aug 3, 2017 at 12:25 PM Alex Harui  wrote:
> 
>> OK, so to summarize a more refined recommendation:
>> 
>> 1) package names with reverse domains MUST be renamed before graduation or
>> have an IPMC approved plan for renaming
>> 2) Projects who expect that their future users outnumber current users are
>> highly encouraged to rename packages
>> 3) Other projects are not required to rename packages and backward
>> compatibility is sufficient reason to not rename packages.
>> 
>> Or should #2 also be a MUST?
>> 
>> -Alex
>> 
>> On 8/3/17, 8:34 AM, "Andy Seaborne"  wrote:
>> 
>>> 
>>> 
>>> On 03/08/17 15:51, Julian Hyde wrote:
 It rarely comes down to the IPMC or the Board dictating how a project
 names its java classes (does anyone recall an instance?), so it’s mainly
 the project’s discretion. In my opinion, where the project is on its
 adoption curve is an important consideration.
>>> 
>>> +1
>>> 
 Most projects that enter the incubator are early on the adoption curve.
 Their future users outnumber their current users. The earlier these
 projects make the change to org.apache, the fewer people they will
 ultimately impact. It seems that gobblin is in this category.
 
 A few projects, such as Flex, are already near the top of their
 adoption curve. The cost/benefit of renaming is not as compelling.
>>> 
>>> Jena was not early on the adoption curve. Long term compatibility has
>>> been, and is, a major element of the project culture.  Importantly,
>>> there are active users who answer questions (here, elsewhere), external
>>> web tutorials, books etc referring to the pre-ASF API.  We have a
>>> responsibility to them as well.
>>> 
>>> "add an API" is more stuff that a small set of volunteer contributors
>>> (Jena has had no paid contributors working on) could not have coped
>>> with.  If a project has the capacity, sure. Not all project will.
>>> 
>>> Set the expectations too high and it is implicitly a filter for a
>>> certain kind of project in size and structure.
>>> 
>>>Andy
>>> 
>>> 
 
 Julian
 
 
> On Aug 3, 2017, at 7:37 AM, Alex Harui 
> wrote:
> 
> From the peanut gallery:
> 
> Does the PPMC get to decide what constitutes a "very good reason" or
> does
> the IPMC and after graduation, the board?
> 
> Flex has not changed its packages in the 5 years at Apache.  We felt
> backward compatibility was and is a "very good reason".  It was way
> more
> important to not require folks to alter their code in order to move to
> the
> Apache versions of Flex.  Also, we are not using Java/Maven so there
> isn't
> really a shading option.
> 
> On the other hand, it seems like it could be confusing for Apache
> projects
> to have packages starting with "com.".  Flex's packages start with
> "mx" or
> "spark" (the component set names).
> 
> Seems like a more refined guidance would be that:
> 1) packages starting with "com" (and maybe
> org.somethingOtherThanApache)
> should be changed as soon as possible/practical
> 2) there is no recommendation for other package prefixes
> 
> My 2 cents,
> -Alex
> 
> On 8/3/17, 5:42 AM, "Shane Curcuru"  > wrote:
> 
>> John D. Ament wrote on 8/2/17 9:13 PM:
>>> On Wed, Aug 2, 2017 at 8:54 PM Roman Shaposhnik
>>> 
>>> wrote:
>>> 
 On Wed, Aug 2, 2017 at 5:40 PM, Abhishek Tiwari 
 wrote:
> Hi all,
> 
> In regards to the recently incubated project - Gobblin, we were
> wondering
> about the policy around renaming Java package names to
> org.apache.* Is
 it a
> mandatory requirement or good to have?
> 
> The reason to ask this is that while we see many 

Re: Urgent: Regarding Java package name change to org.apache.*

[John D. Ament]

Which must's do you see greg?

On Aug 3, 2017 1:09 PM, "Greg Trasuk"  wrote:

> Does this actually need to be policy?  What’s the harm to the foundation
> if a project continues to use a non-Apache package name, assuming that the
> code was donated appropriately?
>
> Certainly, it should be a goal for all projects to use o.a.* package
> names, but if you look around the Foundation’s projects, you’re probably
> going to find lots of non-o.a.* packages.  So it seems like this is another
> case of “Incubator has one (sort-of) policy, while the rest of the
> Foundation does its own thing” cases.  And that being the case, it seems
> like an unreasonable imposition on podlings.
>
> I’d suggest taking out the MUSTs wherever possible, and having mentors
> make “should”, or maybe even “oughta” recommendations.  Apache is already
> seen as unfriendly enough to podlings.
>
> Cheers,
>
> Greg.
> > On Aug 3, 2017, at 12:34 PM, John D. Ament 
> wrote:
> >
> > One caveat - if your packages are "com.theoldcompany.someproject" they
> > should be renamed to "org.apache.someproject" before graduation.  If you
> > have "org.someproject" already or just "someproject" as your package
> names,
> > that's not a naming issue so I don't see that ever blocking graduation.
> >
> > John
> >
> > On Thu, Aug 3, 2017 at 12:25 PM Alex Harui 
> wrote:
> >
> >> OK, so to summarize a more refined recommendation:
> >>
> >> 1) package names with reverse domains MUST be renamed before graduation
> or
> >> have an IPMC approved plan for renaming
> >> 2) Projects who expect that their future users outnumber current users
> are
> >> highly encouraged to rename packages
> >> 3) Other projects are not required to rename packages and backward
> >> compatibility is sufficient reason to not rename packages.
> >>
> >> Or should #2 also be a MUST?
> >>
> >> -Alex
> >>
> >> On 8/3/17, 8:34 AM, "Andy Seaborne"  wrote:
> >>
> >>>
> >>>
> >>> On 03/08/17 15:51, Julian Hyde wrote:
>  It rarely comes down to the IPMC or the Board dictating how a project
>  names its java classes (does anyone recall an instance?), so it’s
> mainly
>  the project’s discretion. In my opinion, where the project is on its
>  adoption curve is an important consideration.
> >>>
> >>> +1
> >>>
>  Most projects that enter the incubator are early on the adoption
> curve.
>  Their future users outnumber their current users. The earlier these
>  projects make the change to org.apache, the fewer people they will
>  ultimately impact. It seems that gobblin is in this category.
> 
>  A few projects, such as Flex, are already near the top of their
>  adoption curve. The cost/benefit of renaming is not as compelling.
> >>>
> >>> Jena was not early on the adoption curve. Long term compatibility has
> >>> been, and is, a major element of the project culture.  Importantly,
> >>> there are active users who answer questions (here, elsewhere), external
> >>> web tutorials, books etc referring to the pre-ASF API.  We have a
> >>> responsibility to them as well.
> >>>
> >>> "add an API" is more stuff that a small set of volunteer contributors
> >>> (Jena has had no paid contributors working on) could not have coped
> >>> with.  If a project has the capacity, sure. Not all project will.
> >>>
> >>> Set the expectations too high and it is implicitly a filter for a
> >>> certain kind of project in size and structure.
> >>>
> >>>Andy
> >>>
> >>>
> 
>  Julian
> 
> 
> > On Aug 3, 2017, at 7:37 AM, Alex Harui 
> > wrote:
> >
> > From the peanut gallery:
> >
> > Does the PPMC get to decide what constitutes a "very good reason" or
> > does
> > the IPMC and after graduation, the board?
> >
> > Flex has not changed its packages in the 5 years at Apache.  We felt
> > backward compatibility was and is a "very good reason".  It was way
> > more
> > important to not require folks to alter their code in order to move
> to
> > the
> > Apache versions of Flex.  Also, we are not using Java/Maven so there
> > isn't
> > really a shading option.
> >
> > On the other hand, it seems like it could be confusing for Apache
> > projects
> > to have packages starting with "com.".  Flex's packages start with
> > "mx" or
> > "spark" (the component set names).
> >
> > Seems like a more refined guidance would be that:
> > 1) packages starting with "com" (and maybe
> > org.somethingOtherThanApache)
> > should be changed as soon as possible/practical
> > 2) there is no recommendation for other package prefixes
> >
> > My 2 cents,
> > -Alex
> >
> > On 8/3/17, 5:42 AM, "Shane Curcuru"  > > wrote:
> >
> >> John D. Ament wrote on 8/2/17 9:13 PM:
> >>> On Wed, 

Re: Urgent: Regarding Java package name change to org.apache.*

[Abhishek Tiwari]

Thanks all for your replies. We decided to bite the bullet and do it since
we are half way already through our work. We will try to address backward
incompatibilities via package shims, and special handling of configs.

On a side note, I think for matters such as these Incubator should document
the official wording once and for all, so that future incubating projects
can plan ahead and have clarity.

Thanks again,
Abhishek

On Thu, Aug 3, 2017 at 10:08 AM, Greg Trasuk  wrote:

> Does this actually need to be policy?  What’s the harm to the foundation
> if a project continues to use a non-Apache package name, assuming that the
> code was donated appropriately?
>
> Certainly, it should be a goal for all projects to use o.a.* package
> names, but if you look around the Foundation’s projects, you’re probably
> going to find lots of non-o.a.* packages.  So it seems like this is another
> case of “Incubator has one (sort-of) policy, while the rest of the
> Foundation does its own thing” cases.  And that being the case, it seems
> like an unreasonable imposition on podlings.
>
> I’d suggest taking out the MUSTs wherever possible, and having mentors
> make “should”, or maybe even “oughta” recommendations.  Apache is already
> seen as unfriendly enough to podlings.
>
> Cheers,
>
> Greg.
> > On Aug 3, 2017, at 12:34 PM, John D. Ament 
> wrote:
> >
> > One caveat - if your packages are "com.theoldcompany.someproject" they
> > should be renamed to "org.apache.someproject" before graduation.  If you
> > have "org.someproject" already or just "someproject" as your package
> names,
> > that's not a naming issue so I don't see that ever blocking graduation.
> >
> > John
> >
> > On Thu, Aug 3, 2017 at 12:25 PM Alex Harui 
> wrote:
> >
> >> OK, so to summarize a more refined recommendation:
> >>
> >> 1) package names with reverse domains MUST be renamed before graduation
> or
> >> have an IPMC approved plan for renaming
> >> 2) Projects who expect that their future users outnumber current users
> are
> >> highly encouraged to rename packages
> >> 3) Other projects are not required to rename packages and backward
> >> compatibility is sufficient reason to not rename packages.
> >>
> >> Or should #2 also be a MUST?
> >>
> >> -Alex
> >>
> >> On 8/3/17, 8:34 AM, "Andy Seaborne"  wrote:
> >>
> >>>
> >>>
> >>> On 03/08/17 15:51, Julian Hyde wrote:
>  It rarely comes down to the IPMC or the Board dictating how a project
>  names its java classes (does anyone recall an instance?), so it’s
> mainly
>  the project’s discretion. In my opinion, where the project is on its
>  adoption curve is an important consideration.
> >>>
> >>> +1
> >>>
>  Most projects that enter the incubator are early on the adoption
> curve.
>  Their future users outnumber their current users. The earlier these
>  projects make the change to org.apache, the fewer people they will
>  ultimately impact. It seems that gobblin is in this category.
> 
>  A few projects, such as Flex, are already near the top of their
>  adoption curve. The cost/benefit of renaming is not as compelling.
> >>>
> >>> Jena was not early on the adoption curve. Long term compatibility has
> >>> been, and is, a major element of the project culture.  Importantly,
> >>> there are active users who answer questions (here, elsewhere), external
> >>> web tutorials, books etc referring to the pre-ASF API.  We have a
> >>> responsibility to them as well.
> >>>
> >>> "add an API" is more stuff that a small set of volunteer contributors
> >>> (Jena has had no paid contributors working on) could not have coped
> >>> with.  If a project has the capacity, sure. Not all project will.
> >>>
> >>> Set the expectations too high and it is implicitly a filter for a
> >>> certain kind of project in size and structure.
> >>>
> >>>Andy
> >>>
> >>>
> 
>  Julian
> 
> 
> > On Aug 3, 2017, at 7:37 AM, Alex Harui 
> > wrote:
> >
> > From the peanut gallery:
> >
> > Does the PPMC get to decide what constitutes a "very good reason" or
> > does
> > the IPMC and after graduation, the board?
> >
> > Flex has not changed its packages in the 5 years at Apache.  We felt
> > backward compatibility was and is a "very good reason".  It was way
> > more
> > important to not require folks to alter their code in order to move
> to
> > the
> > Apache versions of Flex.  Also, we are not using Java/Maven so there
> > isn't
> > really a shading option.
> >
> > On the other hand, it seems like it could be confusing for Apache
> > projects
> > to have packages starting with "com.".  Flex's packages start with
> > "mx" or
> > "spark" (the component set names).
> >
> > Seems like a more refined guidance would be that:
> > 1) packages starting with "com" (and 

Re: Urgent: Regarding Java package name change to org.apache.*

[Greg Trasuk]

Does this actually need to be policy?  What’s the harm to the foundation if a 
project continues to use a non-Apache package name, assuming that the code was 
donated appropriately?  

Certainly, it should be a goal for all projects to use o.a.* package names, but 
if you look around the Foundation’s projects, you’re probably going to find 
lots of non-o.a.* packages.  So it seems like this is another case of 
“Incubator has one (sort-of) policy, while the rest of the Foundation does its 
own thing” cases.  And that being the case, it seems like an unreasonable 
imposition on podlings.

I’d suggest taking out the MUSTs wherever possible, and having mentors make 
“should”, or maybe even “oughta” recommendations.  Apache is already seen as 
unfriendly enough to podlings.

Cheers,

Greg.
> On Aug 3, 2017, at 12:34 PM, John D. Ament  wrote:
> 
> One caveat - if your packages are "com.theoldcompany.someproject" they
> should be renamed to "org.apache.someproject" before graduation.  If you
> have "org.someproject" already or just "someproject" as your package names,
> that's not a naming issue so I don't see that ever blocking graduation.
> 
> John
> 
> On Thu, Aug 3, 2017 at 12:25 PM Alex Harui  wrote:
> 
>> OK, so to summarize a more refined recommendation:
>> 
>> 1) package names with reverse domains MUST be renamed before graduation or
>> have an IPMC approved plan for renaming
>> 2) Projects who expect that their future users outnumber current users are
>> highly encouraged to rename packages
>> 3) Other projects are not required to rename packages and backward
>> compatibility is sufficient reason to not rename packages.
>> 
>> Or should #2 also be a MUST?
>> 
>> -Alex
>> 
>> On 8/3/17, 8:34 AM, "Andy Seaborne"  wrote:
>> 
>>> 
>>> 
>>> On 03/08/17 15:51, Julian Hyde wrote:
 It rarely comes down to the IPMC or the Board dictating how a project
 names its java classes (does anyone recall an instance?), so it’s mainly
 the project’s discretion. In my opinion, where the project is on its
 adoption curve is an important consideration.
>>> 
>>> +1
>>> 
 Most projects that enter the incubator are early on the adoption curve.
 Their future users outnumber their current users. The earlier these
 projects make the change to org.apache, the fewer people they will
 ultimately impact. It seems that gobblin is in this category.
 
 A few projects, such as Flex, are already near the top of their
 adoption curve. The cost/benefit of renaming is not as compelling.
>>> 
>>> Jena was not early on the adoption curve. Long term compatibility has
>>> been, and is, a major element of the project culture.  Importantly,
>>> there are active users who answer questions (here, elsewhere), external
>>> web tutorials, books etc referring to the pre-ASF API.  We have a
>>> responsibility to them as well.
>>> 
>>> "add an API" is more stuff that a small set of volunteer contributors
>>> (Jena has had no paid contributors working on) could not have coped
>>> with.  If a project has the capacity, sure. Not all project will.
>>> 
>>> Set the expectations too high and it is implicitly a filter for a
>>> certain kind of project in size and structure.
>>> 
>>>Andy
>>> 
>>> 
 
 Julian
 
 
> On Aug 3, 2017, at 7:37 AM, Alex Harui 
> wrote:
> 
> From the peanut gallery:
> 
> Does the PPMC get to decide what constitutes a "very good reason" or
> does
> the IPMC and after graduation, the board?
> 
> Flex has not changed its packages in the 5 years at Apache.  We felt
> backward compatibility was and is a "very good reason".  It was way
> more
> important to not require folks to alter their code in order to move to
> the
> Apache versions of Flex.  Also, we are not using Java/Maven so there
> isn't
> really a shading option.
> 
> On the other hand, it seems like it could be confusing for Apache
> projects
> to have packages starting with "com.".  Flex's packages start with
> "mx" or
> "spark" (the component set names).
> 
> Seems like a more refined guidance would be that:
> 1) packages starting with "com" (and maybe
> org.somethingOtherThanApache)
> should be changed as soon as possible/practical
> 2) there is no recommendation for other package prefixes
> 
> My 2 cents,
> -Alex
> 
> On 8/3/17, 5:42 AM, "Shane Curcuru"  > wrote:
> 
>> John D. Ament wrote on 8/2/17 9:13 PM:
>>> On Wed, Aug 2, 2017 at 8:54 PM Roman Shaposhnik
>>> 
>>> wrote:
>>> 
 On Wed, Aug 2, 2017 at 5:40 PM, Abhishek Tiwari 
 wrote:
> Hi all,
> 
> In regards to the recently incubated project - Gobblin, we were
> wondering

Re: Urgent: Regarding Java package name change to org.apache.*

[John D. Ament]

One caveat - if your packages are "com.theoldcompany.someproject" they
should be renamed to "org.apache.someproject" before graduation.  If you
have "org.someproject" already or just "someproject" as your package names,
that's not a naming issue so I don't see that ever blocking graduation.

John

On Thu, Aug 3, 2017 at 12:25 PM Alex Harui  wrote:

> OK, so to summarize a more refined recommendation:
>
> 1) package names with reverse domains MUST be renamed before graduation or
> have an IPMC approved plan for renaming
> 2) Projects who expect that their future users outnumber current users are
> highly encouraged to rename packages
> 3) Other projects are not required to rename packages and backward
> compatibility is sufficient reason to not rename packages.
>
> Or should #2 also be a MUST?
>
> -Alex
>
> On 8/3/17, 8:34 AM, "Andy Seaborne"  wrote:
>
> >
> >
> >On 03/08/17 15:51, Julian Hyde wrote:
> >> It rarely comes down to the IPMC or the Board dictating how a project
> >>names its java classes (does anyone recall an instance?), so it’s mainly
> >>the project’s discretion. In my opinion, where the project is on its
> >>adoption curve is an important consideration.
> >
> >+1
> >
> >> Most projects that enter the incubator are early on the adoption curve.
> >>Their future users outnumber their current users. The earlier these
> >>projects make the change to org.apache, the fewer people they will
> >>ultimately impact. It seems that gobblin is in this category.
> >>
> >> A few projects, such as Flex, are already near the top of their
> >>adoption curve. The cost/benefit of renaming is not as compelling.
> >
> >Jena was not early on the adoption curve. Long term compatibility has
> >been, and is, a major element of the project culture.  Importantly,
> >there are active users who answer questions (here, elsewhere), external
> >web tutorials, books etc referring to the pre-ASF API.  We have a
> >responsibility to them as well.
> >
> >"add an API" is more stuff that a small set of volunteer contributors
> >(Jena has had no paid contributors working on) could not have coped
> >with.  If a project has the capacity, sure. Not all project will.
> >
> >Set the expectations too high and it is implicitly a filter for a
> >certain kind of project in size and structure.
> >
> > Andy
> >
> >
> >>
> >> Julian
> >>
> >>
> >>> On Aug 3, 2017, at 7:37 AM, Alex Harui 
> >>>wrote:
> >>>
> >>>  From the peanut gallery:
> >>>
> >>> Does the PPMC get to decide what constitutes a "very good reason" or
> >>>does
> >>> the IPMC and after graduation, the board?
> >>>
> >>> Flex has not changed its packages in the 5 years at Apache.  We felt
> >>> backward compatibility was and is a "very good reason".  It was way
> >>>more
> >>> important to not require folks to alter their code in order to move to
> >>>the
> >>> Apache versions of Flex.  Also, we are not using Java/Maven so there
> >>>isn't
> >>> really a shading option.
> >>>
> >>> On the other hand, it seems like it could be confusing for Apache
> >>>projects
> >>> to have packages starting with "com.".  Flex's packages start with
> >>>"mx" or
> >>> "spark" (the component set names).
> >>>
> >>> Seems like a more refined guidance would be that:
> >>> 1) packages starting with "com" (and maybe
> >>>org.somethingOtherThanApache)
> >>> should be changed as soon as possible/practical
> >>> 2) there is no recommendation for other package prefixes
> >>>
> >>> My 2 cents,
> >>> -Alex
> >>>
> >>> On 8/3/17, 5:42 AM, "Shane Curcuru"  >>>> wrote:
> >>>
>  John D. Ament wrote on 8/2/17 9:13 PM:
> > On Wed, Aug 2, 2017 at 8:54 PM Roman Shaposhnik
> >
> > wrote:
> >
> >> On Wed, Aug 2, 2017 at 5:40 PM, Abhishek Tiwari 
> >> wrote:
> >>> Hi all,
> >>>
> >>> In regards to the recently incubated project - Gobblin, we were
> >>> wondering
> >>> about the policy around renaming Java package names to
> >>>org.apache.* Is
> >> it a
> >>> mandatory requirement or good to have?
> >>>
> >>> The reason to ask this is that while we see many projects have
> >>> migrated
> >> to
> >>> use org.apache.* package name for their Java source files, the
> >>>Kafka
> >>> project uses kafka.* for Scala sources and org.apache.kafka.* for
> >>>Java
> >>> sources.
> >>>
> >>> Please let us know as soon as possible, because we are in process
> >>>of
> >>> renaming the  packages but if not mandatory we would want to keep
> >> gobblin.*
> >>> package name and avoid the cost of downstream migrations and
> >>>backwards
> >>> incompatibility.
> >>
> >> You don't have to do it right away, but it is a requirement unless
> >>you
> >> have a really,
> >> really, really good reason of why you can't do that.
> >>
> 

Re: Urgent: Regarding Java package name change to org.apache.*

[Wade Chandler]

> 
> 
> On Aug 3, 2017, at 12:25, Alex Harui  wrote:
> 
> OK, so to summarize a more refined recommendation:
> 
> 1) package names with reverse domains MUST be renamed before graduation or
> have an IPMC approved plan for renaming

NetBeans uses org.netbeans, and the domain is also being donated to Apache. It 
is not just an IDE, but is also a rich client platform, like Eclipse, so I 
don’t think just a reverse domain name should be justification for MUST. Surely 
part of the decision takes into consideration the life of the project along 
with what that reverse domain is.

> 2) Projects who expect that their future users outnumber current users are
> highly encouraged to rename packages
> 3) Other projects are not required to rename packages and backward
> compatibility is sufficient reason to not rename packages.
> 
> Or should #2 also be a MUST?

Thanks,

Wade

Re: Urgent: Regarding Java package name change to org.apache.*

[Alex Harui]

OK, so to summarize a more refined recommendation:

1) package names with reverse domains MUST be renamed before graduation or
have an IPMC approved plan for renaming
2) Projects who expect that their future users outnumber current users are
highly encouraged to rename packages
3) Other projects are not required to rename packages and backward
compatibility is sufficient reason to not rename packages.

Or should #2 also be a MUST?

-Alex

On 8/3/17, 8:34 AM, "Andy Seaborne"  wrote:

>
>
>On 03/08/17 15:51, Julian Hyde wrote:
>> It rarely comes down to the IPMC or the Board dictating how a project
>>names its java classes (does anyone recall an instance?), so it’s mainly
>>the project’s discretion. In my opinion, where the project is on its
>>adoption curve is an important consideration.
>
>+1
>
>> Most projects that enter the incubator are early on the adoption curve.
>>Their future users outnumber their current users. The earlier these
>>projects make the change to org.apache, the fewer people they will
>>ultimately impact. It seems that gobblin is in this category.
>> 
>> A few projects, such as Flex, are already near the top of their
>>adoption curve. The cost/benefit of renaming is not as compelling.
>
>Jena was not early on the adoption curve. Long term compatibility has
>been, and is, a major element of the project culture.  Importantly,
>there are active users who answer questions (here, elsewhere), external
>web tutorials, books etc referring to the pre-ASF API.  We have a
>responsibility to them as well.
>
>"add an API" is more stuff that a small set of volunteer contributors
>(Jena has had no paid contributors working on) could not have coped
>with.  If a project has the capacity, sure. Not all project will.
>
>Set the expectations too high and it is implicitly a filter for a
>certain kind of project in size and structure.
>
> Andy
>
>
>> 
>> Julian
>> 
>> 
>>> On Aug 3, 2017, at 7:37 AM, Alex Harui 
>>>wrote:
>>>
>>>  From the peanut gallery:
>>>
>>> Does the PPMC get to decide what constitutes a "very good reason" or
>>>does
>>> the IPMC and after graduation, the board?
>>>
>>> Flex has not changed its packages in the 5 years at Apache.  We felt
>>> backward compatibility was and is a "very good reason".  It was way
>>>more
>>> important to not require folks to alter their code in order to move to
>>>the
>>> Apache versions of Flex.  Also, we are not using Java/Maven so there
>>>isn't
>>> really a shading option.
>>>
>>> On the other hand, it seems like it could be confusing for Apache
>>>projects
>>> to have packages starting with "com.".  Flex's packages start with
>>>"mx" or
>>> "spark" (the component set names).
>>>
>>> Seems like a more refined guidance would be that:
>>> 1) packages starting with "com" (and maybe
>>>org.somethingOtherThanApache)
>>> should be changed as soon as possible/practical
>>> 2) there is no recommendation for other package prefixes
>>>
>>> My 2 cents,
>>> -Alex
>>>
>>> On 8/3/17, 5:42 AM, "Shane Curcuru" >>> wrote:
>>>
 John D. Ament wrote on 8/2/17 9:13 PM:
> On Wed, Aug 2, 2017 at 8:54 PM Roman Shaposhnik
>
> wrote:
>
>> On Wed, Aug 2, 2017 at 5:40 PM, Abhishek Tiwari 
>> wrote:
>>> Hi all,
>>>
>>> In regards to the recently incubated project - Gobblin, we were
>>> wondering
>>> about the policy around renaming Java package names to
>>>org.apache.* Is
>> it a
>>> mandatory requirement or good to have?
>>>
>>> The reason to ask this is that while we see many projects have
>>> migrated
>> to
>>> use org.apache.* package name for their Java source files, the
>>>Kafka
>>> project uses kafka.* for Scala sources and org.apache.kafka.* for
>>>Java
>>> sources.
>>>
>>> Please let us know as soon as possible, because we are in process
>>>of
>>> renaming the  packages but if not mandatory we would want to keep
>> gobblin.*
>>> package name and avoid the cost of downstream migrations and
>>>backwards
>>> incompatibility.
>>
>> You don't have to do it right away, but it is a requirement unless
>>you
>> have a really,
>> really, really good reason of why you can't do that.
>>
>>
> I'm not aware of any requirement around Java package naming.  IN
>fact,
> last
> time it came up it was clear that its a best practice only, and
>doesn't
> have any actual naming requirements.

 John: Do you have a link to that discussion?  I'm of the mind that
it's
 an expected best practice, unless you have a really, really good
reason
 otherwise.

 Abhishek: Can you describe in more detail what these packages do in
the
 context of your software product?

 In general, yes, I'd echo Roman's point strongly for the primary
 external 

Re: Urgent: Regarding Java package name change to org.apache.*

[Andy Seaborne]

On 03/08/17 15:51, Julian Hyde wrote:

It rarely comes down to the IPMC or the Board dictating how a project names its 
java classes (does anyone recall an instance?), so it’s mainly the project’s 
discretion. In my opinion, where the project is on its adoption curve is an 
important consideration.


+1


Most projects that enter the incubator are early on the adoption curve. Their 
future users outnumber their current users. The earlier these projects make the 
change to org.apache, the fewer people they will ultimately impact. It seems 
that gobblin is in this category.

A few projects, such as Flex, are already near the top of their adoption curve. 
The cost/benefit of renaming is not as compelling.


Jena was not early on the adoption curve. Long term compatibility has 
been, and is, a major element of the project culture.  Importantly, 
there are active users who answer questions (here, elsewhere), external 
web tutorials, books etc referring to the pre-ASF API.  We have a 
responsibility to them as well.


"add an API" is more stuff that a small set of volunteer contributors 
(Jena has had no paid contributors working on) could not have coped 
with.  If a project has the capacity, sure. Not all project will.


Set the expectations too high and it is implicitly a filter for a 
certain kind of project in size and structure.


Andy




Julian



On Aug 3, 2017, at 7:37 AM, Alex Harui  wrote:

 From the peanut gallery:

Does the PPMC get to decide what constitutes a "very good reason" or does
the IPMC and after graduation, the board?

Flex has not changed its packages in the 5 years at Apache.  We felt
backward compatibility was and is a "very good reason".  It was way more
important to not require folks to alter their code in order to move to the
Apache versions of Flex.  Also, we are not using Java/Maven so there isn't
really a shading option.

On the other hand, it seems like it could be confusing for Apache projects
to have packages starting with "com.".  Flex's packages start with "mx" or
"spark" (the component set names).

Seems like a more refined guidance would be that:
1) packages starting with "com" (and maybe org.somethingOtherThanApache)
should be changed as soon as possible/practical
2) there is no recommendation for other package prefixes

My 2 cents,
-Alex

On 8/3/17, 5:42 AM, "Shane Curcuru" > wrote:


John D. Ament wrote on 8/2/17 9:13 PM:

On Wed, Aug 2, 2017 at 8:54 PM Roman Shaposhnik 
wrote:


On Wed, Aug 2, 2017 at 5:40 PM, Abhishek Tiwari 
wrote:

Hi all,

In regards to the recently incubated project - Gobblin, we were
wondering
about the policy around renaming Java package names to org.apache.* Is

it a

mandatory requirement or good to have?

The reason to ask this is that while we see many projects have
migrated

to

use org.apache.* package name for their Java source files, the Kafka
project uses kafka.* for Scala sources and org.apache.kafka.* for Java
sources.

Please let us know as soon as possible, because we are in process of
renaming the  packages but if not mandatory we would want to keep

gobblin.*

package name and avoid the cost of downstream migrations and backwards
incompatibility.


You don't have to do it right away, but it is a requirement unless you
have a really,
really, really good reason of why you can't do that.



I'm not aware of any requirement around Java package naming.  IN fact,
last
time it came up it was clear that its a best practice only, and doesn't
have any actual naming requirements.


John: Do you have a link to that discussion?  I'm of the mind that it's
an expected best practice, unless you have a really, really good reason
otherwise.

Abhishek: Can you describe in more detail what these packages do in the
context of your software product?

In general, yes, I'd echo Roman's point strongly for the primary
external API that most users would call:


Or to put it a different way: during your eventual graduation this
question will be
asked and you better have a really, really good explanation if you're
still using
something other than o.a.


That is, supporting packages, or things that are standards, or things
that are specific plugins that integrate with external code - those I
could understand staying with a non-a.o package name for compatibility
or other reasons.

But the main program that users run in the JVM, or the primary Gobblin
classes that users integrating the code into their application?  That
should be in an org.apache.gobblin.* package.

Simple "backwards compatibility for users" as an argument is only
suitable if you're deprecating and have a plan to switch in the
reasonably-near future after graduation.  Not for the long term.

Thanks for raising the question early!



Thanks,
Roman.


--

- Shane

https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.apach 

Re: Code contribution to Apache MXNet with a BSD 3 clause

[Dominic Divakaruni]

+general@incubator

On Thu, Aug 3, 2017 at 8:22 AM Dominic Divakaruni <
dominic.divakar...@gmail.com> wrote:

> Legal-discuss@ to Bcc
>
> Thanks, John. The code will be part of Apache MXNet and our team will
> commit to maintaining this. I will reach out to Apple, but I am not
> optimistic they will make any changes.
>
> Sounds like we are ok either way. So thanks!
>
> Dom
>
> On Thu, Aug 3, 2017 at 3:26 AM, John D. Ament 
> wrote:
>
>> Ideally they would provide the contribution under the Apache License, v2.
>> Are they maintaining these files going forward, or are they ending up in
>> the Apache MXNet repository?  Would they be agreeable to providing an ICLA
>> or an SGA?
>>
>> Either way, this falls under the Incubator's IP Clearance policy.  Please
>> continue this discussion on general@incubator.
>>
>> John
>>
>> On Thu, Aug 3, 2017 at 4:10 AM Dominic Divakaruni <
>> dominic.divakar...@gmail.com> wrote:
>>
>> > Hi All,
>> > We've worked with our friends in Cupertino to build a tool that converts
>> > MXNet models to their CoreML format so you can build iOS and MacOS apps
>> > with it in XCode.
>> >
>> > Apple had done the initial work on this tool and sent us their code to
>> > finish and maintain going forward. We are ready to make it available for
>> > use and would like to make a PR to commit it to Apache MXNet in the next
>> > day.
>> >
>> > Attached is their license file that goes along with the code. Please let
>> > me know if there are any issues or concerns with this.
>> >
>> >
>> > Thanks!
>> > --
>> >
>> > Dominic Divakaruni
>> > 206.475.9200 <(206)%20475-9200> Cell
>> >
>> > -
>> > To unsubscribe, e-mail: legal-discuss-unsubscr...@apache.org
>> > For additional commands, e-mail: legal-discuss-h...@apache.org
>>
>
>
>
> --
>
>
> Dominic Divakaruni
> 206.475.9200 Cell
>
-- 


Dominic Divakaruni
206.475.9200 Cell

Re: Code contribution to Apache MXNet with a BSD 3 clause

[John D. Ament]

On Thu, Aug 3, 2017 at 11:26 AM Dominic Divakaruni <
dominic.divakar...@gmail.com> wrote:

> +general@incubator
>
> On Thu, Aug 3, 2017 at 8:22 AM Dominic Divakaruni <
> dominic.divakar...@gmail.com> wrote:
>
>> Legal-discuss@ to Bcc
>>
>> Thanks, John. The code will be part of Apache MXNet and our team will
>> commit to maintaining this. I will reach out to Apple, but I am not
>> optimistic they will make any changes.
>>
>> Sounds like we are ok either way. So thanks!
>>
>
We're OK to start an IP Clearance.  We're not OK with you just dumping it
into your repos yet.


>
>> Dom
>>
>> On Thu, Aug 3, 2017 at 3:26 AM, John D. Ament 
>> wrote:
>>
>>> Ideally they would provide the contribution under the Apache License, v2.
>>> Are they maintaining these files going forward, or are they ending up in
>>> the Apache MXNet repository?  Would they be agreeable to providing an
>>> ICLA
>>> or an SGA?
>>>
>>> Either way, this falls under the Incubator's IP Clearance policy.  Please
>>> continue this discussion on general@incubator.
>>>
>>> John
>>>
>>> On Thu, Aug 3, 2017 at 4:10 AM Dominic Divakaruni <
>>> dominic.divakar...@gmail.com> wrote:
>>>
>>> > Hi All,
>>> > We've worked with our friends in Cupertino to build a tool that
>>> converts
>>> > MXNet models to their CoreML format so you can build iOS and MacOS apps
>>> > with it in XCode.
>>> >
>>> > Apple had done the initial work on this tool and sent us their code to
>>> > finish and maintain going forward. We are ready to make it available
>>> for
>>> > use and would like to make a PR to commit it to Apache MXNet in the
>>> next
>>> > day.
>>> >
>>> > Attached is their license file that goes along with the code. Please
>>> let
>>> > me know if there are any issues or concerns with this.
>>> >
>>> >
>>> > Thanks!
>>> > --
>>> >
>>> > Dominic Divakaruni
>>> > 206.475.9200 <(206)%20475-9200> Cell
>>> >
>>> > -
>>> > To unsubscribe, e-mail: legal-discuss-unsubscr...@apache.org
>>> > For additional commands, e-mail: legal-discuss-h...@apache.org
>>>
>>
>>
>>
>> --
>>
>>
>> Dominic Divakaruni
>> 206.475.9200 <(206)%20475-9200> Cell
>>
> --
>
>
> Dominic Divakaruni
> 206.475.9200 <(206)%20475-9200> Cell
>

Re: Urgent: Regarding Java package name change to org.apache.*

[John D. Ament]

On Thu, Aug 3, 2017 at 8:42 AM Shane Curcuru  wrote:

> John D. Ament wrote on 8/2/17 9:13 PM:
> > On Wed, Aug 2, 2017 at 8:54 PM Roman Shaposhnik 
> > wrote:
> >
> >> On Wed, Aug 2, 2017 at 5:40 PM, Abhishek Tiwari 
> wrote:
> >>> Hi all,
> >>>
> >>> In regards to the recently incubated project - Gobblin, we were
> wondering
> >>> about the policy around renaming Java package names to org.apache.* Is
> >> it a
> >>> mandatory requirement or good to have?
> >>>
> >>> The reason to ask this is that while we see many projects have migrated
> >> to
> >>> use org.apache.* package name for their Java source files, the Kafka
> >>> project uses kafka.* for Scala sources and org.apache.kafka.* for Java
> >>> sources.
> >>>
> >>> Please let us know as soon as possible, because we are in process of
> >>> renaming the  packages but if not mandatory we would want to keep
> >> gobblin.*
> >>> package name and avoid the cost of downstream migrations and backwards
> >>> incompatibility.
> >>
> >> You don't have to do it right away, but it is a requirement unless you
> >> have a really,
> >> really, really good reason of why you can't do that.
> >>
> >>
> > I'm not aware of any requirement around Java package naming.  IN fact,
> last
> > time it came up it was clear that its a best practice only, and doesn't
> > have any actual naming requirements.
>
> John: Do you have a link to that discussion?  I'm of the mind that it's
> an expected best practice, unless you have a really, really good reason
> otherwise.
>

Sure, its here [1].  There are two TLPs that I know have this issue -
Polygene and Groovy.  There's a few others as well, I'm sure.

[1]:
https://lists.apache.org/thread.html/15550f5bf622ae3070b558505c8a0fd0ce3b23df3012d57de8b6d9f3@%3Cgeneral.incubator.apache.org%3E


>
> Abhishek: Can you describe in more detail what these packages do in the
> context of your software product?
>
> In general, yes, I'd echo Roman's point strongly for the primary
> external API that most users would call:
>
> >> Or to put it a different way: during your eventual graduation this
> >> question will be
> >> asked and you better have a really, really good explanation if you're
> >> still using
> >> something other than o.a.
>
> That is, supporting packages, or things that are standards, or things
> that are specific plugins that integrate with external code - those I
> could understand staying with a non-a.o package name for compatibility
> or other reasons.
>
> But the main program that users run in the JVM, or the primary Gobblin
> classes that users integrating the code into their application?  That
> should be in an org.apache.gobblin.* package.
>
> Simple "backwards compatibility for users" as an argument is only
> suitable if you're deprecating and have a plan to switch in the
> reasonably-near future after graduation.  Not for the long term.
>
> Thanks for raising the question early!
>
> >>
> >> Thanks,
> >> Roman.
>
> --
>
> - Shane
>   https://www.apache.org/foundation/marks/resources
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: Urgent: Regarding Java package name change to org.apache.*

[Shane Curcuru]

Alex Harui wrote on 8/3/17 10:37 AM:
> From the peanut gallery:
> 
> Does the PPMC get to decide what constitutes a "very good reason" or does
> the IPMC and after graduation, the board?
> 
> Flex has not changed its packages in the 5 years at Apache.  We felt
> backward compatibility was and is a "very good reason".  It was way more
> important to not require folks to alter their code in order to move to the
> Apache versions of Flex.  Also, we are not using Java/Maven so there isn't
> really a shading option.
> 
> On the other hand, it seems like it could be confusing for Apache projects
> to have packages starting with "com.".  Flex's packages start with "mx" or
> "spark" (the component set names).

This is the only significant point for me.  I would be -1 on TLPs
continuing to ship a com.company.* package for the primary code for the
project

*If* there is a long history of use and expectations of compatibility,
and *if* the package names are not reverse-domains but are just
component names, then that's fine to keep the package names.

> 
> Seems like a more refined guidance would be that:
> 1) packages starting with "com" (and maybe org.somethingOtherThanApache)
> should be changed as soon as possible/practical

Any packages that use the reversed domain name prefix.

> 2) there is no recommendation for other package prefixes

It's still a best practice to use org.apache.*, unless the package
prefix is long-used and is based on component or functionality names.


-- 

- Shane
  https://www.apache.org/foundation/marks/resources

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

Re: Urgent: Regarding Java package name change to org.apache.*

[Julian Hyde]

It rarely comes down to the IPMC or the Board dictating how a project names its 
java classes (does anyone recall an instance?), so it’s mainly the project’s 
discretion. In my opinion, where the project is on its adoption curve is an 
important consideration.

Most projects that enter the incubator are early on the adoption curve. Their 
future users outnumber their current users. The earlier these projects make the 
change to org.apache, the fewer people they will ultimately impact. It seems 
that gobblin is in this category.

A few projects, such as Flex, are already near the top of their adoption curve. 
The cost/benefit of renaming is not as compelling.

Julian 


> On Aug 3, 2017, at 7:37 AM, Alex Harui  wrote:
> 
> From the peanut gallery:
> 
> Does the PPMC get to decide what constitutes a "very good reason" or does
> the IPMC and after graduation, the board?
> 
> Flex has not changed its packages in the 5 years at Apache.  We felt
> backward compatibility was and is a "very good reason".  It was way more
> important to not require folks to alter their code in order to move to the
> Apache versions of Flex.  Also, we are not using Java/Maven so there isn't
> really a shading option.
> 
> On the other hand, it seems like it could be confusing for Apache projects
> to have packages starting with "com.".  Flex's packages start with "mx" or
> "spark" (the component set names).
> 
> Seems like a more refined guidance would be that:
> 1) packages starting with "com" (and maybe org.somethingOtherThanApache)
> should be changed as soon as possible/practical
> 2) there is no recommendation for other package prefixes
> 
> My 2 cents,
> -Alex
> 
> On 8/3/17, 5:42 AM, "Shane Curcuru"  > wrote:
> 
>> John D. Ament wrote on 8/2/17 9:13 PM:
>>> On Wed, Aug 2, 2017 at 8:54 PM Roman Shaposhnik 
>>> wrote:
>>> 
 On Wed, Aug 2, 2017 at 5:40 PM, Abhishek Tiwari 
 wrote:
> Hi all,
> 
> In regards to the recently incubated project - Gobblin, we were
> wondering
> about the policy around renaming Java package names to org.apache.* Is
 it a
> mandatory requirement or good to have?
> 
> The reason to ask this is that while we see many projects have
> migrated
 to
> use org.apache.* package name for their Java source files, the Kafka
> project uses kafka.* for Scala sources and org.apache.kafka.* for Java
> sources.
> 
> Please let us know as soon as possible, because we are in process of
> renaming the  packages but if not mandatory we would want to keep
 gobblin.*
> package name and avoid the cost of downstream migrations and backwards
> incompatibility.
 
 You don't have to do it right away, but it is a requirement unless you
 have a really,
 really, really good reason of why you can't do that.
 
 
>>> I'm not aware of any requirement around Java package naming.  IN fact,
>>> last
>>> time it came up it was clear that its a best practice only, and doesn't
>>> have any actual naming requirements.
>> 
>> John: Do you have a link to that discussion?  I'm of the mind that it's
>> an expected best practice, unless you have a really, really good reason
>> otherwise.
>> 
>> Abhishek: Can you describe in more detail what these packages do in the
>> context of your software product?
>> 
>> In general, yes, I'd echo Roman's point strongly for the primary
>> external API that most users would call:
>> 
 Or to put it a different way: during your eventual graduation this
 question will be
 asked and you better have a really, really good explanation if you're
 still using
 something other than o.a.
>> 
>> That is, supporting packages, or things that are standards, or things
>> that are specific plugins that integrate with external code - those I
>> could understand staying with a non-a.o package name for compatibility
>> or other reasons.
>> 
>> But the main program that users run in the JVM, or the primary Gobblin
>> classes that users integrating the code into their application?  That
>> should be in an org.apache.gobblin.* package.
>> 
>> Simple "backwards compatibility for users" as an argument is only
>> suitable if you're deprecating and have a plan to switch in the
>> reasonably-near future after graduation.  Not for the long term.
>> 
>> Thanks for raising the question early!
>> 
 
 Thanks,
 Roman.
>> 
>> -- 
>> 
>> - Shane
>> 
>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.apach 
>> 
>> e.org 
>> %2Ffoundation%2Fmarks%2Fresources=02%7C01%7C%7Cef18c5e74b0141378
>> 79a08d4da6d0e5c%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6363736093056
>> 90124=OyrEoidSvoONvFJksGYjhhz%2FatAd4b%2FyjmHcfoGeI%2B0%3D=
>> 0
>> 
>> 

Re: Urgent: Regarding Java package name change to org.apache.*

[Alex Harui]

From the peanut gallery:

Does the PPMC get to decide what constitutes a "very good reason" or does
the IPMC and after graduation, the board?

Flex has not changed its packages in the 5 years at Apache.  We felt
backward compatibility was and is a "very good reason".  It was way more
important to not require folks to alter their code in order to move to the
Apache versions of Flex.  Also, we are not using Java/Maven so there isn't
really a shading option.

On the other hand, it seems like it could be confusing for Apache projects
to have packages starting with "com.".  Flex's packages start with "mx" or
"spark" (the component set names).

Seems like a more refined guidance would be that:
1) packages starting with "com" (and maybe org.somethingOtherThanApache)
should be changed as soon as possible/practical
2) there is no recommendation for other package prefixes

My 2 cents,
-Alex

On 8/3/17, 5:42 AM, "Shane Curcuru"  wrote:

>John D. Ament wrote on 8/2/17 9:13 PM:
>> On Wed, Aug 2, 2017 at 8:54 PM Roman Shaposhnik 
>> wrote:
>> 
>>> On Wed, Aug 2, 2017 at 5:40 PM, Abhishek Tiwari 
>>>wrote:
 Hi all,

 In regards to the recently incubated project - Gobblin, we were
wondering
 about the policy around renaming Java package names to org.apache.* Is
>>> it a
 mandatory requirement or good to have?

 The reason to ask this is that while we see many projects have
migrated
>>> to
 use org.apache.* package name for their Java source files, the Kafka
 project uses kafka.* for Scala sources and org.apache.kafka.* for Java
 sources.

 Please let us know as soon as possible, because we are in process of
 renaming the  packages but if not mandatory we would want to keep
>>> gobblin.*
 package name and avoid the cost of downstream migrations and backwards
 incompatibility.
>>>
>>> You don't have to do it right away, but it is a requirement unless you
>>> have a really,
>>> really, really good reason of why you can't do that.
>>>
>>>
>> I'm not aware of any requirement around Java package naming.  IN fact,
>>last
>> time it came up it was clear that its a best practice only, and doesn't
>> have any actual naming requirements.
>
>John: Do you have a link to that discussion?  I'm of the mind that it's
>an expected best practice, unless you have a really, really good reason
>otherwise.
>
>Abhishek: Can you describe in more detail what these packages do in the
>context of your software product?
>
>In general, yes, I'd echo Roman's point strongly for the primary
>external API that most users would call:
>
>>> Or to put it a different way: during your eventual graduation this
>>> question will be
>>> asked and you better have a really, really good explanation if you're
>>> still using
>>> something other than o.a.
>
>That is, supporting packages, or things that are standards, or things
>that are specific plugins that integrate with external code - those I
>could understand staying with a non-a.o package name for compatibility
>or other reasons.
>
>But the main program that users run in the JVM, or the primary Gobblin
>classes that users integrating the code into their application?  That
>should be in an org.apache.gobblin.* package.
>
>Simple "backwards compatibility for users" as an argument is only
>suitable if you're deprecating and have a plan to switch in the
>reasonably-near future after graduation.  Not for the long term.
>
>Thanks for raising the question early!
>
>>>
>>> Thanks,
>>> Roman.
>
>-- 
>
>- Shane
>  
>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.apach
>e.org%2Ffoundation%2Fmarks%2Fresources=02%7C01%7C%7Cef18c5e74b0141378
>79a08d4da6d0e5c%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6363736093056
>90124=OyrEoidSvoONvFJksGYjhhz%2FatAd4b%2FyjmHcfoGeI%2B0%3D=
>0
>
>-
>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

Ping for Apache SPOT 1.0 (Incubating) Voting Thread

[Raymundo Panduro]

Hi IPMC members...

Just Wondering if you saw the voting email of Apache SPOT 1.0 (Incubating)
Release on this thread:


https://lists.apache.org/thread.html/32d7c93fe66cc256ed12a5b8f91b57b1d0d659b9012c8f4f13c11191@%3Cgeneral.incubator.apache.org%3E

Any comments or feedback regarding the release will be appreciate.



Thank you.


Best Regards!

---

Ray Panduro
http://spot.apache.org/

--

Re: Urgent: Regarding Java package name change to org.apache.*

[Shane Curcuru]

John D. Ament wrote on 8/2/17 9:13 PM:
> On Wed, Aug 2, 2017 at 8:54 PM Roman Shaposhnik 
> wrote:
> 
>> On Wed, Aug 2, 2017 at 5:40 PM, Abhishek Tiwari  wrote:
>>> Hi all,
>>>
>>> In regards to the recently incubated project - Gobblin, we were wondering
>>> about the policy around renaming Java package names to org.apache.* Is
>> it a
>>> mandatory requirement or good to have?
>>>
>>> The reason to ask this is that while we see many projects have migrated
>> to
>>> use org.apache.* package name for their Java source files, the Kafka
>>> project uses kafka.* for Scala sources and org.apache.kafka.* for Java
>>> sources.
>>>
>>> Please let us know as soon as possible, because we are in process of
>>> renaming the  packages but if not mandatory we would want to keep
>> gobblin.*
>>> package name and avoid the cost of downstream migrations and backwards
>>> incompatibility.
>>
>> You don't have to do it right away, but it is a requirement unless you
>> have a really,
>> really, really good reason of why you can't do that.
>>
>>
> I'm not aware of any requirement around Java package naming.  IN fact, last
> time it came up it was clear that its a best practice only, and doesn't
> have any actual naming requirements.

John: Do you have a link to that discussion?  I'm of the mind that it's
an expected best practice, unless you have a really, really good reason
otherwise.

Abhishek: Can you describe in more detail what these packages do in the
context of your software product?

In general, yes, I'd echo Roman's point strongly for the primary
external API that most users would call:

>> Or to put it a different way: during your eventual graduation this
>> question will be
>> asked and you better have a really, really good explanation if you're
>> still using
>> something other than o.a.

That is, supporting packages, or things that are standards, or things
that are specific plugins that integrate with external code - those I
could understand staying with a non-a.o package name for compatibility
or other reasons.

But the main program that users run in the JVM, or the primary Gobblin
classes that users integrating the code into their application?  That
should be in an org.apache.gobblin.* package.

Simple "backwards compatibility for users" as an argument is only
suitable if you're deprecating and have a plan to switch in the
reasonably-near future after graduation.  Not for the long term.

Thanks for raising the question early!

>>
>> Thanks,
>> Roman.

-- 

- Shane
  https://www.apache.org/foundation/marks/resources

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

Re: [IP CLEARANCE] Arrow Plasma Object Store

[John D. Ament]

On Wed, Aug 2, 2017 at 5:50 PM Wes McKinney  wrote:

> We have the git history from the project of origin; the entire Ray
> project (Apache 2.0) git history is commingled with the Plasma Object
> Store code, so it would be possible with some effort to extract only
> the commits relating to the contributed work for examination
>
> * https://github.com/ray-project/ray/tree/master/src/plasma
> * https://github.com/ray-project/ray/tree/master/python/ray/plasma
>
>
Ok, got it.  You're basically receiving a sliver of their overall repo, and
the linked content is just that cutout piece.  Makes sense, thanks.


> The commit from which the code was extracted for contribution to
> Apache Arrow is
>
>
> https://github.com/ray-project/ray/commit/b94b4a35e04d8d2c0af4420518a4e9a94c1c9b9f
>
> Thanks,
> Wes
>
> On Wed, Aug 2, 2017 at 5:40 PM, Julian Hyde  wrote:
> > My mistake. All 8 contributors are present and correct in the ICLAs file.
> >
> > Julian
> >
> >
> >> On Aug 2, 2017, at 1:37 PM, Julian Hyde  wrote:
> >>
> >> The plan is for all 8 named contributors to submit ICLAs.
> >>
> >> I understand from Wes that all have submitted ICLAs, and the secretary
> has acknowledged. I see all except Ujval Mista and Mehrdad Nicknami have
> been added to iclas.txt in the last week or so. Let me check on the last
> two and get back to you.
> >>
> >> Julian
> >>
> >>
> >>> On Aug 2, 2017, at 12:25 PM, John D. Ament 
> wrote:
> >>>
> >>> Julian,
> >>>
> >>> How are we verifying distribution rights?  The git history doesn't
> match
> >>> the documented history.  Are these individuals signing ICLAs?
> >>>
> >>> John
> >>>
> >>> On Wed, Aug 2, 2017 at 3:12 PM Julian Hyde  wrote:
> >>>
>  Apache Arrow is receiving a code for the Plasma Object Store[1].
> 
>  Please vote to approve this contribution.
> 
>  This is a lazy consensus majority vote, per the IP clearance
> process[2],
>  open for at least 72 hours.
> 
>  Julian
> 
>  [1]
> 
> http://incubator.apache.org/ip-clearance/arrow-plasma-object-store.html
> 
>  [2] http://incubator.apache.org/ip-clearance/
> 
> 
>  -
>  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: Urgent: Regarding Java package name change to org.apache.*

[Greg Stein]

On Thu, Aug 3, 2017 at 2:42 AM, Andy Seaborne  wrote:

> On 03/08/17 05:13, Roman Shaposhnik wrote:
>
>> On Wed, Aug 2, 2017 at 6:13 PM, John D. Ament 
>> wrote:
>>
>>> On Wed, Aug 2, 2017 at 8:54 PM Roman Shaposhnik 
>>> wrote:
>>>
>>> On Wed, Aug 2, 2017 at 5:40 PM, Abhishek Tiwari  wrote:

> Hi all,
>
> In regards to the recently incubated project - Gobblin, we were
> wondering
> about the policy around renaming Java package names to org.apache.* Is
>
 it a

> mandatory requirement or good to have?
>
> The reason to ask this is that while we see many projects have migrated
>
 to

> use org.apache.* package name for their Java source files, the Kafka
> project uses kafka.* for Scala sources and org.apache.kafka.* for Java
> sources.
>
> Please let us know as soon as possible, because we are in process of
> renaming the  packages but if not mandatory we would want to keep
>
 gobblin.*

> package name and avoid the cost of downstream migrations and backwards
> incompatibility.
>

 You don't have to do it right away, but it is a requirement unless you
 have a really,
 really, really good reason of why you can't do that.


 I'm not aware of any requirement around Java package naming.  IN fact,
>>> last
>>> time it came up it was clear that its a best practice only, and doesn't
>>> have any actual naming requirements.
>>>
>>
>> I'm not a policy wonk, but for every single podling I've witnessed this
>> has been a very strong bias to be in o.a namespace.
>>
>> Speaking as an IPMC member I would like to see new projects migrate
>> into o.a namespace unless there's a really good reason not to.
>>
>> Or to put it another way, if you want to avoid threads like this one:
>> http://markmail.org/message/2bsrtgckuuihhnv4
>> during your graduation VOTE -- it is better to think about rename now.
>>
>
> Jena was in a similar position with the main APIs under non o.a package
> spaces.
>
> We waited until a major version came along and that was several years
> after graduation.  While it had always been the intent to change, we could
> see that there was going to be major version hop due to othe factors and we
> didn't want to do it twice. We did move non-API code under o.a much earlier
> on an piecemeal basis.
>
> Jena users also have data with URI naming based on host names from our
> origins in HP. We have not moved those to a.o names but encourage migration
> though outputting some warnings when it is encountered and can easily
> changed.
>
> I think it sends a positive signal to new contributors to make the package
> change but it isn't always practical to do so by graduation. The user
> community is already impacted by moving the mailing lists and web sites etc.
>
> For JVM-related projects, the maven coordinates change on entering
> incubation. That is a strong enough signal.


Apache Subversion created a new org.apache.subversion API, and then rebuilt
our old org.tigris API on top of that. The old API is deprecated but still
available. It was also a great chance to refine the API after feedback from
users, and to drop ugly approaches. Much cleaner.

I'd definitely recommend constructing a new API within the org.apache
namespace, and deprecating the old. If you can't do it by graduation, then
get it on the roadmap as a high priority. Keep the old around as (say) a
separate compatibility package, layered onto the new API/naming.

Cheers,
-g

Re: Urgent: Regarding Java package name change to org.apache.*

[Andy Seaborne]

On 03/08/17 05:13, Roman Shaposhnik wrote:

On Wed, Aug 2, 2017 at 6:13 PM, John D. Ament  wrote:

On Wed, Aug 2, 2017 at 8:54 PM Roman Shaposhnik 
wrote:


On Wed, Aug 2, 2017 at 5:40 PM, Abhishek Tiwari  wrote:

Hi all,

In regards to the recently incubated project - Gobblin, we were wondering
about the policy around renaming Java package names to org.apache.* Is

it a

mandatory requirement or good to have?

The reason to ask this is that while we see many projects have migrated

to

use org.apache.* package name for their Java source files, the Kafka
project uses kafka.* for Scala sources and org.apache.kafka.* for Java
sources.

Please let us know as soon as possible, because we are in process of
renaming the  packages but if not mandatory we would want to keep

gobblin.*

package name and avoid the cost of downstream migrations and backwards
incompatibility.


You don't have to do it right away, but it is a requirement unless you
have a really,
really, really good reason of why you can't do that.



I'm not aware of any requirement around Java package naming.  IN fact, last
time it came up it was clear that its a best practice only, and doesn't
have any actual naming requirements.


I'm not a policy wonk, but for every single podling I've witnessed this
has been a very strong bias to be in o.a namespace.

Speaking as an IPMC member I would like to see new projects migrate
into o.a namespace unless there's a really good reason not to.

Or to put it another way, if you want to avoid threads like this one:
http://markmail.org/message/2bsrtgckuuihhnv4
during your graduation VOTE -- it is better to think about rename now.


Jena was in a similar position with the main APIs under non o.a package 
spaces.


We waited until a major version came along and that was several years 
after graduation.  While it had always been the intent to change, we 
could see that there was going to be major version hop due to othe 
factors and we didn't want to do it twice. We did move non-API code 
under o.a much earlier on an piecemeal basis.


Jena users also have data with URI naming based on host names from our 
origins in HP. We have not moved those to a.o names but encourage 
migration though outputting some warnings when it is encountered and can 
easily changed.


I think it sends a positive signal to new contributors to make the 
package change but it isn't always practical to do so by graduation. 
The user community is already impacted by moving the mailing lists and 
web sites etc.


For JVM-related projects, the maven coordinates change on entering 
incubation. That is a strong enough signal.


Andy


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