Thanks Sergio for helping push out 0.2.0! It is of course sad we didn't achieve what we aimed for - as you say many things affected this, including timing, politics and differences in expectations. You could say that to do what we aimed for we should have worked more like a traditional JSR or W3C committee with a fixed timeline, chair, deliverables etc. - forcing through solutions rather than trying to agree at every point. But let bygones stay bygones!
I think that doesn't mean we have to abandon ship - we can let Commons RDF be more of an interoperability layer than a common layer - more similar to Commons VFS as opposed to the JAXB API. The scope of Commons RDF should however remain small - not to grow to a Clerezza or Any23 competitor. Perhaps rdf4j is a good use-case - Commons RDF could easily be a compatibility layer between Sesame 4 and rdf4j on a triple/quad level. We are facing a usual chicken&egg problem - if we go to a community like rdf4j and say "Hey, use Commons RDF" they might say "Who else is using it?". I don't know what you think of us trying to release some basic integration modules ourself within Commons RDF like my branches for jsonld, sesame and jena? Too much of a distraction? Ideally for maintenance we wanted Commons RDF to be a 'frozen' & stable API and for such integration to be done at each third-party project - however I think doing dependency upgrades is not something that is particularly tricky within the Commons community - and things like keeping APIs stable is a key value within Commons. I agree with John on the point that we don't need a big growing community to graduate to Commons - just to be in a "releasable" and maintainable state - which I think we are already at. So personally (as a fresh Commons PMC member!) be in favour of Commons RDF graduating to Commons. On 27 May 2016 at 12:11, John D. Ament <[email protected]> wrote: > Hi Sergio, > > Thanks for bringing this up. This has been on my mind since Andy left the > project, I hadn't brought it up yet as I wanted to see if someone else > would first :-) > > Retirement basically means the podling hasn't been able to build a > sustainable maintenance cycle. I don't think that's the case here. A > retiring podling is one where a large number of people signed up at the > beginning, but then none participated. > > I will say I've always seen community growth as a big challenge for what > you're trying to do. That's why I was pleased to see the target being > commons rather than a standalone PMC. There are enough people in the > commons community to rally behind a release that even if its just one or > two committers here, its enough to get things moving forward. > > In my opinion, I would like to see the commons PMC weigh in on what steps > they'd like to see commons rdf complete between now and graduation. You've > had two perfect incubator releases. That usually means you're graduation > material. > > Gary - you're probably the best one to answer that question. If I look at > the graduation guide, it seems like the accepting project is pretty key > here, http://incubator.apache.org/guides/graduation.html#subproject, and as > chair of commons, I think you'd be the best one to ask. > > John > > On Fri, May 27, 2016 at 5:49 AM Sergio Fernández <[email protected]> wrote: > >> On Fri, May 27, 2016 at 11:43 AM, Sergio Fernández <[email protected]> >> wrote: >> >> > I'd live to hear it. >> > >> >> s/live/love >> >> >> -- >> Sergio Fernández >> Partner Technology Manager >> Redlink GmbH >> m: +43 6602747925 >> e: [email protected] >> w: http://redlink.co >> -- Stian Soiland-Reyes Apache Taverna (incubating), Apache Commons http://orcid.org/0000-0001-9842-9718
