Using labels for flang issues

Subprojects Flang
1

I’ve been trying to capture the status of the project, in part by looking at all of the issues. This situation could be improved by having a better scheme for labeling them.

Currently, there are six different labels that are specific to flang – flang, flang:runtime, flang:driver, flang:frontend, flang:ir, and flang:build.

To make label-based queries simpler, I propose the following:

  • Attach the label “bug” to all issues that are bugs that should be fixed.
  • Attach the label “performance” to all issues related to performance, runtime, compile time, and build time.
  • Attach the label “enhancement” to all issues related to enhancements.
  • Attach the label “missing-feature” to anything where the implementation is planned and not an enhancement.

I also wonder if we should just get rid of the “flang:build” label and just label such issues with “flang” and “build-problem”.

Pete

3 Likes
2

I would add:

  • Attach the label “floating-point” to issues related to floating-point precision.

Pete

3

Also,

  • Attach the label “question” to issues that contain questions.

Pete

4

Hi Pete,

How are issues organized for clang? Perhaps their value in aligning as much as possible.

5

For reference, there was a similar discussion about Clang:

They had a hard time finding something like:
label:"good first issue" label: "clang\:?.*"

2 Likes
6

There are 19 labels with “clang” in their name:
clang:codegen
clang:dataflow
clang:diagnostics
clang:documentation
clang:driver
clang:frontend
clang:headers
clang:modules
clang:static analyzer
clang:tooling
clang
clang-cl
clang-doc
clang-format
clang-include-cleaner
clang-query
clang-tidy
clang-tools-extra
clangd

So our organization looks similar, but shorter.

Pete

7

I suspect that the clang folks had a hard time because they have so many labels. As of right now, I think things are manageable for flang. For example, here’s a query that finds all of the bugs in flang that are not OpenMP:
is:issue is:open label:flang,flang:runtime,flang:driver,flang:frontend,flang:ir label:bug -label:openmp

Pete

1 Like
8

I have two comments: (a) in your list e.eg. clang-include-cleaner which is not clang related and (b) a concise and documented list of labels is probably a win.

9

Thanks @psteinfeld for starting the discussion about labels. I broadly agree with the labels you suggested. Enhancement and “missing-feature” might need a bit more explanation.

The advantage of having labels is that they can have a list of subscribers who get notified if the label is used. This helps people who might be interested in a specific aspect of the compiler, like driver or the frontend of flang. I dont know whether the same works for composite labels.

Since bugs can be filed by people not familiar with the process, this would require some maintenance by volunteers. @EugeneZelenko does a lot of volunteer work to attach the labels. It will be good to get Eugene’s opinion as well.

I also wonder if we should just get rid of the “flang:build” label and just label such issues with “flang” and “build-problem”.

For the flang:build label, the list of subscribers can be found in Sign in to GitHub · GitHub. It might be good to check with these subscribers before removing it.

Attach the label “floating-point” to issues related to floating-point precision.

Can this be called “precision” to include Complex, and may be integer prevision/overflow issues as well?

10
  • Attach the label “floating-point” to issues related to floating-point precision.

“Accuracy” is probably the right word. I doubt that we have many bugs where we somehow mess up on precision, but of course we have bug reports on codes producing inaccurate results that need to be explained.

11

I think it’s reasonable to use generic labels like build-problem, documentation then create project-specific ones ones, so generic labels and their meaning are consistent across all projects.

12

I agree with your logic, but I was trying to avoid inventing new labels. After searching the existing set, “floating-point” was as close as I could come without inventing a new label.

13

Thanks, @EugeneZelenko. I assume that you mean that it’s better to use existing labels “than” to create new ones. If so, I agree heartily.

14

Thanks for the great feedback!

I’m aware of the ability to get notifications based on label names. I’ll check with the subscribers to “flang-build” before taking any action on it.

As I mentioned to @klausler, “precision” seems like a more descriptive label, but using it would require inventing it. I was trying to avoid creating new labels. But with both of you suggesting that change, it seems like the way to go.