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

List:       kde-devel
Subject:    Re: Gitlab Evaluation & Migration
From:       Alexander Potashev <aspotashev () gmail ! com>
Date:       2019-02-23 21:30:25
Message-ID: CADMG6+-OpA78RVHTxPnLuo+OqmfeecUE77ZxjEw0bfrPBNxMpA () mail ! gmail ! com
[Download RAW message or body]

сб, 23 февр. 2019 г. в 12:44, Ben Cooksley <bcooksley@kde.org>:
> Based on all of the above we'd like to propose migrating towards
> Gitlab. Comments?

Hi,

1. We migrated from github.com to self-hosted GitLab when I worked
full-time in a team of 4 developers. A major drawback we noticed back
then was slow page loading when browsing a large diff (e.g. in a merge
request). For example, this commit takes around 15 seconds to load:
https://invent.kde.org/kde/kdenlive/commit/aadd9305b0467fa39e5c84af606c7d9eb1568533
.

We had load times of over 30 seconds for a real-world merge request in
a proprietary project of our team, however it depends on the
server-side hardware.

2. My other concern is the risk of uncontrolled creation of new
branches because with GitLab they are created in the central repo for
every new patch/feature. A repo may end up with dozens of branches of
unclear status.

The branch-per-feature approach works well for a small team of
full-time developers since you can easily ask your colleagues "OK to
delete this branch?" at any time and keep the repo as clean as you
want. For >1000 people having write access (and who may become
unavailable without notice), the same won't work.

3. Also, after moving to self-hosted GitLab, KDE's Git hosting will
get the same familiar look and feel like
github.com/gitlab.com/bitbucket, which may encourage random people to
use it for anything (and their photo archives and more). Do we have
the same infrastructure and administrative resources like GitHub has
to overcome spam/abuse?

Even a fair user may create scratch repo/branch and forget about it,
thousands of such users may easily turn our Git hosting into a
landfill.

I know we had scratch repos before, but the steps to create them
weren't as well-known and accessible as with GitLab. I believe, this
is why we only have a limited number of scratch repos as of today.

-- 
Alexander Potashev
[prev in list] [next in list] [prev in thread] [next in thread]