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

[Jonas Hahnfeld]

Am Dienstag, den 11.02.2020, 14:37 +0100 schrieb Jonas Hahnfeld:
> Am Dienstag, den 11.02.2020, 14:27 +0100 schrieb David Kastrup:
> > Jonas Hahnfeld <
> > hah...@hahnjo.de
> > 
> > > writes:
> > > Am Dienstag, den 11.02.2020, 13:48 +0100 schrieb Federico Bruni:
> > > > Il giorno mar 11 feb 2020 alle 13:18, Jonas Hahnfeld <
> > > > hah...@hahnjo.de
> > > > 
> > > > 
> > > > 
> > > > ha scritto:
> > > > > >  > Another shortcoming is that links to other issues are broken
> > > > > >  > (transformed in links to non-existing anchors in current issue).
> > > > > > 
> > > > > >  I think that is because some issues have not (yet) been migrated. I
> > > > > >  hope these links start to work once all is there.
> > > > > 
> > > > > So I eventually convinced my script to migrate close to all issues 
> > > > > [1],
> > > > > and all references to other issues that I checked so far are now
> > > > > working. Could you maybe check again and let me know if something's
> > > > > still broken? In any case I've already modified my script to first 
> > > > > sort
> > > > > the issues and not take the (random?) order from SF.
> > > > 
> > > > I still see the problem.
> > > > 
> > > > Take issue 34 as example.
> > > > All the "Issue $NUMBER" have a wrong link:
> > > > https://gitlab.com/lilypond-issues/lilypond/issues/34#note_284918285
> > > > 
> > > > 
> > > > 
> > > > https://gitlab.com/lilypond-issues/lilypond/issues/34#note_284918298
> > > > 
> > > > 
> > > > 
> > > > 
> > > > But I can see an "issue 34" link working fine:
> > > > https://gitlab.com/lilypond-issues/lilypond/issues/34#note_284918318
> > > > 
> > > > 
> > > > 
> > > > 
> > > > Perhaps your script is considering only the lower case "issue"?
> > > 
> > > Well no, I'm relying on GitLab magic here - my script attached for
> > > reference.
> > > But I think I see what's going on: When the script migrated issue #34,
> > > the referenced issues were not there yet and apparently GitLab does
> > > some evaluation when the text is posted. If I migrate the issue now
> > > (see 
> > > https://gitlab.com/lilypond-issues/lilypond/issues/5742
> > > 
> > > ), the
> > > links work - also note how "#25" in the first comment comes live.
> > > (I manually edited two comments in the original #34, so these do work
> > > now. The reference to "Issue 1302" is still broken though as I didn't
> > > touch that comment.)
> > > 
> > > Unfortunately this means that my strategy to create the issues "in
> > > order" doesn't work because comments can reference later issues that
> > > were created in the mean-time. So instead I'll try to first create all
> > > issues and then migrate all comments. That doesn't work for later edits
> > > of the issue description, but that should be the minority.
> > > I'll wait a few days for other problems before starting another
> > > attempt.
> > 
> > May I point out the tool-to-use for this task?
> > 
> > File: coreutils.info,  Node: tsort invocation,  Prev: ptx invocation,  Up: 
> > Operating on sorted files
> > 
> > 7.6 ‘tsort’: Topological sort
> > =
> > 
> > [...]
> > 
> > Now of course the non-linear manner of being able to update issues and
> > the desire to have cross-reference means that we _will_ have cycles.  So
> > this is not a cure-all, and cycles may need reediting the issues that
> > are broken by cycles.  But at least for the more linear reference
> > chains, this should be a good help.
> 
> Let me look into how many issue descriptions actually reference other
> issues. If there are none (or at least none that reference earlier
> issues), we can just be happy with the two-stage approach of migrating
> all issues first and add the comments in a second step.

Of course there are references, and sure enough some of them are
circular - see attached list. Most of them are fine if the migration
script creates the issues in order. The ones that are not:
23-Issue #636 references #498
24:Issue #650 references #651 - ERROR
25-Issue #651 references #650
26:Issue #663 references #664 - ERROR
27-Issue #664 references #663
--
105-Issue #1387 references #1365
106:Issue #1395 references #1396 - ERROR
107-Issue #1396 references #1395
--
174-Issue #2130 references #2057
175:Issue #2141 references #2142 - ERROR
176-Issue #2142 references #2141
--
242-Issue #2632 references #1773
243:Issue #2634 references #3290 - ERROR
244-Issue #2638 references #2148
--
414-Issue #3841 references #355
415:Issue #3847 references #3855 - ERROR
416-Issue #3855 references #10

