Weight field in issues too fine grained?

Ömer Sinan Ağacan omeragacan at gmail.com
Tue Jul 2 14:20:42 UTC 2019


I think we may want two different weights "high" and "highest".

- Highest: regressions, incorrect results, runtime panics/crashes. These are
  release blockers.
- High: other bugs

Other than that this sounds good to me.

I don't remember how many kinds of priorities we had in trac but IIRC it used to
work well, I think we can just copy the old priorities as labels.

Ömer

Ben Gamari <ben at smart-cactus.org>, 2 Tem 2019 Sal, 16:58 tarihinde şunu yazdı:
>
> Matthew Pickering <matthewtpickering at gmail.com> writes:
>
> > It isn't possible to change how the weight field works but as Bryan
> > points out we could use some of the more advanced label features.
> >
> > A scoped label (https://docs.gitlab.com/ee/user/project/labels.html#scoped-labels-premium)
> > could be suitable for weight so that it is enforced that each issue
> > only has one weight.
> >
> > Currently my understanding of weight is that
> >
> > 1. (Obviously) hIgh priority issues are marked as 10
> > 2. (Obviously) low priority issues are marked as 3
> > 3. Everything else is left as
> >
> Right. I would suggest that we convert the weight field into two
> (mutually exclusive) labels:
>
>  * P::High would be category (1)
>  * P::Low would be category (2)
>  * No P::* label would imply categoy (3)
>
> Does this sound reasonable to everyone? I could cobble together a script
> to make this change in about 10 minutes if so.
>
> Cheers,
>
> - Ben
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


More information about the ghc-devs mailing list