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