[vtk-developers] Migrating Git repository to Gitlab

[Utkarsh Ayachit]

Folks,

We are getting ever closer to making this move to Gitlab. If all goes
well, the move will happen on Monday, March 16th.

More details on what the development workflow looks like after this
migration will be coming out soon. Behind the scenes, Brad and Ben
have been working tirelessly to update the SetupForDevelopment scripts
and documentation among other things, like uploads for testing
data/baselines etc. As a consequence, all that this boils down to is
to checkout VTK from the new Git URL, and run SetupForDevelopment
script.

In the mean time, there's not much to do. You may want to consider
cleaning up any old gerrit topics, either getting them review/merged
or abandoning them.  The Gerrit instance will remain accessible for a
while so you can still get to the changes you made to be able to move
them manually to Gitlab for review in the new workflow. Dashboard
maintainers, be prepared to change the Git URL for your dashboards on
Monday.

Last, but not the least, thanks for your patience so far and following
the migration as we iron out any remaining kinks!

Utkarsh



On Mon, Mar 2, 2015 at 10:03 AM, Utkarsh Ayachit
<utkarsh.ayachit at kitware.com> wrote:
> 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