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