incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andy Seaborne <a...@apache.org>
Subject Re: Urgent: Regarding Java package name change to org.apache.*
Date Fri, 04 Aug 2017 09:00:56 GMT
On 03/08/17 23:20, John D. Ament wrote:
> Which must's do you see greg?
> 
> On Aug 3, 2017 1:09 PM, "Greg Trasuk" <trasukg@stratuscom.com> 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?


 >>> 1) package names with reverse domains MUST be renamed
 >>> before graduation or have an IPMC approved plan for renaming

SHOULD
(i.e. it needs a justification but isn't absolutely prohibited)

 >>> 2) Projects who expect that their future users outnumber
 >>> current users are highly encouraged to rename packages

+1

 >>> 3) Other projects are not required to rename packages and
 >>> backward compatibility is sufficient reason to not rename packages.

So there seem to be several cases:

Donated names should be fine.  (What about Maven coordinates here?)

.com really ought to migrate at the first convenient moment.
Non-donated, non-".com", less pressure but ought to migrate.
(Maven coordinates MUST change on entering the incubator.)

     Andy

>> 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 <johndament@apache.org>
>> 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 <aharui@adobe.com.invalid>
>> 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" <andy@apache.org> 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 <aharui@adobe.com.INVALID>
>>>>>>> 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" <asf@shanecurcuru.org
>>>>>>> <mailto:asf@shanecurcuru.org>> wrote:
>>>>>>>
>>>>>>>> John D. Ament wrote on 8/2/17 9:13 PM:
>>>>>>>>> On Wed, Aug 2, 2017 at 8:54 PM Roman Shaposhnik
>>>>>>>>> <roman@shaposhnik.org>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> On Wed, Aug 2, 2017 at 5:40 PM, Abhishek Tiwari <abti@apache.org>
>>>>>>>>>> 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.ap
>>>>>>>> ach
>>>>>>>> <
>>>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.a
>>>>>>>> pach>
>>>>>>>> e.org
>>>>>>>> <
>>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fe.org%
>>>>>>>> 2F&data=02%7C01%7C%7C581cf191f4d745137c4008d4da85
>> 30d6%7Cfa7b1b5a7b34438
>>>>>>>> 794aed2c178decee1%7C0%7C0%7C636373712971951815&sdata=aY%
>> 2BocRBKdLSJNW7r
>>>>>>>> 0X4YnZ239BbsJWprJgTncaEESNQ%3D&reserved=0>%2Ffoundation%
>> 2Fmarks%2Fresou
>>>>>>>> rces&data=02%7C01%7C%7Cef18c5e74b0141378
>>>>>>>>
>>>>>>>> 79a08d4da6d0e5c%7Cfa7b1b5a7b34438794aed2c178de
>> cee1%7C0%7C0%7C6363736093
>>>>>>>> 056
>>>>>>>>
>>>>>>>> 90124&sdata=OyrEoidSvoONvFJksGYjhhz%2FatAd4b%2FyjmHcfoGeI%2B0%3D&
>> reserv
>>>>>>>> ed=
>>>>>>>> 0
>>>>>>>>
>>>>>>>> ------------------------------------------------------------
>> ---------
>>>>>>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>>>>>>> <mailto:general-unsubscribe@incubator.apache.org>
>>>>>>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>>>>>> <mailto:general-help@incubator.apache.org>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ------------------------------------------------------------
>> ---------
>>>>>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>>>>>> <mailto:general-unsubscribe@incubator.apache.org>
>>>>>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>>>>> <mailto:general-help@incubator.apache.org>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>>
> 

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


Mime
View raw message