kicad-developers team mailing list archive

[Ian McInerney <mcianster@xxxxxxxxx>]

It looks like part of the formatting issue is related to the fact that the
migrated issues have a line in between each entry in the version
information. What seems to produce the best results is to simply wrap the
copied version text from KiCad inside ``` ```, take a look at this sample
[1]. I think the best way to implement this would be to take advantage of
the issue templates [2], to give the user a pre-made style to fill in. See
[3] for an example that I threw together. We might also be able to use this
to automatically tag the issue with initial labels when it is created. I
haven't tested that though, so I am unsure of the permissions needed to
modify the labels (in one place it looks like normal users can't do that,
but quite a few projects have the labels included in their default
template). If someone wants to try creating an issue in that repository to
see if the labels are added that would be appreciated.

<https://gitlab.com/help/user/project/description_templates>
[1] https://gitlab.com/imcinerney/bugtracker-test/issues/3
[2] https://gitlab.com/help/user/project/description_templates
[3] https://gitlab.com/imcinerney/bugtracker-test/issues/new?issue

-Ian

On Tue, Oct 15, 2019 at 12:28 AM Seth Hillbrand <seth@xxxxxxxxxxxxx> 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.
> >
> > 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.  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.
>
> 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>
>
>
> Overall, this is great!  Looking forward to the move.
>
> -Seth
>


-- 
Ian McInerney
mcianster@xxxxxxxxx

No electrons were harmed in the making of this message