So there's nothing we can do for 650/651, 663/664, 1395/1396, and
2141/2142, I would propose to just manually fix the links.
The other two are actually false positives:
#2634 references a Python bug report, and #3847 is meant to link to
issue #355.

So, no topological sorting needed as far as I can see.
Jonas
#!/usr/bin/env python3

import json
import os
import re
import sys

json_file = sys.argv[1]
with open(json_file, 'r') as f:
issues = json.load(f)

tickets = 

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

[David Kastrup]

Jonas Hahnfeld  writes:

> Am Dienstag, den 11.02.2020, 14:27 +0100 schrieb David Kastrup:
>> 7.6 ‘tsort’: Topological sort
>> =
>> 
>> [...]
>> 
>> Now of course the non-linear manner of being able to update issues and
>> the desire to have cross-reference means that we _will_ have cycles.  So
>> this is not a cure-all, and cycles may need reediting the issues that
>> are broken by cycles.  But at least for the more linear reference
>> chains, this should be a good help.
>
> Let me look into how many issue descriptions actually reference other
> issues. If there are none (or at least none that reference earlier
> issues), we can just be happy with the two-stage approach of migrating
> all issues first and add the comments in a second step.

Or migrate first omitting all links in the descriptions, and afterwards
update all descriptions with links.

One could first create all issues with a stock description, but if that
doesn't trigger spam filters I don't know what will.  So using the
original descriptions in the first pass with links removed...

Actually possibly even with links intact.  As long as one _can_ resubmit
the descriptions afterwards, there should be no problem.

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

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

[David Kastrup]

Jonas Hahnfeld  writes:

> Am Dienstag, den 11.02.2020, 14:16 +0100 schrieb David Kastrup:
>> I am not sure of when and how and whether at all it might make sense
>> suggesting to GitLab that we would be a good showcase project, being
>> ancient and with significant history of different trackers etc.  Just
>> to reduce the long-term likelihood of us overstaying our welcome
>> regarding free resources.  Probably something to think about at a
>> considerably later point of time.  Or when we have significant
>> migration problems.
>
> I don't understand this point. Do you mean we should ask the GitLab
> devs for help with the migration?

Not before we run into a serious dead end, I think.  I don't mean to say
that I understand my point, either.  It just feels like if we are using
a free offering, we might want to think about what in our project would
be useful for making GitLab think it is a good idea hosting us.  I have
a vague feeling that there is some opportunity for social engineering.
I cannot entirely vouch for it since my specialty is more social
demolition.

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

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

[Jonas Hahnfeld]

Am Dienstag, den 11.02.2020, 14:27 +0100 schrieb David Kastrup:
> Jonas Hahnfeld <
> hah...@hahnjo.de
> > writes:
> 
> > Am Dienstag, den 11.02.2020, 13:48 +0100 schrieb Federico Bruni:
> > > Il giorno mar 11 feb 2020 alle 13:18, Jonas Hahnfeld <
> > > hah...@hahnjo.de
> > > 
> > > 
> > > ha scritto:
> > > > >  > Another shortcoming is that links to other issues are broken
> > > > >  > (transformed in links to non-existing anchors in current issue).
> > > > > 
> > > > >  I think that is because some issues have not (yet) been migrated. I
> > > > >  hope these links start to work once all is there.
> > > > 
> > > > So I eventually convinced my script to migrate close to all issues 
> > > > [1],
> > > > and all references to other issues that I checked so far are now
> > > > working. Could you maybe check again and let me know if something's
> > > > still broken? In any case I've already modified my script to first 
> > > > sort
> > > > the issues and not take the (random?) order from SF.
> > > 
> > > I still see the problem.
> > > 
> > > Take issue 34 as example.
> > > All the "Issue $NUMBER" have a wrong link:
> > > https://gitlab.com/lilypond-issues/lilypond/issues/34#note_284918285
> > > 
> > > 
> > > https://gitlab.com/lilypond-issues/lilypond/issues/34#note_284918298
> > > 
> > > 
> > > 
> > > But I can see an "issue 34" link working fine:
> > > https://gitlab.com/lilypond-issues/lilypond/issues/34#note_284918318
> > > 
> > > 
> > > 
> > > Perhaps your script is considering only the lower case "issue"?
> > 
> > Well no, I'm relying on GitLab magic here - my script attached for
> > reference.
> > But I think I see what's going on: When the script migrated issue #34,
> > the referenced issues were not there yet and apparently GitLab does
> > some evaluation when the text is posted. If I migrate the issue now
> > (see 
> > https://gitlab.com/lilypond-issues/lilypond/issues/5742
> > ), the
> > links work - also note how "#25" in the first comment comes live.
> > (I manually edited two comments in the original #34, so these do work
> > now. The reference to "Issue 1302" is still broken though as I didn't
> > touch that comment.)
> > 
> > Unfortunately this means that my strategy to create the issues "in
> > order" doesn't work because comments can reference later issues that
> > were created in the mean-time. So instead I'll try to first create all
> > issues and then migrate all comments. That doesn't work for later edits
> > of the issue description, but that should be the minority.
> > I'll wait a few days for other problems before starting another
> > attempt.
> 
> May I point out the tool-to-use for this task?
> 
> File: coreutils.info,  Node: tsort invocation,  Prev: ptx invocation,  Up: 
> Operating on sorted files
> 
> 7.6 ‘tsort’: Topological sort
> =
> 
> [...]
> 
> Now of course the non-linear manner of being able to update issues and
> the desire to have cross-reference means that we _will_ have cycles.  So
> this is not a cure-all, and cycles may need reediting the issues that
> are broken by cycles.  But at least for the more linear reference
> chains, this should be a good help.

