[RFC] switch to GitLab / gitlab.com

classic Classic list List threaded Threaded
37 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[RFC] switch to GitLab / gitlab.com

Jonas Hahnfeld
(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

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

David Kastrup
Jonas Hahnfeld <[hidden email]> writes:

[Not repeating well-thought considerations]

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

It's worth stating that the large migration hurdle is actually saving as
much from tracker/review setup we have as possible.  Switching Git
repositories, in comparison, is a rather small hurdle.  We need to get
our ducks in a row regard the contributor documentation and scripts, but
otherwise that part is rather simple (famous last words).

--
David Kastrup

Reply | Threaded
Open this post in threaded view
|

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

Dan Eble
In reply to this post by Jonas Hahnfeld
On Feb 5, 2020, at 10:09, Jonas Hahnfeld <[hidden email]> wrote:
>
> 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].

Fine with me.  I don't expect to donate my time to make _any_ move happen, but I'd accept working with these tools to get my patches into LilyPond.  It could hardly be worse than the current combination.

Dan


Reply | Threaded
Open this post in threaded view
|

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

pkx166h-4
On 05/02/2020 16:13, Dan Eble wrote:

> On Feb 5, 2020, at 10:09, Jonas Hahnfeld <[hidden email]> wrote:
>> 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].
> Fine with me.  I don't expect to donate my time to make _any_ move happen, but I'd accept working with these tools to get my patches into LilyPond.  It could hardly be worse than the current combination.
> —
> Dan
>
>
Let's assume this all 'comes to pass' what is, or how will, the
transition of what I do now be expected to happen?

How much (if anything) will I still need or be expected to do?

These are rhetorical for now but will need consideration.

You will need suppose a testing phase and then a cut-off point from the
current patch review process.

(N.B. I really don't mind if the answer is that I'll be required no more
and I am out of a 'job' so to speak, I am not looking for empathy, all
that I am concerned with is that we don't end up with different
developers/patches working in two systems in parallel (if you see what I
mean), and that at the end of it all we still have the ability for
'drive-by-patches' from developers or contributors whom today, just like
to send in git-formatted patches).

James



Reply | Threaded
Open this post in threaded view
|

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

Jonas Hahnfeld
Am Mittwoch, den 05.02.2020, 21:02 +0000 schrieb [hidden email]:

> On 05/02/2020 16:13, Dan Eble wrote:
> > On Feb 5, 2020, at 10:09, Jonas Hahnfeld <
> > [hidden email]
> > > wrote:
> > > 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].
> >
> > Fine with me.  I don't expect to donate my time to make _any_ move happen, but I'd accept working with these tools to get my patches into LilyPond.  It could hardly be worse than the current combination.
> > —
> > Dan
> >
> >
>
> Let's assume this all 'comes to pass' what is, or how will, the
> transition of what I do now be expected to happen?
>
> How much (if anything) will I still need or be expected to do?
As explained in my original message, I'm not proposing changes to the
process. So for you as the Patch meister I would be "business as
usual", just with a different tool.

> These are rhetorical for now but will need consideration.
>
> You will need suppose a testing phase and then a cut-off point from the
> current patch review process.

I don't have a plan for this yet, this is merely a proposal to break
out from the cycle of complaining and instead discuss changes step by
step. But if we decide to pursue this direction, ultimately I guess
you're right, some cut-off needs to happen...

> (N.B. I really don't mind if the answer is that I'll be required no more
> and I am out of a 'job' so to speak, I am not looking for empathy, all
> that I am concerned with is that we don't end up with different
> developers/patches working in two systems in parallel (if you see what I
> mean), and that at the end of it all we still have the ability for
> 'drive-by-patches' from developers or contributors whom today, just like
> to send in git-formatted patches).

No, my hope is that you would be willing to continue your 'job',
basically implementing the process on top of the new tool. It will
certainly require some changes in the details (like using labels), but
from a high level it's hopefully the same.
In the future, we might (re-)introduce some automation to test changes
automatically. This would still leave checking the regtests and the
countdown cycle for a human, unless we also change that. But that's out
of scope, at least for me, right now.

