"tracking issues" and other Issue management questions

help
1

From time to time I encounter minor annoyances in rust, and when I google them there's almost always an open PR for it. So there's the issue where someone reports it and there are discussions around it, but there's may also be a link somewhere in the comments to a "tracking issue". The tracking issue tend to have checkboxes, so the title "tracking" and the checkboxes make it pretty clear what it is: It's used to keep track of the progress of the issue being fixed.

With that said, I have some questions:

  • Who/what decides when a PR should get a tracking issue? Is it when the relevant team (lang, libs, etc) decide that the issue indeed needs to be fixed?
  • If one has something substantive to add regarding the actual issue, should it be to the original PR or should everything be moved to the tracking issue? Or is the tracking issue just used for noting things like "current blockers" and such?

And while I'm anyways asking about issues and process around them -- over the years I've encountered a few situations where things I would like to see be changed/fixed have patches which have a bunch of reviews that seem to have given the green light on the changes, but under the box to the right listing all the reviewers who have reviewed it there's a little text saying it needs 1 more reviewer, and these issues seem to be stuck on this. It's happened a few times so I've started to wonder if that last reviewer isn't actually a reviewer, but it's stuck on some other process. Of course right now I can't find one to illustrate what I mean, but I'd guess I've seen five or six of these over the years I've been using Rust.

If there has been no action taken on these issues for a few months, but the issue isn't closed -- is it considered rude to ping in the comments and ask what the current state of the issue is? I guess I'm in a round-about way also wondering if there are so many issues floating around that some issues which probably could be merged/closed get "lost".

Asking purely out of curiosity.

1 Like
2

Tracking issues are used to track work on and experience with an unstable feature behind a feature gate, as explained in the rustc dev guide. These may either be features that have come out of the RFCs process (with one tracking issue per accepted RFC usually), or from a PR adding a minor feature behind a feature gate. It isn't really tracking an issue to be fixed, rather it is tracking the progress towards stabilisation and providing a place to collect discussion about the feature (including linking any relevant issues or PRs).

There doesn't really seem to be much advice on that. Given that you said "minor annoyances", I imagine you're looking at tracking issues for small features such as adding a new function to the standard library. If it hasn't been merged yet, I would probably comment on the PR for the initial feature if there isn't much discussion at the tracking issue, since it could be changed before merging. If the original PR is merged, suggestions probably want to go in the tracking issue, since they would be changes to the existing (albeit unstable) feature, and may be relevant to standardisation of the feature. Big bugs may need their own issue opening, linked to the tracking issue, but looking at the issues for unstable features, most of those seem to be with quite large changes and involve finding things like ICEs or unsoundness or odd error messages, that come from use of a large unstable feature. I haven't really interacted with the process for contributing to Rust though, so this is just what I understand looking at it from the outside, and I could be wrong.

1 Like
3

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.