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

[Jonas Hahnfeld]

Am Donnerstag, den 06.02.2020, 21:34 -0600 schrieb Karlin High:
> 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.

re "single-patch commits": Firstly we currently push multiple commits
from one review (at least Dan and I do), so I don't fully understand
the point. Additionally I'm not (yet) proposing to use MRs to actually
merge the change, that still happens via staging -> master. I only
propose that we use the UI to review the patches, instead of Rietveld.

> 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.

Fully aligns with my opinion, see the "Alternatives" section of the
proposal.

> > 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
> >

As said GitLab also offers an API, so I'm pretty confident that we
could adapt the mentioned scripts (btw there are many more out there,
doing more or less sophisticated things).

> 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.

Do we need to import from Rietveld? The current issues have links to
the reviews, I think we should just get as much out of SF as possible
and keep the references to the external system.

> > 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.

I first want to gather consensus that GitLab is really a platform that
(at least) a large part of the community could agree on, for the scoped
purpose of replacing the three tools we currently use.

> (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.)

Jonas

signature.asc
Description: This is a digitally signed message part