On 29/02/12 13:13, Ian Dickinson wrote:
On 29/02/12 12:05, Andy Seaborne wrote:
A discussion on general@i
It will resolve whether we have to repackage Jena to graduate.
It's not just the repackaging. Some of the more astringent commenters
are "shocked" that even having compatibility packages and classes (i.e
not under org.apache) in a TLP has ever been allowed. So depending on
how the vote goes, we could be forced to remove all mention of com.hp.*
from the code base, and host the compatibility layer packages somewhere
else.
The problem that gives us is that all the references out there to Jena -
code samples, presentations, articles, papers, tutorials and even books
will be instantly out of date. The discussion on general@ has the tenor
of "well, it's Cloudera's problem so let them sort it out" but that's
not true for Jena. It's not HP's problem!
Absolutely agree. And to your general@i email.
It's a major cost to users, and I don't see that it is to anyone's
benefit to force the extreme case of no non-apache packages.
It's hard to determine but I don't see any evidence that some set of
potential users is put off using Jena by the package name. We do known
that leaving HP made a difference.
If we have to re-name packages to graduate, so be it that's not really a
big deal**. If we have to completely expunge all mention of com.hp.*,
that would be at the very least disappointing.
And then there are vocabularies :-|
Ian
** Well, it'll take some work to get the site docs and Javadoc in line
with the packages.
The other thing about this whole discussion is that it is loaded.
If incubator expects a project to rename, it's still not promising it
will graduate. So a podling comes in, does the change, gets mauled, the
user community messed about. Can the podling take the namespace with it
if it is retired?
Andy
