From kde-devel  Wed Feb 27 22:34:03 2019
From: Nicolas Fella <nicolas.fella () gmx ! de>
Date: Wed, 27 Feb 2019 22:34:03 +0000
To: kde-devel
Subject: Re: Gitlab Evaluation & Migration
Message-Id: <3965586.TI9XcbhIVI () hermione>
X-MARC-Message: https://marc.info/?l=kde-devel&m=155130686500586

Hey,

I've been part of the evaluation with KDE Connect. My experience has been=20
mostly good with a small exception: I personally prefer the push-to-branch=
=20
model over the fork model, but when trying it with KDE Connect pushing to a=
=20
branch created IRC commit notifications which caused a lot of noise in the=
=20
channel. Disabling commit notifications for branches other than master and=
=20
stable would solve that. Other than that I had no issues that were not alre=
ady=20
mentioned.

+1 from me.

Cheers

Nico

On Samstag, 23. Februar 2019 10:44:11 CET Ben Cooksley wrote:
> Hi all,
>=20
> Over the past few months a small group of KDE projects have been
> evaluating Gitlab as a replacement for Phabricator, and we=E2=80=99ve now
> reached the point where we=E2=80=99re ready to have a community wide
> discussion regarding whether we=E2=80=99d like to migrate to Gitlab. We'd=
 like
> to start this by thanking those projects that have assisted in
> evaluating Gitlab for KDE, at list of which can be found at
> https://invent.kde.org/kde/
>=20
> This evaluation process was started in response to feedback Sysadmin
> received in the BoF session in Akademy last year regarding issues
> developers we're having with Phabricator. These included the ability
> to see the submitters details (name and email address), ability to do
> multi-commit reviews and to merge changes conveniently from the web
> amongst other things.
>=20
> Based on the feedback we=E2=80=99ve received to date regarding the Gitlab
> evaluation, the consensus seems to be that a migration would be
> beneficial and helpful to us in the long term.
>=20
> Among the benefits identified thus far are:
> 1) Provision of full featured task management and code review
> functionality to scratch (personal) repositories, which will ease the
> transition to playground and first release.
> 2) Ability to handle native Git commits as part of the code review
> process and merge commits from the web interface rather than having to
> take additional steps to integrate a change.
> 3) Easier and more logical grouping of projects, including being able
> to view the tasks and repositories related to a specific project more
> intuitively
>=20
> Further notes on the evaluation can be found at
> https://notes.kde.org/p/gitlab-evaluation-notes
>=20
> In regards to Phabricator it should be noted that upstream does not
> currently have plans to work on features which would resolve the
> issues we've encountered, and their responsiveness to inquiries from
> us has decreased since we migrated to it several years ago. Gitlab on
> the other hand has a thriving community which openly accepts patches
> and have been very helpful in assisting us with the evaluation process
> (including solving problems we've found).
>=20
> In addition to sysadmins and some of projects maintainers, KDE e.V.
> board, and onboarding goal team has been involved in Gitlab evaluation
> process as well, and they've made the following comments:
>=20
> Neofytos Kolokotronis of the Onboarding goal team:
> We believe this switch will be a great step forward for the Onboarding
> goal as well. The workflow, features and general behavior of Gitlab
> should be much more familiar to developers and non-coders interested
> to contribute to KDE, thus lowering the entry barrier.  Further,
> people coming from FOSS projects already on Github or Gitlab should
> find it very straightforward to start contributing to KDE right away.
> One area that is not to be ignored is that Gitlab has some great and
> up to date documentation.
>=20
> Eike Hein on behalf of the KDE e.V. board of directors:
> After sysadmin gave us a situation report on our code hosting and
> review infrastructure last year, we were initially involved with
> building a relationship with GitLab upstream and setting up a call
> schedule. We then turned the evaluation over to the sysadmin and
> onboarding teams and received continual updates on its progress. We're
> impressed by and thankful for the work done by everyone involved in
> the intervening months, and stand by to help implement a community
> decision based on what was collected.
>=20
> Based on all of the above we'd like to propose migrating towards
> Gitlab. Comments?
>=20
> Thanks,
> Ben Cooksley
> KDE Sysadmin