On Wed, Feb 5, 2020 at 9:09 AM Jonas Hahnfeld <[email protected]> wrote: > I propose > to start using GitLab hosted on gitlab.com [4] for all of this: > Repository, Issues, and Merge Requests (MR) for reviews.
A thread in 2018 explored GitLab's feasibility for LilyPond. <https://lists.gnu.org/archive/html/lilypond-devel/2018-04/msg00014.html> Some points made in that discussion was that SourceForge Allura's issue status tracking features should be equaled or exceeded by any new system, that single-patch commits are likely preferred to branch-merge commits, and that ideally the comments for issue-based discussion could be separated from code-review discussion. Looking at GitLab's features, their "labels" for status tracking, single-checkbox "squash merge" setting (can be set by patch submitter or the person accepting it) and "resolvable discussions" would at least have a chance of meeting those expectations. > Using the managed installation on gitlab.com has the advantage that we > don't need to maintain it. Also future contributors might already have > an account and can start submitting MRs as they are used to. It should > make bug reporting more straight-forward too, with the issues right > next to the repository. As I recall, hosted GitLab's top-end Gold service, $99 USD per user per month, is the default for public repositories. At no charge; they're catering to Open Source projects with that. If a repository is set to Private, the GitLab price list enters the picture and advanced features go away until they get some money. To me, that all seems perfectly sensible. I'm not sure what benefits a self-hosted GitLab would bring that justify the resources it would need. > If deemed necessary, it should be possible to transfer existing issues > from SourceForge via GitLab's API. Importing as much SourceForge Allura and Rietveld content as possible would aid future understanding of coding decisions. It looks like there are Allura import methods available, even if by way of SourceForge -> GitHub -> GitLab. <https://github.com/cmungall/gosf2github> <https://docs.gitlab.com/ee/administration/raketasks/github_import.html> Rietveld export, I'm not sure about. The only thing I could see would be scraping the site for Issues that have a CC of lilypond-devel_gnu.org, unless there are export features I've missed. > GitLab has a feature called 'Repository mirroring' [8], working in both > directions. During the switching period, we could maintain Savannah as > our main repository and let GitLab pull in changes from there. After a > final cut, GitLab could instead be configured to push master and > stable/* branches to Savannah. This would effectively have GitLab be the "staging" branch, then. GNU Savannah could still be "master." One possible next step: import to GitLab a LilyPond Git repository, some SourceForge, and some Rietveld content so people can try it out and see if it's something acceptable and workable. Unfortunately, as a tax preparer it's the wrong time of the year for me to help very much. (CC to Kevin Barry, who mentioned GitLab experience in a separate thread. My info here is more based on research than experience, so please call out any misunderstandings I have.) -- Karlin High Missouri, USA
