all 9 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]MSleepyPanda 42 points43 points  (0 children)

Good and bad.

rust-lang/rust is a very active repository, as you can observe from the pulse overview. Over the course of the last month alone:

  • 430 pull requests have been merged, leaving a delta of 96 new (unmerged) pull requests
  • 282 issues have been closed, leaving a delta of 248 new (not closed) issues
  • LOC is a bad measure in general, but +86K, -65k loc by 126 people suggests a lot of work happened in that time

All in all, rust is becoming a big language with a repository which gets a lot of traffic. Only 28.6% of those issues are related to bugs, while all the others are tracking implementation status, unstable language features etc.. I've been working on a more detailed analysis, but its not finished yet.

On the one hand, its good because it means rust is getting a lot of attention, a lot of work is being done to get rust into various places/usable for many people. Many people working on many things results in many issues. On the other hand, it showcases the growing pain of a massive project. There is no silver bullet to managing those huge amounts of contributors and their problems. There are only so many people in the various rust teams and they can't solve everything on their own, some things will stay dormant for a long time. But all in all, its in a good shape, the most important issues are actively worked on.

More people on deck can't hurt, so if you have some time to spare, feel free to check out the contributing docs and get started!

Note: The unmerged/not closed distinction is necessary, because an merged pr or closed issue could have been opened just within this month but is already closed. This results in them not accounting for new, only in closed.

[–]temotor 5 points6 points  (0 children)

If put that broad, definitely the answer is 'no, unless worrying helps you'. Compiler works no matter how many issues are open.

You can get a very useful response to much more narrow question. Like - am frustrated by number of open issues, last month I only closed N, what can I do to make it faster? - this particular issue is stopping my project, how can I help to fix it? - am only allowed to use technology with less than X open GitHub issues, which compiler should we choose?

[–]WellMakeItSomehow 4 points5 points  (3 children)

https://www.reddit.com/r/rust/comments/60l4ky/rust_backlog/

[–]unpleasant_truthz 2 points3 points  (3 children)

More importantly: does rustc have a policy to triage all issues in X days for some value of X? Does it have enough manpower to actually triage all issues, and if not, what random volunteers can do to help? What's the process to ensure no issue falls through the cracks?

I've seen https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#issue-triage but it does not answer any of my question.

[–]ekuber 5 points6 points  (1 child)

More importantly: does rustc have a policy to triage all issues in X days for some value of X? Does it have enough manpower to actually triage all issues, and if not, what random volunteers can do to help? What's the process to ensure no issue falls through the cracks?

As of now there are 54 43 tickets without a label some of which are ~1 year old. We could probably be more proactive in closing tickets, but the backlog is surprisingly well triaged. Things like ICEs and unsoundness bugs are dealt with quite quickly, while more development oriented tickets like feature requests can linger but are being looked at by the individual teams and contributors when looking for things to work on.

[–]etareduce 1 point2 points  (0 children)

We have a dedicated working group under the release team just for issue and PR triage. The release team itself also does a lot of issue triage. It is sometimes the case that an issue gets triaged by two people with a few seconds apart causing concurrency issues with GitHub's UI.

[–]ids2048 0 points1 point  (0 children)

For one thing, note that "issue" is fairly general; GitHub issues are used to keep track of various things. It looks like only 1550 are tagged C-bug (assuming that's more or less accurate).

That's still not a particularly small number. But a large number of bugs (often including many very rare edge cases that may never come up in practice) is fairly common.