[vtk-developers] Migrating Git repository to Gitlab

[Utkarsh Ayachit]

Folks,

In August 2014, there was a discussion on the mailing list [1] about development
workflows. A conclusion of that conversation was that we will look at a
Github-like approach to make contributing easier. The time has come to act on
those discussions, and we will outline plans to do that below.

Since those initial discussions developers at Kitware have been evaluating
Github and Github clones to see what would work for our projects, including the
large ones like ParaView and VTK. Here is a summary of that evaluation and the
proposed plan.

* We have settled on using Gitlab (an open source Github clone) as the platform
  for hosting the official repositories. There are several advantages to using a
  self-hosted Gitlab instance, including support for customized server-side
  hooks.
* Gitlab is very Github-like. Thus we can use Gitlab for code-review instead of
  Gerrit. For simplicity, let’s call this Kitware hosted instance of Gitlab,
  KWGitlab.
* For VTK, we can use what is commonly called a *Forking Workflow* [2,3].
  Essentially, developers can create a fork of the VTK repository on KWGitlab.
  They can then create branches on their fork to develop new features or bug
  fixes. They can publish their branches to the world on their personal forks.
  Once developers are ready to merge that change into VTK, they go to the
  KWGitlab web application and create a *Merge Request*. Once a merge request is
  made, we can use testing infrastructure to run dashboards on the merge request
  (similar to what we currently do for Gerrit). We can decide on a convention as
  to what constitutes an approval of the merge request. Once approved, the merge
  request can be ‘accepted’ and merged into the master repo.
* Gitlab provides a nicer UI for inspecting changes and posting comments etc, as
  compared with Gerrit, and one that would be familiar to many Github users.
  Reviewing code will be easier, especially for topic branches with a number of
  commits. Attached are a few miscellaneous screenshots from the Gitlab instance
  we're testing out internally.
* For testing we have been experimenting with Buildbot to act as the scheduler
  that triggers a dashboard run when an ‘authenticated’ merge-request is
  received and ready for testing. Authenticated could mean something like the
  following:
    - The merge request has a specific label e.g. “do-tests” AND
    - The merge request was created by a user registered as a VTK developer OR
    - A VTK developer has made a specific comment to trigger the builds.
  We can set up a few buildbot-slaves to test merge requests in addition to the
  traditional continuous and nightly testing.

We will endeavor to make these changes as painless as possible, but ask that you
bear with us as we make the transition. We will flesh out low-level details for
contributing changes, dealing with conflicts, and so forth.

Q&A
===

1. What is the timeline?
   We are testing this out internally right now. There are a few things that
   need to be ironed out like managing ExternalData, updating
   SetupforDevelopment.sh, updating documentation etc. Once VTK 6.2 is out the
   door, we plan to go live with this initiative. This needs to happen by April
   20th, since Google stops supporting OpenID 2.0 [4] then and our current
   instance of Gerrit (with patches to support topic branches) uses OpenID 2.0.
   Thus VTK gerrit users will not be able to sign in to Gerrit after April 20th.

2. Does the git url for checking out VTK change?
   Yes. The git url will indeed change. The current plan is to abandon the old
   URL to avoid confusion.

3. What happens to the Github clone of VTK?
   That will continue as before. We will keep the Github clone updated as
   earlier. Eventually, we can start accepting pull requests on Github that can
   then be migrated to KWGitlab for testing/merging.

4. Are we also moving the bug tracker?
  The general consensus is that it will indeed be nice to start using the
  integrated issue tracker in Gitlab instead of the separate Mantis bug tracker.
  As a first pass however, let’s keep the changes limited. Once we have all
  settled in to using Gitlab we can start a separate thread to discuss how the
  bug tracker evolves.

5. Do I have to update all my dashboards?
   For most part, the only thing that needs to change on the dashboards is where
   the checkout VTK from. We are currently testing a Buildbot+CDash-based
   exhaustive testing model for ParaView to test individual merge requests.
   We’ll post details on how that experiment goes and then we can decide how VTK
   testing infrastructure can be expanded in time. We will certainly migrate the
   current Gerrit topic testing machines to test merge requests either using
   CDash at Home or Buildbot when all this goes live.

[1] http://public.kitware.com/pipermail/vtk-developers/2014-August/030755.html
[2] https://www.atlassian.com/git/tutorials/comparing-workflows/forking-workflow
[3] https://guides.github.com/introduction/flow/
[4] https://developers.google.com/accounts/docs/OpenID
-------------- next part --------------
A non-text attachment was scrubbed...
Name: merge_request_commits.png
Type: image/png
Size: 207591 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20150302/f4e814e1/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: merge_requests.png
Type: image/png
Size: 261858 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20150302/f4e814e1/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: network_view.png
Type: image/png
Size: 255075 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20150302/f4e814e1/attachment-0005.png>