Hi Junjue, It will be simplest to track if you fork the Marmotta repository at GitHub and create a branch named "MARMOTTA-593".
Add me as a collaborator to the GitHub repository. My GitHub id is "ansell". The collaborators list for my fork is at: https://github.com/ansell/marmotta/settings/collaboration When you fork it, you can replace "ansell" with your GitHub id and use that page to add me to the list of collaborators. Yes, the code will be merged to Marmotta in the end. You should create a new module inside of marmotta-sesame-tools named "marmotta-rio-rdfht" https://github.com/apache/marmotta/tree/master/commons/marmotta-sesame-tools You will also need to add a format constant into marmotta-rio-api as a new folder in the following directory, similar to the current 3 folders there: https://github.com/apache/marmotta/tree/master/commons/marmotta-sesame-tools/marmotta-rio-api/src/main/java/org/apache/marmotta/commons/sesame/rio Cheers, Peter Cheers, Peter On 16 May 2015 at 22:19, Junyue Wang <[email protected]> wrote: > Hello Sergio, Peter, > > It's my honor to be a GSoC student. I appreciate your help for the comments > of the project proposal. > I read the proposed methodology you pointed out. But it seems my project is > only related to Sesame and RDF HDT, without touching the code base of > Marmotta. Should I fork Marmotta in github, or start a new repository there? > Will my code be merged into Marmotta in the end? If so, which module of > Marmotta? > > yours, > junyue > > On Thu, Apr 30, 2015 at 2:41 PM, Sergio Fernández <[email protected]> wrote: > >> Hi Peter, >> >> On Wed, Apr 29, 2015 at 1:12 AM, Peter Ansell <[email protected]> >> wrote: >>> >>> Those guidelines look great to me, especially the suggestion about the >>> branch name including the Jira issue, which I have found very useful >>> in all of my git-based projects. In the RDF/HDT case, and possibly in >>> the GeoSPARQL case, the contributed code could be in the form of a new >>> module, so there won't be much interference with the rest of the >>> codebase during that time. However, it is still useful to regularly >>> merge the "develop" branch into each of the branches to keep up to >>> date and reduce the number of merge conflicts occurring near the end >>> when the students will be rushing to complete the project. >> >> >> Great you like it, Peter :-) >> >> I expect less merge conflicts, nevertheless it's a more concrete library; >> with the GeoSPARQL project that workflow is much more important. >> >> I've just have one concern about the documentation. Last year I had >> formatting issues bringing that documentation into the wiki (MoinMoin >> syntax is not markdown, unfortunately). Do you think is better to do it >> directly in the wiki? >> >> I'd love to hear comments from our students, after all you're the ones who >> need to follow that proposed methodology. >> >> Cheers, >> >> -- >> Sergio Fernández >> Partner Technology Manager >> Redlink GmbH >> m: +43 6602747925 >> e: [email protected] >> w: http://redlink.co >>
