Skip to end of metadata
  • Created by Former user, last modified by Former user on Aug 20, 2014
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 Next »

 

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.
    • syncing would make it easier for merging into branches (less impact on existing users)
  • 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