Hi Andy, The Internet connection to github is not stable in China. I'd go for svn instead. My svn account acquired last year works well now. I just created a jena-csv folder in Experimental [1]. In my case, I can commit code to jena-csv during this summer, which will not affect the trunk codebase. At the end of this project, when everything is ready, I can merge jena-csv into the trunk, either by 1) there will be a jena-csv folder in the trunk, or by 2) the code can be directly integrated into jena-core and jena-arq.
Best regards, Ying Jiang [1] https://svn.apache.org/repos/asf/jena/Experimental/jena-csv/ On Fri, Apr 25, 2014 at 10:28 PM, Andy Seaborne <[email protected]> wrote: > Hi Miguel, > Hi Ying, > > This message is to suggest how we organise over the summer. > > 1/ technical discussion in public on dev@. > > (and everyone else, feel free to join in!) > > 2/ git or svn > > Both projects can start outside the codebase and that'll mean the process of > changing trunk won't get in your way. Do whatever is simplest for you. > > You may not need to use the codebase at all initially and rely on snapshot > builds but if you do need the codebase you can either work against the > subversion codebase or the mirror on github. > > Much of this is personal preference. > > Personally, I'd work on github and use git for the GSoC project because it's > good experience. That said, the one feature that svn has is that you can > checkout a part of the tree. (git sparse checkout probably also works : > I've only used it once, briefly.) However, having the whole of trunk > locally, and importing only specific parts into Eclipse/etc works well for > me. > > 3/ Changing Jena itself. > > You'll probably find things that are broken, things that get in your way or > should be done better in the codebase. The main thing is to not let the > existing codebase slow you down. Raise a JIRA about the issue so we have a > permanent record. > > Miguel - attach a patch. From incoming stuff we've received, a github pull > request seems to do something useful. > > Ying - you have commit rights. We usually have a commit-then-review style, > in other words, just go ahead and make the change. If you put the text > string JENA-NNN into the svn commit message then a comment noting the commit > automatically get added to the JIRA. > > 4/ Weekly. > > When we start properly (May 19), could you at least send a message each week > about what you've done and what you are doing next. Nothing long is needed > - just a few lines. But don't wait for the weekly clock-tick if there is > anything you want to discuss. > > 5/ Timelines and plans. > > Each project has a timeline and plan. I don't believe them! or rather, I > see them as the best view at the time they were written and as the project > progresses, and more experience and insight is gained, they may well become > inaccurate and even downright wrong. Also, "stuff happens" and something > takes longer than expected (it's rarely that things take shorter :-). It's > normal to revise the plans. > > 6/ Release early, release often. > > There are several good reasons for this - getting feedback from anyone > interested as well as not putting off the setting up of the build process > for the project until the last minute. > > Andy >
