On 10 February 2015 at 20:31, Marvin Humphrey <mar...@rectangular.com> wrote:
> I also think it would be OK for the project to decide it wants to become a > TLP. Whether the project joins Commons or becomes its own TLP won't impact > the number of people qualified to work on it. Some Apache TLPs are > effectively in maintenance mode and have very low activity, but still have PMC > members willing to answer user questions, make security releases and file > "still here" quarterly reports. That seems like a legitimate aspiration for > this project. Right - I think it would be good to leave as a decision to be made by the PPMC when we get closer to graduation. One problem with TLP is that we would likely need a different name ;-) > A potential Jena destination also seems as though it would have certain > advantages, though my naive speculation is that it might be sub-optimal in > terms of providing neutral territory for negotiating a common API for Jena and > Sesame. Right, the idea is for this to get a common, neutral ground. Although several of the existing implementations, including Jena and Clerezza, already have the 'abstract' sense of this API, but Commons RDF API aims to be common across those, and not to "pick sides". So we have agreed that the new API has to live outside the bigger frameworks. > In any case it seems likely that if the project achieves its design goal, > there will be people willing to work on it as long as both Jena and Sesame > remain viable. That makes it different from other potential "maintenance > mode" TLPs which are in danger of stagnation because they cannot renew their > communities. I imagine the API would not evolve much once it stabilizes - there's only that much maintenance you can do on an Java interface :). But there are additional things we are trying out, like a simple reference implementation, compliance tests, and event notifications. Some general utility functions could also evolve later (e.g. "Copy complete graph from implementation A to implementation B") - but during incubation we would want to focus on the core interfaces and integration with the existing implementations. As our community evolves, I guess documentation would also play a role - the API aims to be common across the RDF implementations - therefore users of the API could be considered a single community (compare with say the JAXB API) - so some usage documentation and tutorials could be appropriate. This would however point out to details in the (Apache and non-Apache) implementations. > Those sound like final mailing lists rather than Incubator ones. I might have > expected these instead: > > d...@commons-rdf.incubator.apache.org > comm...@commons-rdf.incubator.apache.org My guess is that Sergio just suggested "classic" addresses out of habit. :-) Personally I would agree with the above. > Do you expect to keep separate mailing lists after graduation, or will traffic > be shunted onto existing Commons mailing list like d...@commons.apache.org and > comm...@commons.apache.org? Right - part of the community building (if we continue the Commons route) is to gradually move (the decreasing) traffic to the existing dev@commons lists. Commons don't want to split the community with new component-specific lists, which we can understand. However we felt that to start out with growing the Commons RDF community on dev@commons would be a bit of a challenge (300 to 1000 messages/month!) - so part of the motivation for incubation is to have a more separate space within Apache while we flesh out API design and implementation questions - and then whoever "survives" so to speak should be able to move along as we join @commons. :-) > Lots of Apache experience in this group. Four are PMC members of at least one > Apache project. Andy and Reto are ASF Members. Andy and Sergio are both IPMC > members. Stian is a core contributor of the Taverna podling. > > You probably haven't been getting much feedback because there's a lot going on > in the Incubator right now and everybody figures that with a group like that > you're in good shape. :) Agree, Commons RDF is a slightly different proposal - in a way we need the incubator mainly to mature the API (e.g. fight over method names) and grow the community, rather than to be a "podling" to learn the Apache Way and battle with NOTICE files. As you see below, though - we still need volunteer mentors. > The Champion's main work is to help formulate the proposal. That work is > essentially done -- so it doesn't matter too much who takes that role, now. > Are Andy and Reto opting out out as a gesture of openness to Sesame? Sergio has effectively been the Champion for this proposal, but I guess he's not technically admissible as the Champion needs to be a Member or Director. >> === Nominated Mentors === >> >> * Benedikt Ritter (britter at apache dot org) >> * TBD > > Benedikt is a member of the Commons PMC, but he's not a member of the IPMC nor > an Apache Member -- so although Commons input is important, unfortunately it's > not a valid nomination. We pointed this out, we would however still like to keep Benedikt as an informal mentor and our "Commons" representative - in a way we have to learn also the "Commons Way". Voting-wise we have 2 IPMC members already, but obviously it would be good to have more IPMC folks mentoring so we don't have to 'fish' for release votes. > I'd nudge newly elected IPMC member Rob Vesse, but maybe the roster is already > Jena-heavy? Good idea. :) And not unknown territory for Rob. So I agree to be careful of getting Jena-heavy (I'm not quite neutral either), but it would be great to have Rob involved - I'm sure he would try to keep his clean fresh mentor hat on - just like I try to keep my "API user" hat on in this project. :-) We were hoping to also get some "RDF neutral" mentors. -- Stian Soiland-Reyes --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
