Thanks everyone for the feedback! -Matt
On Mon, Aug 10, 2015 at 9:55 AM, Chris Nauroth <cnaur...@hortonworks.com> wrote: > Consideration of end user impact is a great point, and perhaps the most > important consideration. In the case of DataFu, others have brought up > that the rename would be a backwards-incompatible change that breaks all > existing client scripts that use DataFu, and going forward such a change > would cause extra low-value typing in a scripting language that's targeted > to serving non-programmers. I think this makes a compelling argument for > preserving the existing names in DataFu. For another project where the > package names are entirely an implementation detail and not user-facing, > doing the rename is not likely to cause impact. > > Thanks for bringing up the topic, Matt. > > --Chris Nauroth > > > > > On 8/10/15, 2:22 AM, "Stian Soiland-Reyes" <st...@apache.org> wrote: > > >I think you should consider the impact and potential gain on a > >per-project basis, and agree this within the podling. I don't think we > >can prescribe one way or the other for every project. > > > > > >Changing the package name can for Java developers be a bit of an > >identity thing and help to level the playing field if a strong > >commercial actor is still involved. Removing > >com.proprietarycompany.projectname can be more important than removing > >a neutral org.projectname. > > > > > >A more user-fronting project (e.g. a GUI or self-contained server) > >face less impact on renaming than a project with many compile-bindings > >outside the project (e.g. Hadoop). > > > > > >For the Taverna incubator (which can't be reliably placed on such an > >axis with a GUI+server and many external plugins), we decided that as > >we were moving to Apache at the same time as we were getting ready for > >3.0 with a different plugin system anyway, then this was a good time > >(and perhaps the only time) to do package rename. > > > >But for our project, which had numerous git repositories, Maven > >modules and OSGi configurations (and was due some refactoring), a Java > >package rename and restructuring was a bit more work than a quick sed > >and folder move, and left the codebase in non-compilable flux for > >several months and took away focus from community building. > > > >On the other hand, this was a good exercise for engaging the whole of > >the PPMC in taking responsibility for all of the code base - for our > >project we had a history of divide-and-conquer responsibilities, but > >once we had agreed on the new structure, then several committers could > >help in getting the code back in shape. Deciding on the code base > >structure "by committee" in the open rather than through a visionary > >"dictatorship" is quite a bit of overhead, but also helps build a > >common understanding and buy-in of how the project should be. > > > >For an early project like the Commons RDF incubator, package rename > >was done in a day and had minimal impact. Here we didn't do any > >structural changes except splitting out a new module. I think keeping > >the change lightweight is the best option if possible. > > > >As Andy pointed out, for a mature project like Jena (with third-party > >bindings) you might consider to hold off package rename until the next > >major release, which could be years down the line. You can still use > >the org.apache.* packages for new stuff, and if you have a clear > >api/impl split, also gradually move impl modules under org.apache. > > > > > > > > > >On 10 August 2015 at 02:28, Roman Shaposhnik <ro...@shaposhnik.org> > wrote: > >> Thank you all for the feedback. This is super helpful! > >> > >> One question that I still have is this: do we have a bias > >> for suggesting package rename or any package name > >> can remain in place? > >> > >> Thanks, > >> Roman. > >> > >> On Sat, Aug 8, 2015 at 2:25 AM, Andy Seaborne <a...@apache.org> wrote: > >>> Hi, > >>> > >>> Jena graduated 2012 with old namespaces under com.hp.hpl.jena, and some > >>> under org.openjena, with an intention to change at the first major > >>>release > >>> update. As new packages came along, they went into org.apache.jena > >>>but the > >>> user facing packages remained where they were. > >>> > >>> We released Jena 3.0.0 last month, so 3 years. That major release was > >>> coupled to another incompatible change (RDF 1.1 semantics) so 3.x > >>> wasn't just to do the packages, package renaming waited until a > >>>convenient > >>> point. > >>> > >>> Our users have data with (RDF) namespaces under old names - we are not > >>> planning on changing that at all. (A general issue for all linked > >>>data.) > >>> > >>> I don't see it as an issue for graduation if the project has > >>>considered the > >>> matter. > >>> > >>> Andy > >>> > >>> > >>> On 07/08/15 23:16, Matthew Hayes wrote: > >>>> > >>>> Hi all, > >>>> > >>>> Roman Shaposhnik suggested I open a discussion on the following topic: > >>>> > >>>> For Apache DataFu, all of the Java classes are declared in a datafu.* > >>>> namespace. This has been the naming convention since the DataFu > >>>>project > >>>> started in 2010. Since DataFu became part of the Apache incubation > >>>> process, the topic has come up of moving all of the classes into a > >>>> org.apache.datafu.* namespace. This was first discussed in January > >>>>2014 > >>>> (see DATAFU-7) and most recently again in the past couple weeks. The > >>>> consensus at the time last year was that it would be a huge pain for > >>>>users > >>>> and not worth the cost. It would break any script out there currently > >>>> using DataFu. Also Jakob Homan and Russell Journey pointed out that > >>>>this > >>>> is just a convention and not all Apache projects follow it. Since we > >>>> would > >>>> like DataFu to graduate sometime soon it would be good to clarify > >>>>what the > >>>> requirements are on package naming conventions before we do a release. > >>>> > >>>> Thoughts? > >>>> > >>>> Thanks, > >>>> Matt > >>>> > >>> > >>> > >>> --------------------------------------------------------------------- > >>> 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 > >> > > > > > > > >-- > >Stian Soiland-Reyes > >Apache Taverna (incubating), Apache Commons RDF (incubating) > >http://orcid.org/0000-0001-9842-9718 > > > >--------------------------------------------------------------------- > >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 > >