Does this answer your questions?
Jonas

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Karlin High
In reply to this post by Jonas Hahnfeld
On Wed, Feb 5, 2020 at 9:09 AM Jonas Hahnfeld <[hidden email]> 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 | Threaded
Open this post in threaded view
|

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 <
> [hidden email]
> > 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 (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Karlin High
On 2/7/2020 1:59 AM, Jonas Hahnfeld wrote:
> 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.

I probably didn't relate the discussion properly. It had to do with
commits vs branch merges. This post raises the question:

<https://lists.gnu.org/archive/html/lilypond-devel/2018-04/msg00023.html>

And these seemed like GitLab's answer to it:

<https://docs.gitlab.com/ee/user/project/merge_requests/squash_and_merge.html>

<https://docs.gitlab.com/ee/user/project/merge_requests/fast_forward_merge.html>

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

I think you're right.

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

Very good. Does anyone know of reasons why GitLab would NOT be a good
fit for Lilypond? I won't know them due to lack of experience, and don't
feel I have anything further to say here.
--
Karlin High
Missouri, USA

Reply | Threaded
Open this post in threaded view
|

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

Jonas Hahnfeld
Am Freitag, den 07.02.2020, 02:30 -0600 schrieb Karlin High:

> On 2/7/2020 1:59 AM, Jonas Hahnfeld wrote:
> > 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.
>
> I probably didn't relate the discussion properly. It had to do with
> commits vs branch merges. This post raises the question:
>
> <
> https://lists.gnu.org/archive/html/lilypond-devel/2018-04/msg00023.html
> >
>
> And these seemed like GitLab's answer to it:
>
> <
> https://docs.gitlab.com/ee/user/project/merge_requests/squash_and_merge.html
> >
>
> <
> https://docs.gitlab.com/ee/user/project/merge_requests/fast_forward_merge.html
> >
You removed the important part with my answer:
> 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.

Jonas

>
> > 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.
>
> I think you're right.
>
> > 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.
>
> Very good. Does anyone know of reasons why GitLab would NOT be a good
> fit for Lilypond? I won't know them due to lack of experience, and don't
> feel I have anything further to say here.
>

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Karlin High
On 2/7/2020 2:36 AM, Jonas Hahnfeld wrote:
> You removed the important part with my answer:
>> 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.

Apologies. I will be more careful with quote trimming.
--
Karlin High
Missouri, USA

Reply | Threaded
Open this post in threaded view
|

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

Kevin Barry
In reply to this post by Karlin High
> (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.)

Thank you for the CC. I have read through the messages, and the previous
discussion from 2018.

My two cents are:
- I think if we want to integrate issue tracking, code review, and source code
  hosting in one place, then Gitlab is the best option
- I do not have the experience of working with SF/Allura, Rietveld, and
  Savannah to get code into LilyPond, but, judging from appearances, the
  flow for contributions will be smoother for existing developers and less
  off-putting for new or occasional developers (I think, outside projects like
  the Linux kernel, drive-by pull/merge requests are more common than drive-
  by patches)
- I agree that using gitlab.com is better than self-hosting, but
depending on the
  technical challenges involved it may be necessary to host a dedicated Gitlab
  runner (i.e. a server for doing CI/CD builds/tests).
- I think it's possible James Lowe's workflow might be be different
under Gitlab.
  Re the concerns he raised in the old thread, I believe he would be able to
  mostly replicate what he does now with labels (and sorting by priority label).
  (I can see that this flow, including the "countdown" is under discussion
  elsewhere.)
- I don't know who tests that every patch successfully builds and passes basic
  tests, but in my experience, having Gitlab do that for me every time someone
  opens a merge request (on one of my own projects at work) has been a
  godsend (before that, I had to do it myself every time).

> 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.
I think this is a good approach. Gitlab allows, for example, to have a number of
protected branches (master + staging), and to default merge requests to any one.
You can also set it to do different CI/CD on a branch by branch basis
(for example
you may want to run more stringent or longer tests on the staging branch than on
others).

Reply | Threaded
Open this post in threaded view
|

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

Federico Bruni-2
In reply to this post by Jonas Hahnfeld
Il giorno ven 7 feb 2020 alle 08:59, Jonas Hahnfeld <[hidden email]>
ha scritto:
> 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.

I'm totally in favour of GitLab, hosted on gitlab.com.
It would be good to get the opinions of current developers in this
thread.

I guess that the quality of the issue migration might influence the
decision. (I remember I did a migration test from Google Code to Github
years ago, but issue numbers were not retained and this was considered
a blocker IIRC)
Hence I suggest to test a migration and see how it goes.

I've asked privately to Trevor to get the privileges to see the Admin
tab in SF, in order to get the .json file to import issues in
gitlab.com.
I would do it in my Gitlab account just for test.

Maybe later we can use an organization account to test this in team.
I think this was managed by Janek:
<https://gitlab.com/groups/lilypond/-/group_members>


Reply | Threaded
Open this post in threaded view
|

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

Urs Liska-3
In reply to this post by Kevin Barry


Am 7. Februar 2020 09:48:30 MEZ schrieb Kevin Barry <[hidden email]>:

>> (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.)
>
>Thank you for the CC. I have read through the messages, and the
>previous
>discussion from 2018.
>
>My two cents are:
>- I think if we want to integrate issue tracking, code review, and
>source code
>  hosting in one place, then Gitlab is the best option
>- I do not have the experience of working with SF/Allura, Rietveld, and
> Savannah to get code into LilyPond, but, judging from appearances, the
>flow for contributions will be smoother for existing developers and
>less
>off-putting for new or occasional developers (I think, outside projects
>like
>the Linux kernel, drive-by pull/merge requests are more common than
>drive-
>  by patches)
>- I agree that using gitlab.com is better than self-hosting, but
>depending on the
>technical challenges involved it may be necessary to host a dedicated
>Gitlab
>  runner (i.e. a server for doing CI/CD builds/tests).
>- I think it's possible James Lowe's workflow might be be different
>under Gitlab.
>Re the concerns he raised in the old thread, I believe he would be able
>to
>mostly replicate what he does now with labels (and sorting by priority
>label).
>(I can see that this flow, including the "countdown" is under
>discussion
>  elsewhere.)
>- I don't know who tests that every patch successfully builds and
>passes basic
>tests, but in my experience, having Gitlab do that for me every time
>someone
>  opens a merge request (on one of my own projects at work) has been a
>  godsend (before that, I had to do it myself every time).

To add: tests are also triggered when additional commits are pushed to an open MT.


>
>> 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.
>I think this is a good approach. Gitlab allows, for example, to have a
>number of
>protected branches (master + staging), and to default merge requests to
>any one.
>You can also set it to do different CI/CD on a branch by branch basis
>(for example
>you may want to run more stringent or longer tests on the staging
>branch than on
>others).

I think this is an extremely good point. Being able to squash upon merge, with or without merge commit, in combination with being able to automate that as a staging branch with final test, seems a very good idea to me.

This integration of tools can be handled completely independently from any policies about the review process or countdown etc.

To recap at this point: the worry about gitlab.com is similar to that wrt guthub: their TOS won't give us a substantial amount of trust in continuity of service.

Urs
--
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

Reply | Threaded
Open this post in threaded view
|

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

Federico Bruni-2
Il giorno ven 7 feb 2020 alle 10:36, Urs Liska <[hidden email]>
ha scritto:
> To recap at this point: the worry about gitlab.com is similar to that
> wrt guthub: their TOS won't give us a substantial amount of trust in
> continuity of service.

It's always been this situation unfortunately (see Google Code
shutdown). And I haven't checked SourceForge ToS...
If this worry is a blocker, we'll never change tools, which is worse.

