Gerrit to GitHub migration

TLDR: Gerrit patches will be migrated to GitHub pull requests on Wednesday, May 8.

We will migrate the remaining Gerrit changesets as GitHub pull requests and will use GitHub pull requests for future changes to Charm++. We plan to do the migration on Wednesday, May 8.

The following steps will be taken:

1. Set the Charm++ Gerrit to readonly. (done)
2. Rename the charm branch to master on GitHub. (done)
3. Migrate changesets to GitHub. (done)
4. Enable Travis CI builds on GitHub. (done)
5. Modify autobuild to use GitHub. (done)
6. Change links in the manual and website.

About 200 open (i.e., not merged or abandoned) changesets will be migrated.

The pull requests will be created as branches on top of the master branch. The branches will be named review/<user>/<changeid>.

Pull requests will be created as the user that created the changeset on Gerrit, as long as we have the GitHub username and token (as pplimport otherwise), similar to the issue migration from Redmine. We can reuse the previous tokens, no need to send us new information.

After migration, the Charm++ Gerrit will remain online in read-only mode for some time.

Note that only the changesets will be migrated, not the comments or reviews on Gerrit. Migrated pull requests will have a link back to Gerrit.

Things that you could do:

• Please familiarize yourself with how pull requests work. Pull requests use a branch granularity instead of the commit granularity that Gerrit uses. Apart from this difference, most concepts are very similar between pull requests and changesets. I wrote a brief overview of how pull requests work here: https://github.com/UIUC-PPL/charm/wiki/Working-with-GitHub-Pull-Requests
• We have already migrated the Gerrit changesets of Projections to GitHub (https://github.com/UIUC-PPL/projections). A test import of Charm++ Gerrit can be found here: https://github.com/UIUC-PPL/charm-test
• Please merge or abandon changes, if possible. This will reduce the number of changes that have to be transferred.

Contingency plans

In case Travis is not usable

• We only have max. 5 parallel jobs, but Jenkins runs on 7 machines currently
• The 5 jobs are shared among Charm++ (~20 min build time), Charm4py (~13 min build time) and Projections (~1 min build time)

Possible solutions:

• Use Travis build stages
  • only start 1 build in first stage, run the others only if that first build succeeds
  • or, only build Charm++ in the first stage, run tests only after all builds succeed
• Continue using Jenkins for Linux builds, use Travis only for a Darwin/Windows build
• "Merge" some of the builds, e.g. test linux-netlrts smp and non-smp in the same VM, one after the other

In case (some) pull requests are not usable

• Potential difficulties with conflict resolutions, dependencies among changesets, ...

Possible solutions:

• Continue using PRs, but merge these difficult changesets on gerrit (requires manual sync from github to gerrit before)

TODOs

• Add testing with NAMD, Changa, ...