GHC label conventions

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

GHC label conventions

Ben Gamari-3

Hello everyone,

I have documented our current conventions regarding GitLab label usage
on the Wiki [1]. Please do keep this up-to-date if you create, remove,
or rename a label.

As always, feedback is welcome

Cheers,

- Ben


[1] https://gitlab.haskell.org/ghc/ghc/wikis/GitLab-Labels/

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: GHC label conventions

GHC - devs mailing list
Good!

Colours are a bit mixed up.  Blue seems to be for "Scope".  Could "Issue flags" be another colour, and "Types of bugs" be another.  The mixture under those headings is hard to grok.

Simon

|  -----Original Message-----
|  From: ghc-devs <[hidden email]> On Behalf Of Ben Gamari
|  Sent: 29 March 2019 18:00
|  To: GHC developers <[hidden email]>
|  Subject: GHC label conventions
|  
|  
|  Hello everyone,
|  
|  I have documented our current conventions regarding GitLab label usage
|  on the Wiki [1]. Please do keep this up-to-date if you create, remove,
|  or rename a label.
|  
|  As always, feedback is welcome
|  
|  Cheers,
|  
|  - Ben
|  
|  
|  [1]
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab
|  .haskell.org%2Fghc%2Fghc%2Fwikis%2FGitLab-
|  Labels%2F&amp;data=02%7C01%7Csimonpj%40microsoft.com%7Cf0bcbca77f214dc5a
|  9a408d6b4705bb1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63689479200
|  3872381&amp;sdata=DeNxaFFKnkyYOXhIoUoiIeqq19ceOK37BHP5wwfmAg0%3D&amp;res
|  erved=0
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

RE: GHC label conventions

Ben Gamari-3
Simon Peyton Jones via ghc-devs <[hidden email]> writes:

> Good!
>
> Colours are a bit mixed up. Blue seems to be for "Scope". Could "Issue
> flags" be another colour, and "Types of bugs" be another. The mixture
> under those headings is hard to grok.
>
Yes they were; I ran out of time before I had a chance to look too
deeply at the colors.

Matthew and I discussed the matter of colors and he argued that most
labels should remain a single color (currently blue) to prevent things
from becoming too visually busy. Given how cluttered GitLab's UI already
is, I'm sympathetic to this argument.

I just had a quick look over the colors with this in mind and changed a
couple to improve consistency. Things are could likely still be improved
but the general idea is:

 * purple: types of issues (e.g. bug, feature request, task)
 * green: performance issues
 * red: correctness issues
 * yellow/brown: stages of the issue lifecycle
 * blue: bug scope (operating system, architecture, compiler subsystem,
   language featuresetc.)

Cheers,

- Ben


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: GHC label conventions

GHC - devs mailing list
In reply to this post by Ben Gamari-3
Are you sure you got all the labels. Eg I don't see "type error messages
https://gitlab.haskell.org/ghc/ghc/issues?label_name%5B%5D=type+error+messages

Maybe that's because there is only one such ticket, #16439.

Can we have a list of all such orphaned labels, so we can get rid of them?  Eg by relabelling

Simon


|  -----Original Message-----
|  From: ghc-devs <[hidden email]> On Behalf Of Ben Gamari
|  Sent: 29 March 2019 18:00
|  To: GHC developers <[hidden email]>
|  Subject: GHC label conventions
|  
|  
|  Hello everyone,
|  
|  I have documented our current conventions regarding GitLab label usage
|  on the Wiki [1]. Please do keep this up-to-date if you create, remove,
|  or rename a label.
|  
|  As always, feedback is welcome
|  
|  Cheers,
|  
|  - Ben
|  
|  
|  [1]
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab
|  .haskell.org%2Fghc%2Fghc%2Fwikis%2FGitLab-
|  Labels%2F&amp;data=02%7C01%7Csimonpj%40microsoft.com%7Cf0bcbca77f214dc5a
|  9a408d6b4705bb1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63689479200
|  3872381&amp;sdata=DeNxaFFKnkyYOXhIoUoiIeqq19ceOK37BHP5wwfmAg0%3D&amp;res
|  erved=0
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

RE: GHC label conventions

