сб, 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, 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
