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
