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

[David Kastrup]

Jonas Hahnfeld <address@hidden> 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 <
>> > address@hidden
>> > 
>> > 
>> > 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".