[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-28 17:42:57
Message-ID: CA+XidOE0UJVYd+5epXA1VXaqrLHVRaPJs4i421LBHRyEi1+=jA () mail ! gmail ! com
[Download RAW message or body]

On Fri, Mar 1, 2019 at 3:13 AM Nate Graham <nate@kde.org> wrote:
>
>  ---- On Wed, 27 Feb 2019 23:02:03 -0700 Ben Cooksley <bcooksley@kde.org>=
 wrote ----
>  > In terms of server load, it would be nice if the setup of forks was
>  > still something the developer had to initiate rather than being done
>  > automatically for every repository touched by kdesrc-build (I say this
>  > mainly as if we had 50 people fork just half of the mainline
>  > repositories we have, that's ~450GB of space used up - a massive
>  > scalability issue)
>
> This seems like a challenge that needs to be addressed regardless of whet=
her or not kdesrc-build does it automatically, because people creating tons=
 and tons of forks is guaranteed to happen anyway if we move to Gitlab. It =
seems non-optimal if having more people able to submit merge requests resul=
ts in the potential to blow up our servers.

We have a little over 1,000 mainline repositories, so in the above
example we'd be talking about 25,000 forks being created - and i'd be
expecting quite a bit more than 50 people to use kdesrc-build. To use
another scenario, if the metric of half the repositories being
involved (or even a quarter) held true with say 300 users, you're now
looking at 75,000 - 150,000 forked repositories (and probably around
1.4TB - 2.7TB of space used) courtesy of an automated tool.

It would take quite a while for us to reach 150,000 forked
repositories on Gitlab if humans were to be creating these manually,
however if an automated tool is going to be creating them as part of
it's workflow, then we will hit it much more quickly (and is a
phenomenal waste of resources given virtually all of those forks will
never be utilised)

I certainly do expect a number of forks to be created yes, but i'd
rather they be useful forks where someone at least intends on working
on something, rather than ones created automatically by software "just
in case" someone decides to work on a project.

>
> Nate
>

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