Orson, Great work so far.
I was noticing as you were testing migrating the issues that our @names in the text seem to not transfer well. In one of the issues just now (the pcbnew segfault issue #228 [2]) it pulls in a different user for Seth whenever @seth is mentioned, and also for my name. Do you think it would be possible to do two things with the message text: 1) Replace the @name usage for the most common people with their GitLab user (this would require us to know all of them and have a map between name and user). This should also be case insensitive, since we don't always seem to capitalize names. 2) Escape the @name usage in other cases (maybe add a space between the @ and the name?). At the very least we should probably escape them so we don't randomly mention unrelated people in all our issues. On the topic of labels, I was doing some research and if we can get the OSS license for GitLab I think we can turn the Launchpad status and priority into scoped labels [1]. The nice thing about those is only one label per scope can be applied to an issue at a time, and adding a new label to an issue automatically removes the old one. I think we could define scopes such as priority::{wishlist, low, medium, etc...} status::{new, confirmed, in progress, as designed, fix committed, etc...} By doing this I think it is nice and obvious what the open/close status of the bug is (instead of just having open/close). I was going to start redrafting Nick's Launchpad guidance into something for GitLab using the labels in the next week hopefully. Then we can get some more comments on it. [1] https://docs.gitlab.com/ee/user/project/labels.html#scoped-labels-premium [2] https://gitlab.com/orsonmmz/kicad-bug-tracker/issues/228#note_230289955 Thanks for doing this. -Ian On Mon, 14 Oct 2019, 23:52 Maciej Suminski, <maciej.sumin...@cern.ch> wrote: > I have started working on the bug tracker migration script [1], and now > you can check out a test batch of 100 bug reports converted to Gitlab > [2]. I am looking forward to your comments. > > What is transferred accurately? > - description > - messages (including attachments and dates) > - milestones > - tags > - duplicates ('related bugs' in Gitlab) > > What is different? > - text formatting: > Gitlab uses markdown to format the text, while Launchpad reports are > plain text. From what I see, verbatim text transfer between the > platforms does not look terrible, but if you see anything that demands a > fix - let me know. > > - importance: > In Gitlab bugs are described with 'weight' property, which is an > integer. I imagine the higher the weight, the more important is a bug. > For the moment I use the following mapping: > 'Critical': return 50 > 'High': return 40 > 'Medium': return 30 > 'Low': return 20 > 'Wishlist': return 10 > > - status: > Gitlab offers only two status types: opened/closed. It is a pity, but I > doubt we can do anything about it. Here is a mapping proposal: > 'New': return 'active' > 'Incomplete': return 'active' > 'Opinion': return 'active' > 'Invalid': return 'close' > 'Won\'t Fix': return 'close' > 'Expired': return 'close' # TODO should be closed or active? > 'Confirmed': return 'active' > 'Triaged': return 'active' > 'In Progress': return 'active' > 'Fix Committed': return 'close' > 'Fix Released': return 'close' > > - authors: > The whole contents is currently transferred under a single author > (myself, but I plan to use a dedicated account for the migration). If we > were admins of a Gitlab instance, then we could use 'sudo' [3] to > impersonate users. This would still require users to create their > accounts before the migration. > My workaround is adding a first line indicating the original author > ('xxx wrote:'). > > To-do: > - assignees: > I plan to create a user map linking Launchpad and Gitlab accounts to > transfer. If an account is not mapped, then I will try to search > gitlab.com for an exact match (I cannot guess correctly if search > results contain multiple accounts). > > - optimization: > The script is painfully slow (100 issues in 0.5h), and I have not > profiled it yet. > > - URLs: > I would like to convert Launchpad links occurring in the reports to > their Gitlab counterparts. > > Other notes: > KiCad Janitor may retire after the migration, as Gitlab provides a way > to close issues using commit messages [4]. > > Cheers, > Orson > > 1. https://gitlab.com/orsonmmz/kicad-bug-tracker > 2. > https://gitlab.com/orsonmmz/kicad-bug-tracker/issues?scope=all&state=all > 3. https://docs.gitlab.com/ee/api/#sudo > 4. > > https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#default-closing-pattern > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp >
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp