Skip to content

GitLab

GHC
GHC
Last edited by Hécate Moonlight
Page history New page

labels

GitLab uses labels to organize both issues and merge requests. GHC uses this mechanism to track a variety of information. Here we document the conventions we use. For more general issue conventions, see the issue conventions page.

Here is

This list is machine-generated and always up to date, but it is long, and not semantically grouped.

Super-important note. In the definitive list, there are two links for each label: one for the issues with that label, and one for the merge requests with that label.

Markup: the markup ~debugger or ~"debugger" renders to a clickable label debugger leading to the issues with that label. (Question: what markup leads to MRs with that label?)

Classifying labels

The rest of this page describes the semantics of our label usage in GHC. It is human-written, and hence may not mention every label.

If you create a new label please do add it to this list, keeping the list in alphabetical order. Also, avoid using colors other than blue unless your label really needs to be noticed.

Types of issues

  • bug: This denotes an issue which describes a bug or infelicity
  • feature request: This denotes an issue which describes a desired new feature.
  • task: This denotes an issue which describes a task of some sort (e.g. a refactoring that should be undertaken, a test which should be introduced, etc.)

Types of bugs

These labels describe how a bug manifests. Usually every bug should be bear exactly one of the following.

Issue priority

These labels define the relative priority of issues. Priority here is determined by a combination of issue severity and prevalence.

  • Plow: Issues that are of low priority
  • Pnormal: Issues that are of normal priority
  • Phigh: Issues that are of high priority
  • Phighest: Issues that are of highest priority (e.g. a runtime crash or correctness issue affecting a large number of users)

Miscellaneous

  • developer experience: All things related to both the bells and whistles in the development process, and the things that may hamper the usage and understanding of the code-base outside of the documentation. CI, error messages and documentation already have their own labels, you may thus tag issues that are not linked to those with this label. It is about the joy of programming.
  • CI breakage: Denotes a bug that broke CI (this could likely be dropped; nothing should break CI now)
  • user-facing: Denotes a merge request which changes the interface exposed by GHC or its core libraries in a user-noticeable way. Merge requests so-marked trigger the head.hackage build jobs.
  • broken test: An issue due to which one or more tests in the test suite are marked as expect_broken
  • Trac import: Issues imported from GHC's old Trac instance
  • report impact: Issues affect GHC's adherence to the Haskell Report
  • needs CLC feedback: Issues which require feedback from the Core Libraries Committee

Issue lifecycle

These indicate various stages in the lifecycle of an issue.

  • needs triage: An issue that hasn't yet been triaged. This involves a maintainer applying the appropriate labels and weight.
  • info needed: Information is needed from the issue reporter
  • upstream: Things that require coordination with an upstream package

Backport status

These labels are to do with backporting of fixes to stable release branches.

  • backport needed:8.8: This denotes a merge request which should be backported to a 8.8 branch before the next release.
  • backport needed:8.10: This denotes a merge request which should be backported to a 8.10 branch before the next release.
  • ~"backport needed:8.12": This denotes a merge request which should be backported to a 8.12 branch before the next release.
  • backport: This denotes a merge request which backports a merge request to a stable branch. The merge request description should link to the MR or issue from which the backported patch came

Bug environmental scope

These labels identify the environments in which a bug will manifest.

Operating systems

Issues lacking of these labels are assumed to be reproducible on Linux.

  • macOS: Issues affecting Apple's macOS, iOS, of watchOS
  • Windows: Issues affecting Microsoft Windows

Architectures

Issues lacking of these labels are assumed to be reproducible on x86-64.

  • ARM: Issues affecting one of the ARM architectures (e.g. ARMv*, AArch32, or AArch64)
  • PowerPC: Issues affecting the PowerPC architecture
  • SPARC: Issues affecting the SPARC architecture

Other

  • clang: Bugs triggered by GHC's interaction with the Clang C compiler (e.g. on Darwin)
  • cpp: Bugs related to use of the C preprocessor
  • cross-compilation: Bugs which only show up during cross-compilation
  • unregisterised: Issues with GHC's unregisterised C backend
  • determinism: Issues of non-determinism in GHC's output (see #4012)

Subsystems

These labels identify compiler subsystems which are in some way implicated in a bug or touched by a merge request.

Optimisations

Non-compiler subsystems

External projects

These labels are generally relics of when GHC's bugtracker was also used to track issues in external projects. New issues with these projects should rather be filed against the appropriate upstream.

Language features

These labels identify user-visible language features which a bug is triggered by.

Language extensions

These labels correspond to the language extensions after which they are named.