But choosing GitLab gives me some confidence because it's widely used
(Debian, GNOME). Unfortunately I don't think these two projects can
host LilyPond.
GNOME Gitlab has a World group, but it's for unofficial software *using
GNOME technologies*... perhaps if we turn LilyPad into a Gtk app we can
sneak into? ^_^


Reply | Threaded
Open this post in threaded view
|

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

Jonas Hahnfeld
In reply to this post by Urs Liska-3
Am Freitag, den 07.02.2020, 10:36 +0100 schrieb Urs Liska:
> I think this is an extremely good point. Being able to squash upon merge, with or without merge commit, in combination with being able to automate that as a staging branch with final test, seems a very good idea to me.

Possibly in the future, but not under the proposal that I wrote.

> This integration of tools can be handled completely independently from any policies about the review process or countdown etc.
>
> To recap at this point: the worry about gitlab.com is similar to that wrt guthub: their TOS won't give us a substantial amount of trust in continuity of service.

True, but there is an important difference: GitLab (at least the
community edition) is fully open-source. So if we take periodic backups
(ie exports) we can do two things should the need arise:
1) Setup our own GitLab (and be it only until migration to another
platform is complete)
2) Extract the needed data from the export, as we already have it
exported from gitlab.com

Jonas

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

David Kastrup
In reply to this post by Karlin High
Karlin High <[hidden email]> writes:

> On 2/7/2020 1:59 AM, Jonas Hahnfeld wrote:
>> 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.
>
> I probably didn't relate the discussion properly. It had to do with
> commits vs branch merges. This post raises the question:
>
> <https://lists.gnu.org/archive/html/lilypond-devel/2018-04/msg00023.html>
>
> And these seemed like GitLab's answer to it:
>
> <https://docs.gitlab.com/ee/user/project/merge_requests/squash_and_merge.html>
>
> <https://docs.gitlab.com/ee/user/project/merge_requests/fast_forward_merge.html>
>
>> 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.
>
> I think you're right.
>
>> 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.
>
> Very good. Does anyone know of reasons why GitLab would NOT be a good
> fit for Lilypond? I won't know them due to lack of experience, and
> don't feel I have anything further to say here.

I am currently reading up on its corporate history and structure.  What
I find encouraging in this regard is that they have a lot of corporate
customers and significant earnings in comparison with their market
valuation.  That makes a "looking for buyout" scenario less likely, a
scenario that has significant odds of us landing in an environment one
did not originally anticipate (note that the last corporate owner
changes to SourceForge actually were beneficial with regard to our own
situation, but that is an exception more than the rule).

There have been numerous ostensibly free services expanding a lot with
VC money that ended up getting bought out when they achieved a strategic
importance without a clearcut income perspective in proportion to their
valuation.  GitHub, now owned by Microsoft, comes to mind, as well as
projects like Gitorious that were just bought up (by GitLab, actually)
and retired.  Google is one company that managed to pivot from being a
free service without a clearcut business model to a market leader in,
uh, whatever?

What really puzzles me right now reading up on GitLab history that in
2017 they acquired Gitter.  Gitter is an instant messaging service for
_GitHub_ (yes, that is correct) users requiring maximum permissions and
having pervasive logging.  That seems to only make business sense in the
data gathering business, for internal or external use.

Sorry, this is all not much more than banter right now.  Basically I
don't see any obvious red flags.

--
David Kastrup

Reply | Threaded
Open this post in threaded view
|

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

David Kastrup
In reply to this post by Urs Liska-3
Urs Liska <[hidden email]> writes:

> To recap at this point: the worry about gitlab.com is similar to that
> wrt guthub: their TOS won't give us a substantial amount of trust in
> continuity of service.

The seminal difference being that a workable free version of their
software is available for the purpose of self-hosting.  That gives an
escape hatch that either users or competing services can pick up in the
case of contingency.

This may seem academical, but even the academical possibility reins in
corporate decision makers from performing wholesale changes on a whim.

--
David Kastrup

Reply | Threaded
Open this post in threaded view
|

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

Federico Bruni-2
In reply to this post by Federico Bruni-2
Il giorno ven 7 feb 2020 alle 10:33, Federico Bruni
<[hidden email]> ha scritto:
> I guess that the quality of the issue migration might influence the
> decision.

I forgot I already investigated the SF -> GitLab migration almost 2
years ago:
http://lilypond.1069038.n5.nabble.com/Allura-SourceForge-to-Gitlab-migration-td211549.html

Unfortunately, no progress on the import from Allura:
https://gitlab.com/gitlab-org/gitlab/issues/21747

