On 1 July 2016 at 15:46, A. Soroka <[email protected]> wrote: > 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.)
In effect this is what we already have with some of the modules, e.g. elephas and Fuseki. I wouldn't want to formalize such a grouping, as it would mean say the Fuseki grouping could be more scared from fixing core or vice versa. For "new" and "experimental" things, why not try one of these: a) "Anyone" can ask to have a feature branch for their new thing in https://github.com/apache/jena repository. They can contribute by GitHub pull request, but merging into "their" feature branch. As Pull Requests are social, this might build interest in the new features, and others might also contribute to the branch - which potentially would stabilize and join the main "master" branch to become part of a full Jena release. As usual, regular PRs and wider engagement puts them on the track to committership - but if they only commit to their special branch without doing the effort to merge into master they might not qualify. We used this in another project with GSOC students - one practical problem with this is that there can be many branches to keep track of (e.g. the pull request suddenly goes to master instead), and that the branch can lag behind - e.g. your feature end up using a SNAPSHOT of core. But branches are cheap, and if the experiment turns out to be a flop it can just be tagged and then the branch can be deleted. (it can be resurrected from tag if needed) Another issue in this approach is releases - e.g. let's say the new feature was Fuseki and you want a release based on the stable core - but the rest of Jena core master is not feeling for a release right now, e.g. it's upgrading to Java 9. So now you might have to do a slightly dirty "partial release" of just the new module, with modified poms to rely on the stable core. This means you get mixed tags and tricky history - but it's OK if you then later "catch up" and the module agrees to keep the same dev/release speed as core. b) Someone proposes a new feature or module, perhaps fresh or half-baked code base, and Jena PMC asks Infra to make a new ASF repository, e.g. https://github.com/apache/jena-fuseki (let's say Fuseki was new today). They contribute by pull requests - it's all done on dev@jena as above, and again interest might build up. Releases and dependencies against Jena Core can then be done cleanly - at least as long as you don't need a SNAPSHOT feature in Core. This would enable a 'faster' route to committership I think - although the new committers would start with having experience mainly in "their" repository, they might need to do things like releasing Jena Core if they need a SNAPSHOT feature. Here the questions is what happens if the N<3 volunteers of the new component all wither away - then basically that repository is "at risk" c) The newcomer proposes an incubator project with Jena as the Sponsoring PMC. This has the danger of going towards a "Jakarta" model with many large projects that stop being relate to each other - but it's probably a better option if the new thing looks like it might become a separate product; the podling could then build its own community and have a choice to graduate to either a TLP (if Incubator PMC so agrees) or become formal part of Jena (if Jena PMC so agrees). The disadvantage of this is that the podling would not be as connected to Jena to start with and the newcomers won't be on track for Jena committership. (However they will have to learn the Apache Way through the podling) d) You set up a "jena-extras" GitHub organization with very low barriers for contributing. Basically anyone can start a git repository and ask to transfer it to jena-extras for shared custodians. Anyone who contributes are added to the organization, in addition to the ASF Jena committers (if they want to). The problem with this is that it's easy to end up with lax IP governance and you'll have a harder job later to move it into Jena (e.g. you would need to do a formal Software Grant) - however that can also be an advantage if the experiment wanted to try dependencies of incompatible licenses, e.g. 4store (GPL). Community-wise there's a danger that this would form a "lower tier" and risk making it harder to become part of the Jena PMC, as any new and cool stuff could just be sent straight to jena-extras, where the newcomers don't get to learn the "Apache Way" and perhaps don't even communicate with each others moduels. Discuss! ;-) -- Stian Soiland-Reyes Apache Taverna (incubating), Apache Commons http://orcid.org/0000-0001-9842-9718
