[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 21:47:05
Message-ID: CA+XidOFTbQVht9xq71ozeiqa_acNS00H3vUnPprjVdgmsVp9EA () mail ! gmail ! com
[Download RAW message or body]

On Sun, Feb 24, 2019 at 10:30 AM Alexander Potashev
<aspotashev@gmail.com> wrote:
>
> =D1=81=D0=B1, 23 =D1=84=D0=B5=D0=B2=D1=80. 2019 =D0=B3. =D0=B2 12:44, Ben=
 Cooksley <bcooksley@kde.org>:
> > Based on all of the above we'd like to propose migrating towards
> > Gitlab. Comments?
>
> Hi,

Hi Alexander,

>
> 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/aadd9305b0467fa39e5c84af606c7d=
9eb1568533

That commit is massive and is far beyond what would be routine for a
project to commit, so I think it's quite reasonable for the system to
take a bit of time to process it.
Loading that page right now using the web inspector shows it takes
about 8 seconds to generate, followed by a further 4 seconds to
download, which doesn't seem unreasonable for 3200 lines of changes,
plus context, over 187 files - especially given it syntax highlights
it.

> .
>
> 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.

We have relatively decent hardware available, so I don't expect that
to be an issue.

>
> 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.

It depends on the model you want to work with, as I mentioned in one
of my earlier emails regarding how merge requests would work.

Projects can choose one of two ways to do it (and even use both models
simultaneously should they wish):

1) Use branch-per-feature / review-request, with the branches being
housed in the main repository.
2) Use individual repository forks

With either model, as part of submitting the merge request you are
given the option to have the source branch removed when the merge
request is approved, which will cleanup the repository the merge
request is originated from.

>
> 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?

Other open source projects which have switched to Gitlab also allow
repositories to be created freely and they have not had to deal with
abuse problems.
I don't see why we would be any different.

>
> 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.

Because the repositories are under users own individual namespaces
this won't pollute the listing of main repositories which are what
everyone will be interested in.

>
> 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.

git@code:~$ cat projects-list/projects-to-anongit.list | wc -l
2380
git@code:~$ cat projects-list/projects-to-anongit.list | grep -v
^scratch/ | grep -v ^clones/ | wc -l
1030
git@code:~$ cat projects-list/projects-to-anongit.list | grep ^scratch/  | =
wc -l
985
git@code:~$ cat projects-list/projects-to-anongit.list | grep ^clones/  | w=
c -l
365

If we count scratch and clone repositories together, 57% of all
repositories on our systems currently are "personal" repositories, so
they're certainly not in limited use.

>
> --
> Alexander Potashev

Cheers,
Ben
[prev in list] [next in list] [prev in thread] [next in thread]