So a migration script needs to be written.
I've uploaded today's dump of SF issues here (165MB):
https://drive.google.com/open?id=1llmnlKMt-LyhWHGcbSCSdSSKjsT0mTff

in case someone wants to play with it...




Reply | Threaded
Open this post in threaded view
|

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

Jonas Hahnfeld
Am Freitag, den 07.02.2020, 16:28 +0100 schrieb Federico Bruni:

> Il giorno ven 7 feb 2020 alle 10:33, Federico Bruni
> <
> [hidden email]
> > ha scritto:
> > I guess that the quality of the issue migration might influence the
> > decision.
>
> I forgot I already investigated the SF -> GitLab migration almost 2
> years ago:
> http://lilypond.1069038.n5.nabble.com/Allura-SourceForge-to-Gitlab-migration-td211549.html
>
>
> Unfortunately, no progress on the import from Allura:
> https://gitlab.com/gitlab-org/gitlab/issues/21747
>
>
> So a migration script needs to be written.
> I've uploaded today's dump of SF issues here (165MB):
> https://drive.google.com/open?id=1llmnlKMt-LyhWHGcbSCSdSSKjsT0mTff
>
>
> in case someone wants to play with it...
Thanks for sharing! I put together a simplistic script to create a
proof-of-concept: https://gitlab.com/lilypond-issues/lilypond/issues

It's only 1137 issues (now my server is blacklisted for spamming...),
but it has some important features mentioned so far:
 * It preserves the issue numbers, and additionally has a link to SF.
 * It migrates the current description and all comments.
 * It copies the attachments and adds links / previews.
 * Status, Type, and Priority are migrated as labels.
 * The migrated issue is closed when it was closed on SF.

Obviously I can't post in other person's names, so it has "Originally
reported / posted by" lines at the beginning of every issue and comment
(unless it had already been migrated from Google Code). Another
shortcoming is that I could not reproduce the threaded structure on SF,
so all comments are sorted chronologically.

Please all take a look and let me know what you think!
Jonas

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

David Kastrup
Jonas Hahnfeld <[hidden email]> writes:

> Am Freitag, den 07.02.2020, 16:28 +0100 schrieb Federico Bruni:
>> Il giorno ven 7 feb 2020 alle 10:33, Federico Bruni
>> <
>> [hidden email]
>> > ha scritto:
>> > I guess that the quality of the issue migration might influence the
>> > decision.
>>
>> I forgot I already investigated the SF -> GitLab migration almost 2
>> years ago:
>> http://lilypond.1069038.n5.nabble.com/Allura-SourceForge-to-Gitlab-migration-td211549.html
>>
>>
>> Unfortunately, no progress on the import from Allura:
>> https://gitlab.com/gitlab-org/gitlab/issues/21747
>>
>>
>> So a migration script needs to be written.
>> I've uploaded today's dump of SF issues here (165MB):
>> https://drive.google.com/open?id=1llmnlKMt-LyhWHGcbSCSdSSKjsT0mTff
>>
>>
>> in case someone wants to play with it...
>
> Thanks for sharing! I put together a simplistic script to create a
> proof-of-concept: https://gitlab.com/lilypond-issues/lilypond/issues
>
> It's only 1137 issues (now my server is blacklisted for spamming...),
> but it has some important features mentioned so far:
>  * It preserves the issue numbers, and additionally has a link to SF.
>  * It migrates the current description and all comments.
>  * It copies the attachments and adds links / previews.
>  * Status, Type, and Priority are migrated as labels.
>  * The migrated issue is closed when it was closed on SF.
>
> Obviously I can't post in other person's names, so it has "Originally
> reported / posted by" lines at the beginning of every issue and comment
> (unless it had already been migrated from Google Code). Another
> shortcoming is that I could not reproduce the threaded structure on SF,
> so all comments are sorted chronologically.
>
> Please all take a look and let me know what you think!

For a first pitch certainly impressive.  It's nice that the SHA1 ids
have become live.

--
David Kastrup
My replies have a tendency to cause friction.  To help mitigating
damage, feel free to forward problematic posts to me adding a subject
like "timeout 1d" (for a suggested timeout of 1 day) or "offensive".

12