[ITK] [ITK-dev] [ITK-users] Migration to GitHub

[Marcus D. Hanwell]

On Tue, Aug 1, 2017 at 5:45 PM, Sean McBride <sean at rogue-research.com>
wrote:

> On Tue, 1 Aug 2017 11:40:25 -0400, Francois Budin said:
>
> >As Matt mentioned, the main reason is because a lot of ITK users already
> >have Github accounts and are familiar with that environment. The idea is
> >really to make is as simple as possible for the community to contribute.
> >Using Gitlab would still require users to have an account on GitLab to
> push
> >patches. Most ITK users already have a Github account with their own
> >projects, and contributing to ITK just requires cloning the project and
> >creating a pull-request.
>
> The fact that many people are familiar with github and its workflow is
> indeed a good argument.
>

Indeed, one should not underestimate the power of going where the people
are, and frankly the GitHub workflow has continued to improve enormously
over the years. Many of the features that were missing when we initially
chose Gerrit (and GitLab wasn't even a project) are now present. You can
require pull requests have been reviewed, that a CI test passes, assign
multiple reviewers, etc.

>
> But the "using Gitlab would still require users to have an account on
> GitLab" I think is no argument at all.  Creating a GitLab account is a fast
> and easy one-time task, the browser can then remember your password, etc.
> Everyone is used to having a zillion accounts for all the zillion services
> we all use.
>
> Thankfully the Kitware GitLab instance features GitHub integration, and I
use my GitHub account through it, thereby using two-factor authentication,
etc without the need for yet another account. I don't know how used to it
we are, and I appreciate it when efforts are made. Especially when not all
accounts feature two-factor authentication, enabling me to use an
authentication mechanism that does and is also shared is very nice.

I think there are good reasons why CMake, VTK, ParaView chose to use
GitLab, but that doesn't make them good reasons for all projects. I
personally prefer the experience on GitHub, even though I know it is closed
source and would rather use something open. I also know it is git, and
moving is far easier than it once was. There are a number of third-party
integrations that are very nice (some appear for GitLab too, but often
lagging/less of them).

GitLab from inside and outside doesn't feel as fast, and a non-scientific
test from inside Kitware showed a pause with spinny wheel to view a diff on
a small VTK patch, a larger patch for another project showed instantly when
I clicked on it. Both interfaces use usable, but I have long felt GitLab is
slower and have heard others say the same. The addition of sites that are
deployed to hosting with SSL and CDN is pretty nice for repositories that
want to do that.

I think different projects are going to choose different solutions, and
hope that we can encourage a small number of different solutions but enable
exploration of the optimal fit. The chances are the landscape will look
different in five years time too, and it may be time to reevaluate. I am
not trying to advocate either way for ITK as I rarely contribute patches,
but I am more likely to participate even in more superficial ways on
patches if it is on a platform I use daily.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/community/attachments/20170802/1044dfa3/attachment-0001.html>
-------------- next part --------------
_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html

Kitware offers ITK Training Courses, for more information visit:
http://kitware.com/products/protraining.php

Please keep messages on-topic and check the ITK FAQ at:
http://www.itk.org/Wiki/ITK_FAQ

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/insight-developers