Ben Gamari-3
Simon Peyton Jones via ghc-devs <[hidden email]> writes:

> Are you sure you got all the labels. Eg I don't see "type error messages
> https://gitlab.haskell.org/ghc/ghc/issues?label_name%5B%5D=type+error+messages
>
> Maybe that's because there is only one such ticket, #16439.
>
Indeed, that is reason. I had intended to fold that particular label
into ~"error messages" but it appears that I missed it.

> Can we have a list of all such orphaned labels, so we can get rid of them?  Eg by relabelling
>
Sure, I can produce such a list. Give me just a minute.

Cheers,

- Ben

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: GHC label conventions

Ben Gamari-3
In reply to this post by GHC - devs mailing list
Simon Peyton Jones via ghc-devs <[hidden email]> writes:

> Are you sure you got all the labels. Eg I don't see "type error messages
> https://gitlab.haskell.org/ghc/ghc/issues?label_name%5B%5D=type+error+messages
>
> Maybe that's because there is only one such ticket, #16439.
>
> Can we have a list of all such orphaned labels, so we can get rid of them?  Eg by relabelling
>
The set of orphan keywords is attached (orphan-keywords.json).

For reference, the orphan set was computed from the set of all keywords
(all-keywords.csv, from Trac report #25) and the keyword mapping used by
the import script (keyword-label-mapping.json, mapping Trac keywords to
a set of GitLab labels) as follows in Python:

    import csv
    import json

    all_keywords = set(e[0].lower() for e in csv.reader(open('all-keywords.csv')))
    mapping = json.load(open('./keyword-label-mappping.json'))
    mapped_keywords = set(map(str.lower, mapping.keys()))
    orphans = set(all_keywords).difference(mapped_keywords)
    json.dump(list(orphans), open('orphan-keywords.json','w'))

Cheers,

- Ben



_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (497 bytes) Download Attachment
all-keywords.csv (31K) Download Attachment
orphan-keywords.json (4K) Download Attachment
keyword-label-mappping.json (10K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: GHC label conventions

Phyx
Hi Ben, 

That's awesome! I'm glad to have something to refer to as on Trac I was sometimes hesitant as to where something fell. 

Two questions, well three.

1. Curious, is there no Linux label? Similarly no x86 and x64_86 labels? 
2. The ARM one is that Arm (e.g. pre AArch32) or just all Arm architectures? (I see no AArch64) either. Is this because we didn't have a label for them in trac?

3. Slightly unrelated, on Phabricator I used to have a customized side bar with helpful links such as this one. Can I do the same on GitLab? 

Thanks, 
Tamar 


Sent from my Mobile

On Mon, Apr 1, 2019, 21:35 Ben Gamari <[hidden email]> wrote:
Simon Peyton Jones via ghc-devs <[hidden email]> writes:

> Are you sure you got all the labels. Eg I don't see "type error messages
> https://gitlab.haskell.org/ghc/ghc/issues?label_name%5B%5D=type+error+messages
>
> Maybe that's because there is only one such ticket, #16439.
>
> Can we have a list of all such orphaned labels, so we can get rid of them?  Eg by relabelling
>
The set of orphan keywords is attached (orphan-keywords.json).

For reference, the orphan set was computed from the set of all keywords
(all-keywords.csv, from Trac report #25) and the keyword mapping used by
the import script (keyword-label-mapping.json, mapping Trac keywords to
a set of GitLab labels) as follows in Python:

    import csv
    import json

    all_keywords = set(e[0].lower() for e in csv.reader(open('all-keywords.csv')))
    mapping = json.load(open('./keyword-label-mappping.json'))
    mapped_keywords = set(map(str.lower, mapping.keys()))
    orphans = set(all_keywords).difference(mapped_keywords)
    json.dump(list(orphans), open('orphan-keywords.json','w'))

Cheers,

- Ben


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: GHC label conventions

Ben Gamari-3
Phyx <[hidden email]> writes:

> Hi Ben,
>
> That's awesome! I'm glad to have something to refer to as on Trac I was
> sometimes hesitant as to where something fell.
>
Indeed; you certainly weren't the only one. As you can tell from the
import mappings I posted earlier, Trac keyword usage wasn't particularly
consistent.

> Two questions, well three.
>
> 1. Curious, is there no Linux label? Similarly no x86 and x64_86 labels?

I consider Linux/x86-64 to be the default; e.g. if there a ticket isn't
labelled with one of the operating system labels then it should be
assumed that either the issue is OS-independent or it's Linux. This is a
compromise but given that we need to assign labels manually, it didn't
seem like manually labelling all Linux tickets was worth the effort.
Also, once !653 lands issue authors will be prompted for their operating
system in the issue description.

> 2. The ARM one is that Arm (e.g. pre AArch32) or just all Arm
> architectures? (I see no AArch64) either.

ARM refers to all ARM architectures. I'll update the description to be
more clear on this.

> Is this because we didn't have a label for them in trac?
>
Pretty much.

> 3. Slightly unrelated, on Phabricator I used to have a customized side bar
> with helpful links such as this one. Can I do the same on GitLab?
>
I'm afraid the answer may be "no". I have this page in my browser's
bookmarks list. I suppose we could add it to _sidebar [1], which is
displayed in the sidebar on the right side of the screen when viewing
the wiki; however this seems like a bit of a slippery slope as it isn't
really a top-level page.

Cheers,

- Ben

[1] https://gitlab.haskell.org/ghc/ghc/wikis/_sidebar

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: GHC label conventions

Phyx
Hi Ben,


I consider Linux/x86-64 to be the default; e.g. if there a ticket isn't
labelled with one of the operating system labels then it should be
assumed that either the issue is OS-independent or it's Linux. This is a
compromise but given that we need to assign labels manually, it didn't
seem like manually labelling all Linux tickets was worth the effort.
Also, once !653 lands issue authors will be prompted for their operating
system in the issue description.

That's fair, I had thought this might be the case, but have you considered that you also
lose the ability to filter using an inclusion filter then? To get list of x86 only Linux you would have
exclude all competing tags then (if possible).

But this also introduce an ambiguity, there's no way to say for instance that an issue effects Linux and
Windows for instance as you would just have the Windows tag.


> 2. The ARM one is that Arm (e.g. pre AArch32) or just all Arm
> architectures? (I see no AArch64) either.

ARM refers to all ARM architectures. I'll update the description to be
more clear on this.

> Is this because we didn't have a label for them in trac?
>
Pretty much.

> 3. Slightly unrelated, on Phabricator I used to have a customized side bar
> with helpful links such as this one. Can I do the same on GitLab?
>
I'm afraid the answer may be "no". I have this page in my browser's
bookmarks list. I suppose we could add it to _sidebar [1], which is
displayed in the sidebar on the right side of the screen when viewing
the wiki; however this seems like a bit of a slippery slope as it isn't
really a top-level page.

Ah ok, was just checking, I can do a local plugin instead.

Thanks,
Tamar


Cheers,

- Ben

[1] https://gitlab.haskell.org/ghc/ghc/wikis/_sidebar

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: GHC label conventions

Ben Gamari-3
Phyx <[hidden email]> writes:

> Hi Ben,
>
>
>> I consider Linux/x86-64 to be the default; e.g. if there a ticket isn't
>> labelled with one of the operating system labels then it should be
>> assumed that either the issue is OS-independent or it's Linux. This is a
>> compromise but given that we need to assign labels manually, it didn't
>> seem like manually labelling all Linux tickets was worth the effort.
>> Also, once !653 lands issue authors will be prompted for their operating
>> system in the issue description.
>>
>
> That's fair, I had thought this might be the case, but have you considered
> that you also
> lose the ability to filter using an inclusion filter then? To get list of
> x86 only Linux you would have
> exclude all competing tags then (if possible).
>
Indeed. Apparently at some point GitLab will be gaining the ability to
do full boolean expression queries. However, until then I'm not sure
that I see an alternative that isn't labor-intensive.

> But this also introduce an ambiguity, there's no way to say for instance
> that an issue effects Linux and
> Windows for instance as you would just have the Windows tag.
>
Yes, this a known (and unfortunate) consequence of the choice.

Cheers,

- Ben

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (497 bytes) Download Attachment