The thoughts behind my original comment were as much driven by getting
the last release out as well as a potential new module.
Ideally, everything gets released synchronously with all versions in
step. But in a big system, the ideal isn't always possible.
At the moment, the upgrade to Apache POM 18 has broken the jena maven
tools (I have no idea why). This is a dilemma - upgrade to the better
process with one module excluded to stay back on the old version (2
version back). In this case, the upgrade was more to keep track of the
parent but suppose that it was for a bug fix.
Some parts of the Jena release are used more widely than other parts.
It seems prudent to accept that some releases may be for part of the set
of modules. And rather than discuss that at the release point,
discussing what the community wants ahead of that busy time is useful.
This extends to new modules that might arise. Applying the same
criteria to a new piece of work (e.g. works in all cases) is IMO too
high a barrier. The criteria I'd like to use are more like as long as
the code is legally clean and does something useful.
That said, for new work, the approach of separate github repo, not
formally connected with the project seems the lowest work for the
project. I'm not a fan of the idea of Project Jena encompassing
everything because the PMC can't as effective if it has to watch
everything. "Modules" with a different community is healthy.
This gets into a full circle - that new work might need tweaks to
"jena-main" (for want of another label) which are quite small except
that it enables the new work to progress. Luckily the new work can
depend on snapshot builds for a while but maybe a release specifically
for jena-main changes, or specific release of jena-main because of some
bug, could come along.
Andy
On 04/07/16 17:42, Stian Soiland-Reyes wrote:
On 4 July 2016 at 17:23, A. Soroka <[email protected]> wrote:
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?
That is indeed the danger.. that approach works well for what aims to
be integrated additions. But that said, Fuseki 2 has managed to become
integrated.
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.
Yes, obviously practically the actual release would have to be done by
an existing committer, but there is nothing stopping a PMC to own
multiple git repositories, see for instance: http://git.apache.org/
It's just a few clicks in Jira to ask Infra to make a new repository -
with a few checks later that say the GitHub Pull Request integrations
are working.
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?
No, that's the kind of thing a PMC can just bootstrap on its own.
BTW - I've now added
https://github.com/apache/incubator-commonsrdf/tree/jena/jena so I
guess that particular example is now moot :)
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?
Such a GitHub group would not be formally associated with ASF or Jena
PMC (and that would have to be made clear) - just with particular
individuals who happen to also be part of Jena.
See the bottom of
https://taverna.incubator.apache.org/download/code/#taverna-extras
for how we did this - note that we used it more of a 'dumping ground'
for license incompatible stuff - that kind of thing would earlier have
been done at "Apache Extras" at Google Code
https://code.google.com/a/apache-extras.org/hosting/ - but as Google
Code now is in Read-only that is no longer an option.
