lilypond-devel
[Top][All Lists]
Advanced

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

[RFC] switch to GitLab / gitlab.com


From: Jonas Hahnfeld
Subject: [RFC] switch to GitLab / gitlab.com
Date: Wed, 05 Feb 2020 16:09:31 +0100
User-agent: Evolution 3.34.3

(Note: I wrote this in ~1 hour, so some details are not thought through
yet. I rather want this to serve as an example of a concrete proposal
to change one thing at a time.)

What this proposal is about
===========================

Right now, LilyPond's source code is hosted on Savannah [1], our issues
are tracked on SourceForge [2] and we review patches on Rietveld [3].
There is no synchronization between the systems and a contributor is
required to synchronize the review and the associated issue. I propose
to start using GitLab hosted on gitlab.com [4] for all of this:
Repository, Issues, and Merge Requests (MR) for reviews. It was
evaluated 'C' in 2015 [5] and should be an 'acceptable hosting for a
GNU package' [6].

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.

If deemed necessary, it should be possible to transfer existing issues
from SourceForge via GitLab's API. For the future, we can use exports
from GitLab [7] as backups and rely on them should we ever wish to
switch tools.

What this is NOT about
======================

I'm NOT proposing any change to the processes used right now. In
particular:
 * Review stays mandatory, but instead of Rietveld you push to a branch
(or a fork if you like) and open a MR.
 * The Patch meister keeps on testing (manually for now; CI could be a
future step) and posts the results in the MR.
 * We still have countdowns, but instead of SourceForge we use labels
in GitLab to track the status.
 * After countdown, commits are pushed to staging; patchy-staging
transfers them to master.

Alternatives considered
=======================

One option would be self-hosting GitLab and not using gitlab.com. This
comes with the disadvantage that somebody has to maintain the server.
From my personal experience, this takes a large amount of time and
dedication because GitLab is very complex to update.

 * GNU Savannah: could handle issues, but no reviews
 * GitHub: bought by Microsoft and proprietary, rated F /
'Unacceptable' [6]
 * Gitea: only self-hosted as far as I know, still relatively new
 * Gerrit: only a review tool, so issues and source code hosting need
additional tools

Closing thoughts
================

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.

Links
=====
1: https://git.savannah.gnu.org/cgit/lilypond.git/
2: https://sourceforge.net/p/testlilyissues/issues/
3: https://codereview.appspot.com/
4: https://gitlab.com/explore
5: https://www.gnu.org/software/repo-criteria-evaluation.html
6: https://www.gnu.org/software/repo-criteria.html
7: https://docs.gitlab.com/ee/user/project/settings/import_export.html
8: https://docs.gitlab.com/ee/user/project/repository/repository_mirroring.html

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


reply via email to

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