[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-devel
Subject: Re: Gitlab Evaluation & Migration
From: Gleb Popov <6yearold () gmail ! com>
Date: 2019-02-23 10:03:17
Message-ID: CALH631=RVct+gE93EwrGhkyyLNJQw-9c_b6=djpN3ntCnteBEw () mail ! gmail ! com
[Download RAW message or body]
On Sat, Feb 23, 2019 at 1:44 PM Ben Cooksley <bcooksley@kde.org> wrote:
> Hi all,
>
> Over the past few months a small group of KDE projects have been
> evaluating Gitlab as a replacement for Phabricator, and we've now
> reached the point where we're ready to have a community wide
> discussion regarding whether we'd 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/
>
> 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.
>
> Based on the feedback we've 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.
>
> 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
>
> Further notes on the evaluation can be found at
> https://notes.kde.org/p/gitlab-evaluation-notes
>
> 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.
My own experience agrees with this statement. I've got an impression that
Phabricator devs completely not interested in bug reports coming from users
with a pact (a term for paid support used by Phacility).
So, I'm all for moving from Phabricator and that PHP-based CLI.
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).
>
> 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:
>
> 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.
>
> 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.
>
> Based on all of the above we'd like to propose migrating towards
> Gitlab. Comments?
>
> Thanks,
> Ben Cooksley
> KDE Sysadmin
>
[Attachment #3 (text/html)]
<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" \
class="gmail_attr">On Sat, Feb 23, 2019 at 1:44 PM Ben Cooksley <<a \
href="mailto:bcooksley@kde.org">bcooksley@kde.org</a>> wrote:<br></div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex">Hi all,<br> <br>
Over the past few months a small group of KDE projects have been<br>
evaluating Gitlab as a replacement for Phabricator, and we've now<br>
reached the point where we're ready to have a community wide<br>
discussion regarding whether we'd like to migrate to Gitlab. We'd like<br>
to start this by thanking those projects that have assisted in<br>
evaluating Gitlab for KDE, at list of which can be found at<br>
<a href="https://invent.kde.org/kde/" rel="noreferrer" \
target="_blank">https://invent.kde.org/kde/</a><br> <br>
This evaluation process was started in response to feedback Sysadmin<br>
received in the BoF session in Akademy last year regarding issues<br>
developers we're having with Phabricator. These included the ability<br>
to see the submitters details (name and email address), ability to do<br>
multi-commit reviews and to merge changes conveniently from the web<br>
amongst other things.<br>
<br>
Based on the feedback we've received to date regarding the Gitlab<br>
evaluation, the consensus seems to be that a migration would be<br>
beneficial and helpful to us in the long term.<br>
<br>
Among the benefits identified thus far are:<br>
1) Provision of full featured task management and code review<br>
functionality to scratch (personal) repositories, which will ease the<br>
transition to playground and first release.<br>
2) Ability to handle native Git commits as part of the code review<br>
process and merge commits from the web interface rather than having to<br>
take additional steps to integrate a change.<br>
3) Easier and more logical grouping of projects, including being able<br>
to view the tasks and repositories related to a specific project more<br>
intuitively<br>
<br>
Further notes on the evaluation can be found at<br>
<a href="https://notes.kde.org/p/gitlab-evaluation-notes" rel="noreferrer" \
target="_blank">https://notes.kde.org/p/gitlab-evaluation-notes</a><br> <br>
In regards to Phabricator it should be noted that upstream does not<br>
currently have plans to work on features which would resolve the<br>
issues we've encountered, and their responsiveness to inquiries from<br>
us has decreased since we migrated to it several years ago. \
</blockquote><div><br></div><div>My own experience agrees with this statement. \
I've got an impression that</div><div>Phabricator devs completely not interested \
in bug reports coming from users</div><div>with a pact (a term for paid support used \
by Phacility).</div><div><br></div><div>So, I'm all for moving from Phabricator \
and that PHP-based CLI.<br></div><div><br></div><blockquote class="gmail_quote" \
style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex">Gitlab on<br> the other hand has a thriving \
community which openly accepts patches<br> and have been very helpful in assisting us \
with the evaluation process<br> (including solving problems we've found).<br>
<br>
In addition to sysadmins and some of projects maintainers, KDE e.V.<br>
board, and onboarding goal team has been involved in Gitlab evaluation<br>
process as well, and they've made the following comments:<br>
<br>
Neofytos Kolokotronis of the Onboarding goal team:<br>
We believe this switch will be a great step forward for the Onboarding<br>
goal as well. The workflow, features and general behavior of Gitlab<br>
should be much more familiar to developers and non-coders interested<br>
to contribute to KDE, thus lowering the entry barrier. Further,<br>
people coming from FOSS projects already on Github or Gitlab should<br>
find it very straightforward to start contributing to KDE right away.<br>
One area that is not to be ignored is that Gitlab has some great and<br>
up to date documentation.<br>
<br>
Eike Hein on behalf of the KDE e.V. board of directors:<br>
After sysadmin gave us a situation report on our code hosting and<br>
review infrastructure last year, we were initially involved with<br>
building a relationship with GitLab upstream and setting up a call<br>
schedule. We then turned the evaluation over to the sysadmin and<br>
onboarding teams and received continual updates on its progress. We're<br>
impressed by and thankful for the work done by everyone involved in<br>
the intervening months, and stand by to help implement a community<br>
decision based on what was collected.<br>
<br>
Based on all of the above we'd like to propose migrating towards<br>
Gitlab. Comments?<br>
<br>
Thanks,<br>
Ben Cooksley<br>
KDE Sysadmin<br>
</blockquote></div></div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic