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 <
> > address@hidden
> > 
> > > writes:
> > > Am Dienstag, den 11.02.2020, 13:48 +0100 schrieb Federico Bruni:
> > > > Il giorno mar 11 feb 2020 alle 13:18, Jonas Hahnfeld <
> > > > address@hidden
> > > > 
> > > > 
> > > > 
> > > > 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

find_references.py
Description: Text Data

references.txt
Description: Text document

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