Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • The entire history of uPortal including all maintenance branches would be copied to GitHub, all new development and maintenance would take place via git.
  • The uPortal code in subversion at source.jasig.org would be left in place. The entire /uPortal directory would be made read-only and no further updates would be done in SVN. Optionally the /uPortal directory would be deleted allowing for access to specific revisions but reducing confusion for people new to the project looking for the uPortal source code.The documentation and manual content included in the uPortal source code in early versions of uPortal 2 would be filtered out in the migration to reduce the git repository size. There would be a process that mirrored all post-migration commits to the git repository to the uPortal directory in Subversion allowing deployers using SVN specific integrations to continue using those processes.

Test Migration

A test migration of the uPortal source code has been completed and is available: https://github.com/edalquist/uPortal-GitTest If anyone would like access to play with this throw-away repository email Eric Dalquist.

...

  1. Developer Familiarity
    • Primary concern with speed for applying critical fixes for a 4.0.1 release
  2. svn:externals
    • Used by some deployers as an alternative to a vendor drop import
    • This should be addressed by the read-only SVN mirroring that will be maintained
  3. Local deployments using Subversion (if Subversion is their institutional repository)
    • Process to merge fixes into local repository directly from the uPortal repository?Are there examples of a patch merging process that is specific to uPortal using Subversion?
    • This should be addressed by the read-only SVN mirroring that will be maintained
  4. Sakai-Jasig merger 
    • How will this relate to the merger and any broader SCM/Release management strategy? (http://groups.google.com/group/jasig-sakai-collaboration)
    • As far as I know projects Projects under a merged Jasig/Sakai Collaboration will still be responsible for setting their own SCM and release management strategies just as it is now under Jasig

...