Which must's do you see greg? On Aug 3, 2017 1:09 PM, "Greg Trasuk" <tras...@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? > > 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 <johndam...@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 <aha...@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" <a...@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 <aha...@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" <a...@shanecurcuru.org > >>>>> <mailto:a...@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 > >>>>>>> <ro...@shaposhnik.org> > >>>>>>> wrote: > >>>>>>> > >>>>>>>> On Wed, Aug 2, 2017 at 5:40 PM, Abhishek Tiwari <a...@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-unsubscr...@incubator.apache.org > >>>>>> <mailto:general-unsubscr...@incubator.apache.org> > >>>>>> For additional commands, e-mail: general-h...@incubator.apache.org > >>>>>> <mailto:general-h...@incubator.apache.org> > >>>>>> > >>>>> > >>>>> > >>>>> ------------------------------------------------------------ > --------- > >>>>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > >>>>> <mailto:general-unsubscr...@incubator.apache.org> > >>>>> For additional commands, e-mail: general-h...@incubator.apache.org > >>>>> <mailto: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 > >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
