Repository navigation
New label suggestion: awaiting release #33571
Description
So far, when a bug is confirmed and fixed, we do one of two things:
- Close the issue as soon as the PR lands
- 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?
Activity
bnoordhuis commentedon May 27, 2020
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 commentedon May 27, 2020
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.ylabels to support multiple release lines?targos commentedon May 27, 2020
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 commentedon May 27, 2020
GH has a limit on the number of labels and we're already at (or close) to that limit.
jasnell commentedon May 27, 2020
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 commentedon May 27, 2020
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 commentedon Aug 5, 2020
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.