User:YuviPanda/G2G

Tentative name for a set of scripts that make Gerrit / GitHub interop possible

The idea is that all actual code modifications happen on GH, Discussion happens on GH *and* Gerrit (sync'd 2 way), and final merging happens in Gerrit. It does not require that new contributors who wish to contribute via GitHub have a Gerrit account. Also does not require git review.

Workflow
It is a bot that does the following:


 * 1) Watch for new PRs in GitHub
 * 2) When a new PR comes in, opens an equivalent Gerrit patchset, and leaves a comment on the GitHub PR
 * 3) If there are multiple commits in the GH PR, they are all squashed into one
 * 4) Commit message is combination of title, description & commit messages of all commits in PR
 * 5) There's a link in the commit message to original PR
 * 6) Author information is preserved (hopefully only one person pushes to a PR).
 * 7) Committer is the bot account
 * 8) Whenever there is a comment on either GH or Gerrit, it is synced to the other
 * 9) Inline comments go to their appropriate inline places
 * 10) PR comments become patchset comments, and vice versa
 * V, C changes in Gerrit leave a text comment on GH
 * 1) When new commits are added to a PR, the appropriate Gerrit patchset is modified
 * 2) When a Gerrit Patchset is modified, the appropriate PR doesn't get anything added. We might even decide to invalidate the PR when this happens. Reason being in Gerrit everything is squashed so there's no way to just push a single new commit to the PR
 * 3) Abandon / Merge in Gerrit does the same in GitHub, but *not* vice versa.

Implementation
This should be implemented as a bunch of python scripts running on labs. A special purpose account should be created on both GH and Gerrit for the bot. It'll probably just use polling, but GH's post receive webhooks might be useful here. Gerrit might have a similar mechanism too - we could perhaps integrate this the same way Jenkins is integrated.

Alternative is to write a Gerrit plugin, but it has the disadvantage of being GWT/Java, and the advantage of producing simpler looking boxes when represented by an UML diagram.

An approach that combines both might also be possible. Need more research to find the simplest approach that could possibly work.

Modules

 * 1) GH PR modifications watcher
 * 2) GH PR -> Gerrit Patchset committer
 * 3) Gerrit Patchset comments -> GH PR comments
 * 4) Gerrit Inline comments -> GH Inline Comments
 * 5) GH PR comments -> Gerrit Patchset comments
 * 6) GH Inline Comments -> Gerrit Inline comments
 * 7) Gerrit Abandon / Merge -> GH close pull request

Planning
Trying to get all of this done at once will end in disaster, so let's get it done bit by bit

Iteration 1

 * 1) Create gerrit bot account, GH bot account, setup keys on labs
 * 2) GH PR watcher
 * 3) GH PR -> Gerrit Patchset Commiter (only initial request - manual trigger)

By the end of this, the bot can pick up brand new PRs and create equivalent Gerrit patchsets. It's okay to have this manually trigger.

Iteration 2

 * 1) GH PR -> Gerrit Patchset Updater (when new commit is added - automatic trigger)
 * 2) Automatic trigger for initial GH PR -> Gerrit Patchset committer

New commits added to a GH PR should automatically update patchset.

Iteration 3

 * 1) Gerrit Patchset Comment -> GH PR Comment (Automatic)
 * 2) Gerrit Merge / Abandon -> GH PR Merge / Abandon

This brings partial one way discussions sync from Gerrit to GitHub. Also automatic.

Iteration 4

 * 1) Gerrit Inline Comment -> GH inline Comment

This completes the Gerrit -> GH discussion sync.

Iteration 5

 * 1) GH PR Comments -> Gerrit Patchset comments
 * 2) GH Close -> Gerrit abandon

Iteration 6

 * 1) GH Inline Comments -> Gerrit Inline Comments

This completes GH <-> Gerrit two way sync

Timeline
Absolutely no clue. I don't think the iterations are equal length either - they are merely logically grouped bundles of work. I hope to get at least a good chunk of this done before end of April 2013, however - I'll be afk all of May.