Skip to end of metadata
Go to start of metadata

In order to foster contributions and speed up review as well as the desire to store our source code in the same place as other major open source projects, Rice is looking at moving our source code to GitHub.

Background

  1. Farooq set up a Kuali githib repo at https://github.com/kuali. Needs a project to pilot it first.
  2. Jeff's stuff is out there at https://github.com/jcaddel.
  3. KC is migrating to Git this week. See their plans at SVN to Git.
  4. TRC has a working group. See TRC Git & GitHub Working Group.
  5. KFS is looking into migrating.  
  6. Someone needs to figure out best practices with regards to migrating an existing Subversion repository to GitHub and turn that into actionable steps
    1. Move the entire repo at once?
    2. Move parts of the repo?
  7. Goal is to move post Rice 2.3.
  8. Notes from git discussion at 1/23/13 KTI meeting
  9. Notes from git discussion at 11/30/11 KTI meeting
  10. KC conversion Notes: SVN to Git
  11. Repository Cleanup for list of current Rice svn repos

Items to Consider Before Moving

First step - is this the right technical direction for Kuali overall? - Eric, TRC

-> Yes, discussed at TRC and decided it was the right way to go.

Next step - Rice pilot, specific items below

  1. Developer education, coming up to speed. Steep learning curve. - DMs
    1. different concepts, same terminology means different things
    2. can take a couple of months to get up to speed
    3. ask developers to read documentation
    4. use existing developers in dev sessions
    5. look for online training
  2. Different workflows that github enables. - Architects & DMs
    1. Our current flow is most happens on trunk, branches for major & minor versions, sandbox. 
    2. On git, sandbox can go away. Local machines.
    3. How will we do topic branching.
    4. Discuss how we handle branching.
    5. Integrate code review process more.
    6. Developers on feature branches. Generate pull request that has to be accepted by a DM.
    7. git workflows, look for something else, decide on what we do
  3. How do we handle contributions - PMs, DMs
    1. structure around pull requests
    2. staging area where unit, integration, and AFTs run
  4. Look at gaps between svn & git - Dev Ops
    1. All subversion specific hooks/tooling/scripting will need a facelift
      1. Preferably being replaced by tooling that is SCM agnostic, supporting both SVN and Git (ie maven-scm-plugin)
      2. TODO: test mvn-scm-plugin to see if the newer version will work with release, nightly-tagging
    2. svn revision number plugin which is subversion specific, won't work with githib. Equivalent needs to be found.
    3. Nightly tagging process has svn revision number in the tag
      1. TODO: test out using build number alone for tagging (can set build # to retain continuity)
    4. Review database process and having it work on git in addition to svn
    5. Automated, revision based builds also contain the SVN revision number
    6. Bug is with parent directories not created.
    7. about 10 items total where existing process needs to be verified with regards to supporting both github and svn
    8. Maven-git integration may not be as good as maven-svn integration. Some known past issues.
    9. Dev Ops will need to create a detailed list of issues for review.
  5. Mechanics of cutting over the repository. - Infrastructure
    1. Import binary repo over to github
    2. Access permissions for everyone
    3. CLA required, normal process
    4. Electronic CLAs?
    5. Alternative to CLA
  6. Do we need to & how do we archive svn? - Infrastructure
    1. githib should pull in svn history
    2. can delete repository if you screw up
  7. Look into getting enterprise features for open source project. - Infrastructure

Steps

Preliminary Work

  1. Do migration analysis - Jessica, will document the svn layout & bring to meeting - DONE see Repository Cleanup
  2. Update our DevOps and CI integration so that it works with GitHub
    1. Take an export of a recent version of Rice (no history needed for this part)
    2. Load it into a GitHub project
    3. Set up a CI environment to test checkout, builds, maven release, tagging, etc.
    4. May need to update/rework plugins or processes. Will need to work with DevOps. 
  3. look for online training - Jessica; DONE, see Git Online Training
  4. Ask Mark Norton if we can do a lighter weight version of CLA for small items - Jessica
  5. come up with initial draft of our workflows - Jerry
  6. After 2.5 project plan comes together, see if we can have Peter take a look at this for 1-2 hours a week

 

Once We're ready to convert

Note: we'll need resources from Rice & DevOps to do the work

  1. Review KC page to see what other steps & considerations we have
  2. Get a list of all authors so that we can map them
    1. Using the following command:

    2. https://docs.google.com/a/kuali.org/document/d/1l6ubFuPBtWEvGg7weGu90z-IIBFUH0jLrJ3whPUQTEE/edit

  3. Get a list of all github user names for the Kuali Rice team: https://docs.google.com/a/kuali.org/spreadsheets/d/1uyLugRvd7EldJuIMRfhxt-_jwUcgzrQv7EnsFKc2RWY/edit#gid=0e
  4. Trial migration to sandbox - Farooq
  5. Try with test CI - DevOps
  6. Test with IntelliJ integration, Eclipse - ???
  • No labels