In discussion on JENA-1015 (Commons RDF module) the question has arisen (as Andy put it there):
'How can we have a core set of modules (base to Fuseki maybe) and some other modules that range from "additional" to "experimental" while at the same time not getting into too much release overhead.' I'll throw out some off-the-top-of-my-head ideas just to get conversation started: In another project with which I have worked, the approach was to have tiers within the project itself (in that example, a "labs" tier, an "extensions" tier, and a "core" tier). Higher tiers committed the project itself (read: committers) to more intense support but also carried with them more qualifications. E.g. to get into the "extensions" tier it is necessary to have committed support from two institutions that are members of the larger organization associated with that project as a whole. Obviously, that doesn't work directly for an Apache project, but mutatis mutandis we could develop some similar scheme. Maybe Jena could support two classes of modules, core and not-core. Core would be as Andy describes above, not-core would include everything else. Just as a strawman, we could say that in order to support a not-core module, Jena might require the (voluntary) assignment of at least N committers to it who will maintain responsibility for it. (N=2 or 3, maybe?) Only those committers would normally make releases of that particular module, and they would have the responsibility at minimum to see to it that the latest release of their module works with the latest release of the core. This scheme would have the advantage of letting us partition the modules already in the project as well as making some space for possible future extensions, but it would require some organizational work and some overhead to get set up and run. (Although it might reduce the overhead for a core release, which is a nice thought.) On the other hand, a real sharp and simple (and inexpensive) approach would be to say that Jena just doesn't maintain any non-core modules. If a non-core module is interesting enough to a community that intersects with that of Jena, it's on that community to find a home for it, either independently or via some other project (Apache or no). For example, I'd be curious as to whether the Commons RDF project could help host a Jena impl of Commons RDF. This scheme has the advantage of minimal burden on Jena. In the field already we have https://labs.apache.org/, but that is focused on the efforts of individual committers and (IIRC) explicitly excludes making any releases. Other flavors? Other thoughts? --- A. Soroka The University of Virginia Library > On Jul 1, 2016, at 6:30 AM, Andy Seaborne (JIRA) <[email protected]> wrote: > > > [ > https://issues.apache.org/jira/browse/JENA-1015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15357808#comment-15357808 > ] > > Andy Seaborne edited comment on JENA-1015 at 7/1/16 10:30 AM: > -------------------------------------------------------------- > > There is a useful bigger discussion here that would be better on dev@. > > How can we have a core set of modules (base to Fuseki maybe) and some other > modules that range from "additional" to "experimental" while at the same time > not getting into too much release overhead. > > > > was (Author: andy.seaborne): > There is a useful bigger discussion here that would be better on dev@. > > How can we have a core set of modules (base to Fuseki maybe) and some other > modules that range from "additional" to "experimental" while at the same time > getting into release overhead. > > >> Commons RDF module >> ------------------ >> >> Key: JENA-1015 >> URL: https://issues.apache.org/jira/browse/JENA-1015 >> Project: Apache Jena >> Issue Type: New Feature >> Components: Jena >> Reporter: A. Soroka >> Priority: Minor >> >> Based on a thread on the dev@ mailing list: >> http://markmail.org/search/?q=jena+commons+rdf#query:jena%20commons%20rdf%20list%3Aorg.apache.incubator.jena-dev+page:1+mid:jjljtijtw36f3jf3+state:results >> and mention on the users@ mailing list, there is some desire to implement >> the Commons RDF API: >> https://commonsrdf.incubator.apache.org/ >> This issue is to track just such an effort. > > > > -- > This message was sent by Atlassian JIRA > (v6.3.4#6332)
