Github migration

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

Decisions agreed upon

Item	Outcome	Date

Item	Outcome	Date
Using github (not any other form of git/repo etc)
Continue using JIRA for issue tracking and turn off the github issue tracker to prevent confusion

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