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

[Jonas Hahnfeld]

Am Dienstag, den 11.02.2020, 14:16 +0100 schrieb 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.

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

Jonas

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