← Back to team overview

kicad-developers team mailing list archive

Re: GitLab migration

 

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.suminski@xxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>

Follow ups

References