Comments in-line. --- A. Soroka The University of Virginia Library
> On Jul 1, 2016, at 8:58 PM, Stian Soiland-Reyes <[email protected]> wrote: > > 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. > > 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. Hm, I'm not sure whether it would discourage people from working on core or encourage new people (who might not be ready to work on the core) to work on the periphery. But in any case, this suggestion had the disadvantage of requiring more overhead, so it wasn't a great idea anyway. I'm not going to make any lengthy argument for it. > 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. ... > 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. This seems a bit problematic to me. What about the cases (which are really the cases of interest) for which there is no horizon in time at which the work is to "catch up" in any particular sense, for which the extension modules have an independent future? > b) Someone proposes a new feature or module, perhaps fresh orhalf-baked code > base, and Jena PMC asks Infra to make a new ASF repository, e.g. > https://github.com/apache/jena-fuseki (let's sayFuseki was new today). ... > 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" This seems intriguing-- are you suggesting that the new folks would be able to make releases out of the special "sidecar" code-base? What relationship would this proposal have with the formal incubation process? This is kind of asking for Jena to have multiple repositories under the Apache org, which seems reasonable to me, but then, I don't understand the implications for Infra and the work they would have to do for this. > 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). I think this makes sense for a lot of possible projects (larger ones, mostly). But the example in hand (a Commons RDF impl) is one where the size of project doesn't seem to merit a new Apache incubation, right? > 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. I like this, in many ways. It's low-cost, simple, and flexible. But I don't know enough about Apache methods to understand what the implications are for "ownership". Is it possible for a project (Jena) to "lay claim" to a GitHub org like that without some kind of formal arrangement with GitHub, and if not, is that formalization difficult or costly? > -- > Stian Soiland-Reyes > Apache Taverna (incubating), Apache Commons > http://orcid.org/0000-0001-9842-9718
