On Sun, Feb 24, 2019 at 10:30 AM Alexander Potashev <aspotas...@gmail.com> wrote: > > сб, 23 февр. 2019 г. в 12:44, Ben Cooksley <bcooks...@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/aadd9305b0467fa39e5c84af606c7d9eb1568533 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/ | wc -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
