Github migration

This page will track the tasks and schedule around the migration of the Sakai code from SVN to github:

https://github.com/sakaiproject

Decisions agreed upon

Tasks

• Flatten externals
• Is it worth shuffling the code around completely, ie an API directory, tools directory, etc.
• Jenkins builds need to be switched to

Issues

• SVN will need to be syncronised with git commits for the branches for as long as they are supported. Yes/no? We could just move the tags too.
  • syncing would make it easier for merging into branches (less impact on existing users)
  • http://behindcompanies.com/2014/01/a-simple-script-for-deploying-code-with-githubs-webhooks/
• Moving msub will be difficult without long timeframe to allow institutions to migrate themselves and upskill.
  • guide to moving
  • people should be able to migrate on their own schedule
  • msub and the svn sync would likely need to be kept running until 10.x is no longer supported, so at least until 2016
• What do we do about contrib?
  • People move their own tools where they want?
  • Create a new contrib repo and bundle the tools inside there? Its not all tools though.
  • Potentially give people advance warning then just switch it off. Possibly the same time frame as for msub (June 30 2016?)
  • Create a separate github repo for each contrib tool?
    • devise a simple workflow to integrate those repos with the "normal" build
• What do to about pull requests/patches? 
  • Even if we continue to use jira, I'm guessing we'd take patches going forward as part of the github pull request system
  • Do we attempt to migrate all contributed patches that currently exist in Sakai over to here (there are hundreds), leave them as-is or just close those tickets with a comment that they should be a pull request?

Commit procedure

• Everything handled by local forks and pull requests, core team responsible for reviewing and merging PRs.
  • The core team reviews many patches every week and instead of a patch file this would now be PR's.
  • It should not be common practice to merge your own PR's 
    • There are situations where this would be fine
      • Release process as this does updates to poms
      • possibly Tool Maintainers?
    • Kernel should always be reviewed with the exception of releasing.
• See Jasig page on git workflow for committers and non committers.
• What about i18n updates? Ideally it would be easier than staging a pull request.

Volunteers

• Former user (Deleted)
• Former user (Deleted)
• Matthew Jones