Hi, Thank you both for the input.
On 10/15/19 1:28 AM, Seth Hillbrand wrote:
> On 2019-10-14 16:09, Ian McInerney wrote:
>
>> 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.
Good catch, I have not noticed the issue. I hope Gitlab has not flooded
you with notification mails, I am sorry if that happened.
I will escape the user names, I guess there is no advantage in replacing
the user names during the migration.
>> 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'll second Ian's suggestion that the priorities and status both get
> labels.
Agreed, scoped labels seems like a perfect match that I was not aware of.
I'd like to see Heat map to GitLab's weight. You can't really
> search much with weight in GitLab (no range operators that I can find),
> so it seems mostly useful for sorting after you get the results.
Given we are going to use scoped labels to indicate the priority, I do
not mind mapping heat to weight. I think a closer match is up- and
down-voting, but it is not something that I can modify with API, so
let's stick to the weight attribute.
> I think we'll need to figure out how to deal with our version
> information in KiCad not being nicely formatted for markdown. The
> blockquote for variable indents is readable but distracting. Maybe we
> can get it into a block like:
> <details>
> <summary>KiCad Version Info</summary>
> <pre>All the details here</pre>
> </details>
Ian has also another idea, I will test both and pick one that looks
better (IMHO;).
Cheers,
Orson
> Overall, this is great! Looking forward to the move.
>
> -Seth
signature.asc
Description: OpenPGP digital signature
_______________________________________________ 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