Let me look into how many issue descriptions actually reference other
issues. If there are none (or at least none that reference earlier
issues), we can just be happy with the two-stage approach of migrating
all issues first and add the comments in a second step.

Jonas


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

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

[Jonas Hahnfeld]

Am Dienstag, den 11.02.2020, 14:16 +0100 schrieb David Kastrup:
> Jonas Hahnfeld <
> hah...@hahnjo.de
> > writes:
> 
> > Am Montag, den 10.02.2020, 09:20 +0100 schrieb Jonas Hahnfeld:
> > > Am Sonntag, den 09.02.2020, 23:34 +0100 schrieb Federico Bruni:
> > > > Il giorno dom 9 feb 2020 alle 22:50, Jonas Hahnfeld <
> > > > hah...@hahnjo.de
> > > > 
> > > > 
> > > > 
> > > > ha scritto:
> > > > > 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!
> > > > 
> > > > Pretty impressive! I gave a quick glance and it looks great.
> > > > I suggest you eventually share the script in the gitlab.com issue I 
> > > > linked before so others can use it...
> > > 
> > > Will do, probably put it in a public repository (possibly even below
> > > the lilypond group), just for archival purposes.
> > > 
> > > > Another shortcoming is that links to other issues are broken 
> > > > (transformed in links to non-existing anchors in current issue).
> > > 
> > > I think that is because some issues have not (yet) been migrated. I
> > > hope these links start to work once all is there.
> > 
> > So I eventually convinced my script to migrate close to all issues [1],
> > and all references to other issues that I checked so far are now
> > working. Could you maybe check again and let me know if something's
> > still broken? In any case I've already modified my script to first sort
> > the issues and not take the (random?) order from SF.
> > 
> > Jonas
> > 
> > 1: except for #2965, #2044, #2765, #1939, #3654, #4778, #887, #162,
> > #328, #689, #1181, #1618, #1854 - these were considered "spam" but this
> > can be easily worked around by making the repo private for the course
> > of the migration.
> 
> This looks pretty good.  Any idea on whether the tracker should even be
> able to do threading in its issue tracking?  That one's not a
> showstopper.

I looked into this and GitLab does support threading - but not how
SourceForge did: You can turn a comment into a thread, but all replies
to it are again linearized. So not much gained here.

> But of course there are two elephants in the room.  The first is that a
> major point of the exercise is that we want to supplant Rietveld.  Just
> changing the tracker is not a net win.  We are not likely to transfer
> existing Rietveld issues, I guess.  It would be quite-nice to have but
> again: as long as Rietveld sticks around, not a showstopper.  But we
> definitely want to check out the issue flow there.

As per my original proposal, we would start using GitLab MRs for review
but still follow the current process for everything else. I agree that
we don't need to migrate old Rietveld issues (we still have the links).

> So we need a few volunteers getting accounts and emulating our process
> there.  I'm up to volunteering, I guess.
> 
> And of course, once we have a few issues washed through there (and
> likely referenced from our current tracker for the "real" process),

We can of course play with the test migrations (let me know your
account names and I can add you), but I would not put real reviews into
it: I plan to delete all migration tests, we should have one canonical
start for the new platform.

> we
> need to ask James for a look and for feedback of what would be mandatory
> and what would be good for him to have for getting on at least as well
> as he does now.  And we need to take that serious: the amount of work he
> puts in at the _current_ point of time already is nothing that one would
> lightly ask of a volunteer, so we should make sure that what is expected
> to be a net win for the average contributor does not yet make things
> harder for him.
> 
> We don't want to be in the situation that should he one day decide to
> spend more time working with LilyPond than working for LilyPond, we have
> to close shop.
> 
> I am not sure of when and how and whether at all it might make sense

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

[David Kastrup]

Jonas Hahnfeld  writes:

> Am Dienstag, den 11.02.2020, 13:48 +0100 schrieb Federico Bruni:
>> Il giorno mar 11 feb 2020 alle 13:18, Jonas Hahnfeld <
>> hah...@hahnjo.de
>> > 
>> ha scritto:
>> > >  > Another shortcoming is that links to other issues are broken
>> > >  > (transformed in links to non-existing anchors in current issue).
>> > > 
>> > >  I think that is because some issues have not (yet) been migrated. I
>> > >  hope these links start to work once all is there.
>> > 
>> > So I eventually convinced my script to migrate close to all issues 
>> > [1],
>> > and all references to other issues that I checked so far are now
>> > working. Could you maybe check again and let me know if something's
>> > still broken? In any case I've already modified my script to first 
>> > sort
>> > the issues and not take the (random?) order from SF.
>> 
>> I still see the problem.
>> 
>> Take issue 34 as example.
>> All the "Issue $NUMBER" have a wrong link:
>> https://gitlab.com/lilypond-issues/lilypond/issues/34#note_284918285
>> 
>> https://gitlab.com/lilypond-issues/lilypond/issues/34#note_284918298
>> 
>> 
>> But I can see an "issue 34" link working fine:
>> https://gitlab.com/lilypond-issues/lilypond/issues/34#note_284918318
>> 
>> 
>> Perhaps your script is considering only the lower case "issue"?
>
> Well no, I'm relying on GitLab magic here - my script attached for
> reference.
> But I think I see what's going on: When the script migrated issue #34,
> the referenced issues were not there yet and apparently GitLab does
> some evaluation when the text is posted. If I migrate the issue now
> (see https://gitlab.com/lilypond-issues/lilypond/issues/5742), the
> links work - also note how "#25" in the first comment comes live.
> (I manually edited two comments in the original #34, so these do work
> now. The reference to "Issue 1302" is still broken though as I didn't
> touch that comment.)
>
> Unfortunately this means that my strategy to create the issues "in
> order" doesn't work because comments can reference later issues that
> were created in the mean-time. So instead I'll try to first create all
> issues and then migrate all comments. That doesn't work for later edits
> of the issue description, but that should be the minority.
> I'll wait a few days for other problems before starting another
> attempt.

May I point out the tool-to-use for this task?

File: coreutils.info,  Node: tsort invocation,  Prev: ptx invocation,  Up: 
Operating on sorted files

7.6 ‘tsort’: Topological sort
=

‘tsort’ performs a topological sort on the given FILE, or standard input
if no input file is given or for a FILE of ‘-’.  For more details and
some history, see *note tsort background::.  Synopsis:

 tsort [OPTION] [FILE]

   ‘tsort’ reads its input as pairs of strings, separated by blanks,
indicating a partial ordering.  The output is a total ordering that
corresponds to the given partial ordering.

   For example

 tsort <

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

[Jonas Hahnfeld]

Am Dienstag, den 11.02.2020, 13:48 +0100 schrieb Federico Bruni:
> Il giorno mar 11 feb 2020 alle 13:18, Jonas Hahnfeld <
> hah...@hahnjo.de
> > 
> ha scritto:
> > >  > Another shortcoming is that links to other issues are broken
> > >  > (transformed in links to non-existing anchors in current issue).
> > > 
> > >  I think that is because some issues have not (yet) been migrated. I
> > >  hope these links start to work once all is there.
> > 
> > So I eventually convinced my script to migrate close to all issues 
> > [1],
> > and all references to other issues that I checked so far are now
> > working. Could you maybe check again and let me know if something's
> > still broken? In any case I've already modified my script to first 
> > sort
> > the issues and not take the (random?) order from SF.
> 
> I still see the problem.
> 
> Take issue 34 as example.
> All the "Issue $NUMBER" have a wrong link:
> https://gitlab.com/lilypond-issues/lilypond/issues/34#note_284918285
> 
> https://gitlab.com/lilypond-issues/lilypond/issues/34#note_284918298
> 
> 
> But I can see an "issue 34" link working fine:
> https://gitlab.com/lilypond-issues/lilypond/issues/34#note_284918318
> 
> 
> Perhaps your script is considering only the lower case "issue"?

Well no, I'm relying on GitLab magic here - my script attached for
reference.
But I think I see what's going on: When the script migrated issue #34,
the referenced issues were not there yet and apparently GitLab does
some evaluation when the text is posted. If I migrate the issue now
(see https://gitlab.com/lilypond-issues/lilypond/issues/5742), the
links work - also note how "#25" in the first comment comes live.
(I manually edited two comments in the original #34, so these do work
now. The reference to "Issue 1302" is still broken though as I didn't
touch that comment.)

Unfortunately this means that my strategy to create the issues "in
order" doesn't work because comments can reference later issues that
were created in the mean-time. So instead I'll try to first create all
issues and then migrate all comments. That doesn't work for later edits
of the issue description, but that should be the minority.
I'll wait a few days for other problems before starting another
attempt.

Thanks
Jonas
#!/usr/bin/env python3

import argparse
from datetime import datetime
import json
import os
import requests
import sys
from urllib3.util.retry import Retry

GITLAB_API = 'https://gitlab.com/api/v4'
GITLAB_API_UPLOAD = GITLAB_API + '/projects/{repo}/uploads'
GITLAB_API_ISSUE_CREATE = GITLAB_API + '/projects/{repo}/issues'
GITLAB_API_ISSUE_UPDATE = GITLAB_API + '/projects/{repo}/issues/{issue}'
GITLAB_API_ISSUE_NOTE = GITLAB_API + '/projects/{repo}/issues/{issue}/notes'
GITLAB_API_ISSUE_UNSCRIBE = GITLAB_API + '/projects/{repo}/issues/{issue}/unsubscribe'

GITLAB_ISSUE = 'https://gitlab.com/{repo}/issues/{issue}'

SF_ISSUE = 'https://sourceforge.net{url}{issue}'

SF_USER = 'https://sourceforge.net/u/{user}'
TEMPLATE_USER = '[{user}](%s)' % SF_USER

ATTACHMENT_TEMPLATE = '![{file}]({url})'
ATTACHMENTS = '\n\n**Attachments**:  \n'

DESCRIPTION_TEMPLATE_AUTHOR = '*Originally reported by:* {author}\n\n{description}'
DESCRIPTION_TEMPLATE_URL = '{description}\n\n---\n*Original URL*: {url}'

COMMENT_TEMPLATE_AUTHOR = '*Originally posted by:* {author}\n\n{text}'

def get_parser():
parser = argparse.ArgumentParser(
description='Migrate LilyPond issues to GitLab',
)
parser.add_argument(
'--token',
help=(
'GitLab token, get it at ' +
'https://gitlab.com/profile/personal_access_tokens'
),
required=True,
)
parser.add_argument(
'--repo',
help='GitLab repository where to import',
required=True
)
parser.add_argument(
'export',
help='Directory with export from SourceForge'
)
return parser

parser = get_parser()
args = parser.parse_args(sys.argv[1:])
api_repo = args.repo.replace('/', '%2F')

export_dir = args.export
json_file = os.path.join(export_dir, 'issues.json')
if not os.path.isfile(json_file):
print('No export found in `%s`' % export)
sys.exit(1)

with open(json_file, 'r') as f:
issues = json.load(f)

tickets = issues['tickets']
sf_url = issues['tracker_config']['options']['url']
# issues['milestones'] is empty
issues_custom_fields = issues['custom_fields']
open_status_names = issues['open_status_names'].split(' ')
closed_status_names = issues['closed_status_names'].split(' ')
# issues['saved_bins'] contains our pre-defined search queries

api = requests.Session()
# Supply token
api.headers = {'Private-Token': args.token}
# Retry on "Internal Server Error"
retries = Retry(
method_whitelist=['POST','PUT'],
status_forcelist=[500],
)
adapter = requests.adapters.HTTPAdapter(max_retries=retries)
api.mount(GITLAB_API, adapter)

def get_ticket_num(ticket):
return ticket['ticket_num']

def is_author(author):
return author not in 

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

[David Kastrup]

Jonas Hahnfeld  writes:

> Am Montag, den 10.02.2020, 09:20 +0100 schrieb Jonas Hahnfeld:
>> Am Sonntag, den 09.02.2020, 23:34 +0100 schrieb Federico Bruni:
>> > Il giorno dom 9 feb 2020 alle 22:50, Jonas Hahnfeld <
>> > hah...@hahnjo.de
>> > 
>> > 
>> > ha scritto:
>> > > 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!
>> > 
>> > Pretty impressive! I gave a quick glance and it looks great.
>> > I suggest you eventually share the script in the gitlab.com issue I 
>> > linked before so others can use it...
>> 
>> Will do, probably put it in a public repository (possibly even below
>> the lilypond group), just for archival purposes.
>> 
>> > Another shortcoming is that links to other issues are broken 
>> > (transformed in links to non-existing anchors in current issue).
>> 
>> I think that is because some issues have not (yet) been migrated. I
>> hope these links start to work once all is there.
>
> So I eventually convinced my script to migrate close to all issues [1],
> and all references to other issues that I checked so far are now
> working. Could you maybe check again and let me know if something's
> still broken? In any case I've already modified my script to first sort
> the issues and not take the (random?) order from SF.
>
> Jonas
>
> 1: except for #2965, #2044, #2765, #1939, #3654, #4778, #887, #162,
> #328, #689, #1181, #1618, #1854 - these were considered "spam" but this
> can be easily worked around by making the repo private for the course
> of the migration.

This looks pretty good.  Any idea on whether the tracker should even be
able to do threading in its issue tracking?  That one's not a
showstopper.

But of course there are two elephants in the room.  The first is that a
major point of the exercise is that we want to supplant Rietveld.  Just
changing the tracker is not a net win.  We are not likely to transfer
existing Rietveld issues, I guess.  It would be quite-nice to have but
again: as long as Rietveld sticks around, not a showstopper.  But we
definitely want to check out the issue flow there.

So we need a few volunteers getting accounts and emulating our process
there.  I'm up to volunteering, I guess.

And of course, once we have a few issues washed through there (and
likely referenced from our current tracker for the "real" process), we
need to ask James for a look and for feedback of what would be mandatory
and what would be good for him to have for getting on at least as well
as he does now.  And we need to take that serious: the amount of work he
puts in at the _current_ point of time already is nothing that one would
lightly ask of a volunteer, so we should make sure that what is expected
to be a net win for the average contributor does not yet make things
harder for him.

We don't want to be in the situation that should he one day decide to
spend more time working with LilyPond than working for LilyPond, we have
to close shop.

I am not sure of when and how and whether at all it might make sense
suggesting to GitLab that we would be a good showcase project, being
ancient and with significant history of different trackers etc.  Just to
reduce the long-term likelihood of us overstaying our welcome regarding
free resources.  Probably something to think about at a considerably
later point of time.  Or when we have significant migration problems.

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

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

[Federico Bruni]

Il giorno mar 11 feb 2020 alle 13:18, Jonas Hahnfeld  
ha scritto:

 > Another shortcoming is that links to other issues are broken
 > (transformed in links to non-existing anchors in current issue).

 I think that is because some issues have not (yet) been migrated. I
 hope these links start to work once all is there.


So I eventually convinced my script to migrate close to all issues 
[1],

and all references to other issues that I checked so far are now
working. Could you maybe check again and let me know if something's
still broken? In any case I've already modified my script to first 
sort

the issues and not take the (random?) order from SF.


I still see the problem.

Take issue 34 as example.
All the "Issue $NUMBER" have a wrong link:
https://gitlab.com/lilypond-issues/lilypond/issues/34#note_284918285
https://gitlab.com/lilypond-issues/lilypond/issues/34#note_284918298

But I can see an "issue 34" link working fine:
https://gitlab.com/lilypond-issues/lilypond/issues/34#note_284918318

Perhaps your script is considering only the lower case "issue"?

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

[Jonas Hahnfeld]

Am Montag, den 10.02.2020, 09:20 +0100 schrieb Jonas Hahnfeld:
> Am Sonntag, den 09.02.2020, 23:34 +0100 schrieb Federico Bruni:
> > Il giorno dom 9 feb 2020 alle 22:50, Jonas Hahnfeld <
> > hah...@hahnjo.de
> > 
> > 
> > ha scritto:
> > > 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!
> > 
> > Pretty impressive! I gave a quick glance and it looks great.
> > I suggest you eventually share the script in the gitlab.com issue I 
> > linked before so others can use it...
> 
> Will do, probably put it in a public repository (possibly even below
> the lilypond group), just for archival purposes.
> 
> > Another shortcoming is that links to other issues are broken 
> > (transformed in links to non-existing anchors in current issue).
> 
> I think that is because some issues have not (yet) been migrated. I
> hope these links start to work once all is there.

So I eventually convinced my script to migrate close to all issues [1],
and all references to other issues that I checked so far are now
working. Could you maybe check again and let me know if something's
still broken? In any case I've already modified my script to first sort
the issues and not take the (random?) order from SF.

Jonas

1: except for #2965, #2044, #2765, #1939, #3654, #4778, #887, #162,
#328, #689, #1181, #1618, #1854 - these were considered "spam" but this
can be easily worked around by making the repo private for the course
of the migration.


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

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

[Jonas Hahnfeld]

Am Montag, den 10.02.2020, 07:58 +0100 schrieb Han-Wen Nienhuys:
> Very nice. Why is the project/user called lilypond-issues?

Because I don't want to to do this with my personal account. First I
created a personal repo hahnjo/lilypond and granted lilypond-issues
access to it. That doesn't work unfortunately because for preserving
the ticket numbers and backdate the issues / comments, the API user
must be "owner" of the repository. By definition there is only one for
personal repos (well, makes sense), but it's less of an issue for a
group: There we could just grant that user temporary Owner access for
the final migration and remove it afterwards.

> Do we know who owns the 'lilypond' user?

If you mean the lilypond group https://gitlab.com/lilypond, then I'd
guess Janek?

Jonas


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

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

[Jonas Hahnfeld]

Am Sonntag, den 09.02.2020, 23:34 +0100 schrieb Federico Bruni:
> Il giorno dom 9 feb 2020 alle 22:50, Jonas Hahnfeld <
> hah...@hahnjo.de
> > 
> ha scritto:
> > 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!
> 
> Pretty impressive! I gave a quick glance and it looks great.
> I suggest you eventually share the script in the gitlab.com issue I 
> linked before so others can use it...

Will do, probably put it in a public repository (possibly even below
the lilypond group), just for archival purposes.

> Another shortcoming is that links to other issues are broken 
> (transformed in links to non-existing anchors in current issue).

I think that is because some issues have not (yet) been migrated. I
hope these links start to work once all is there.

> When I tested the Google Code>GitHub issue migration years ago, I was 
> blocked by Github filters and I had to ask a special permission to 
> continue. In case you see a block try contacting GitLab.com.

For now it was only the text of a single issue that was considered
"spam". But I'll keep that in mind, maybe ask for the final migration
if I hit more problems in the tests.

Jonas


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

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

[Han-Wen Nienhuys]

Very nice. Why is the project/user called lilypond-issues? Do we know who
owns the 'lilypond' user?

On Sun, Feb 9, 2020 at 10:50 PM Jonas Hahnfeld  wrote:

> Am Freitag, den 07.02.2020, 16:28 +0100 schrieb Federico Bruni:
> > Il giorno ven 7 feb 2020 alle 10:33, Federico Bruni
> > <
> > f...@inventati.org
> > > 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
>


-- 
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen

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

[Federico Bruni]

Il giorno dom 9 feb 2020 alle 22:50, Jonas Hahnfeld  
ha scritto:

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!


Pretty impressive! I gave a quick glance and it looks great.
I suggest you eventually share the script in the gitlab.com issue I 
linked before so others can use it...


Another shortcoming is that links to other issues are broken 
(transformed in links to non-existing anchors in current issue).


When I tested the Google Code>GitHub issue migration years ago, I was 
blocked by Github filters and I had to ask a special permission to 
continue. In case you see a block try contacting GitLab.com.

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

[Jonas Hahnfeld]

Am Sonntag, den 09.02.2020, 23:03 +0100 schrieb David Kastrup:
> Jonas Hahnfeld <
> hah...@hahnjo.de
> > writes:
> 
> > Am Freitag, den 07.02.2020, 16:28 +0100 schrieb Federico Bruni:
> > > Il giorno ven 7 feb 2020 alle 10:33, Federico Bruni 
> > > <
> > > f...@inventati.org
> > > 
> > > > 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.

If you mean for example this comment:
https://gitlab.com/lilypond-issues/lilypond/issues/4633#note_284960086
... then no, that's not GitLab to credit but the link was already there
on SourceForge (check the original issue) and the markup is preserved.
But yes, plain commit ids will become clickable once the project has
the source code imported.

Jonas


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

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

[Werner LEMBERG]

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

+1  Very nice!


Werner

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

[Jonas Hahnfeld]

Am Sonntag, den 09.02.2020, 22:50 +0100 schrieb 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 
> > <
> > f...@inventati.org
> > 
> > > 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...)

Correction: It's only issue #2965 that akismet considers spam. Oh well,
if I read the documentation correctly, migrating into a private
repository and then making it public disables spam checking...
So I'll let my server run the script over night and check the result
tomorrow.

Cheers
Jonas


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

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

[David Kastrup]

Jonas Hahnfeld  writes:

> Am Freitag, den 07.02.2020, 16:28 +0100 schrieb Federico Bruni:
>> Il giorno ven 7 feb 2020 alle 10:33, Federico Bruni 
>> <
>> f...@inventati.org
>> > 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".

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 
> <
> f...@inventati.org
> > 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
Description: This is a digitally signed message part

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

[Federico Bruni]

Il giorno ven 7 feb 2020 alle 10:33, Federico Bruni 
 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...

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

[Federico Bruni]

Il giorno ven 7 feb 2020 alle 12:45, Trevor  ha 
scritto:
The Allura software that we use at SourceForge is also Open Source, I 
believe.


See 

I don't know to what extent the SourceForge team have modified this, 
but
if self-hosting is a possibility this should at least be seriously 
investigated.
(Not by me, I should add - at 79 my days of technical involvement are 
over.)


We'd always intended to migrate Allura to a self-hosted platform, but
no-one seemed willing to put in the effort 5 years ago.


The purpose of changing issue tracker is using an intergated platform 
like GitLab (code hosting integrated with issue tracker and Continuous 
Integration).
We'd rather avoid self-hosting if possible (even though it's 
good-to-have-option in case available services are interrupted or 
change policy).

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

[Trevor]

David Kastrup wrote  07/02/2020 12:21:30
Subject: Re: [RFC] switch to GitLab / gitlab.com


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.

The Allura software that we use at SourceForge is also Open Source, I 
believe.


See https://allura.apache.org/

I don't know to what extent the SourceForge team have modified this, but
if self-hosting is a possibility this should at least be seriously 
investigated.
(Not by me, I should add - at 79 my days of technical involvement are 
over.)


We'd always intended to migrate Allura to a self-hosted platform, but
no-one seemed willing to put in the effort 5 years ago.

Trevor

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

[David Kastrup]

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

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

[David Kastrup]

Karlin High  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:
>
> 
>
> And these seemed like GitLab's answer to it:
>
> 
>
> 
>
>> 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

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

[Jonas Hahnfeld]

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
Description: This is a digitally signed message part

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

[Federico Bruni]

Il giorno ven 7 feb 2020 alle 10:36, Urs Liska  
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? ^_^

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

[Federico Bruni]

Il giorno ven 7 feb 2020 alle 08:59, Jonas Hahnfeld  
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:

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

[Urs Liska]

Am 7. Februar 2020 09:48:30 MEZ schrieb Kevin Barry :
>> (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.

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

[Kevin Barry]

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

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

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
Description: This is a digitally signed message part

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:




And these seemed like GitLab's answer to it:






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

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 <
> hah...@hahnjo.de
> > 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

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

[Karlin High]

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



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.




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

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

[Jonas Hahnfeld]

Am Mittwoch, den 05.02.2020, 21:02 + schrieb pkx1...@posteo.net:
> On 05/02/2020 16:13, Dan Eble wrote:
> > On Feb 5, 2020, at 10:09, Jonas Hahnfeld <
> > hah...@hahnjo.de
> > > 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
Description: This is a digitally signed message part

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

[pkx166h]

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

On Feb 5, 2020, at 10:09, Jonas Hahnfeld  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

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

[Dan Eble]

On Feb 5, 2020, at 10:09, Jonas Hahnfeld  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

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

[David Kastrup]

Jonas Hahnfeld  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).

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

-- 
David Kastrup

[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
Description: This is a digitally signed message part