Skip to end of metadata
Go to start of metadata

 

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

ItemOutcomeDate
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.
  • 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

  • No labels