[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Gitlab Evaluation & Migration
From:       Ben Cooksley <bcooksley () kde ! org>
Date:       2019-02-23 19:08:36
Message-ID: CA+XidOF4_f73X9vFd7mEUsEwGLMRQ0dPxQpSgNVCPhpJsHvpqA () mail ! gmail ! com
[Download RAW message or body]

On Sun, Feb 24, 2019 at 7:28 AM Boudhayan Gupta <me@baloneygeek.com> wrote:
> 
> Hi Ben et. al.,
> 
> What are our plans regarding integrating with GitLab CI? I see that we have the \
> YAML files in some of the repos already, but do we plan to replace Jenkins in the \
> long run?

We've been experimenting with it, mostly at this time as a way of
providing CI on merge requests.

Our main issue at this stage is determining a way of deploying it in a
way that is maintainable (at the moment with Jenkins all builds are
conducted from a small set of central templates which makes
implementing KDE wide changes trivial, however Gitlab requires
per-repository .gitlab-ci.yaml files)

Once we've sorted that, it will definitely be brought online at the
very least to provide CI on merge requests and may quite possibly
replace build.kde.org as well.
Due to complexities and other security concerns changes to the Binary
Factory are not under consideration at this time.

> 
> Sincerely,
> Boudhayan Gupta
> 

Cheers,
Ben

> 
> On Sat, 23 Feb 2019 at 11:04, Gleb Popov <6yearold@gmail.com> wrote:
> > 
> > 
> > 
> > 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


[prev in list] [next in list] [prev in thread] [next in thread]