New label suggestion: awaiting release

[mmarchini]

So far, when a bug is confirmed and fixed, we do one of two things:

1. Close the issue as soon as the PR lands
2. Keep the issue open while we're waiting for a release

I don't think either approaches properly shows that an issue has been fixed already, but is not available on any releases yet. The first approach (closing the issue) might give the false impression that the fix is available on the latest releases already, which can cause confusion and frustration to users. The second approach requires users to read the issue (and usually multiple comments) before finding out the issue is fixed, just not released yet.

To help communicate this state, a awaiting release label could be used. It would be good to have automation around this label, but I think we can start with a simple manual label instead. I'm not entirely sure how this would work with issues that affect multiple release lines, but I'd love to hear suggestions. What do folks think?

[bnoordhuis]

The concept sounds good to me but I don't know how it should work. In -current fixes are released ASAP but in other release lines it's up to the releaser of duty whether it gets included. Sounds difficult to automate.

I treat the bug tracker as a TODO list and I therefore don't like keeping fixed issues open but I understand it can be useful to users. A label would let me filter with -label:"awaiting release" .

[targos]

I prefer to close issues as soon as they are fixed on master (or the staging branch if they only apply to a specific release line).

What about something like fixed-in-vx.y labels to support multiple release lines?

[targos]

Btw I'm not really fond of the idea if it cannot be automated. We already don't use manual labels correctly enough (for example, semver-minor is often forgotten).

[bnoordhuis]

What about something like fixed-in-vx.y labels to support multiple release lines?

GH has a limit on the number of labels and we're already at (or close) to that limit.

[jasnell]

GH has a limit on the number of labels and we're already at (or close) to that limit.

Side note: an audit / cleanup of existing labels may be worthwhile.

With regards to awaiting release, definitely not fond of keeping issues open. An alternative suggestion, if a way of automating it could be found, would be to maintain a project board.

[sam-github]

Its definitely useful to see what versions a bug affects, and what versions the fix has been released on. Wanting this info is pretty reasonable, but in the absence of automation, maintaining the labels will be lots of error prone work. So, I'm +1 for a label if it can be automated, but -1 for manual maintenance.

[mmarchini]

Unlikely that this can be properly automated, so I'll close it. Feel free to reopen if anyone still thinks it's a good idea.