lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC] switch to GitLab / gitlab.com


From: Karlin High
Subject: Re: [RFC] switch to GitLab / gitlab.com
Date: Thu, 6 Feb 2020 21:34:51 -0600

On Wed, Feb 5, 2020 at 9:09 AM Jonas Hahnfeld <address@hidden> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]