Maybe it would be better to postpone a bit committing new things and divert more dev time to sorting out more existing tickets?
The number of open tickets at Issues · pytorch/pytorch · GitHub is 11,362.
The number of open tickets at Issues · tensorflow/tensorflow · GitHub is 1,920.
The number of open tickets at Issues · microsoft/vscode · GitHub is 7,046.
You get the idea.
1 Like
I was wrong that it +5k opened tickets.
That number is shown on https://github.com/llvm/llvm-project/
After enter to issue tab it is possible to see 20 258 still opened tickets 
Nope I don’t get that.
Please explain.
There’s a false (implicit) premise in your (strange) rhetorical question: lots of tickets and new features are (or should be) mutually exclusive.
2 Likes
If you want to help with the set of issues around clang at least you can see Triaging old Clang bugs
Many of those issues are probably long fixed, or are duplicates and such.
Without personally knowing much about how to actually debug errors, I have been able to clear out a few dozen issues by simply recreating them and finding which version they have been fixed in.
4 Likes
llvm-project has over 20k open tickets. This is a good thing? I don’t think so. I think the premise is more that a high open ticket count correlates with some inattention to (a) users, (b) quality. And it’s a given that if you’re spending your time on new features, you’re unlikely to be spending time addressing open tickets; the project mostly does not use tickets to track to-do lists.
3 Likes
Some of these issues came from bugzilla migration that accumulated there over 20+ years of LLVM history. So, a good cleanup of old issues is well-desired. On the good side, we’re having 40k closed issues!
2 Likes
I very much do not like the interjection of even more claims when the primary argument hasn’t been adjudicated. But okay:
This is a good thing?
Good or bad is a matter of ethics and those are community-dependent - as far as I can tell this community (and many others, cf. this response) are fine with this state of affairs.
Moving on from normative claims:
I think the premise is more that a high open ticket count correlates with some inattention to (a) users, (b) quality
I think you intended for the word correlation to do a lot work on your behalf but it infact casts serious doubt on the force of your overall rhetorical purpose: if indeed the relationship is correlational and not causal then fixing/triaging tickets will have absolutely no effect on “attention to users” and “attention to quality”.
And it’s a given that if you’re spending your time on new features, you’re unlikely to be spending time addressing open tickets
There’s that equivocation again: unlikely. It should be self-evident that there are manifold circumstances under which this implication fails to be true; for example, when new features obviate old issues/bugs. Even more to the point, your own comment here alludes to an excluded-middle: the project possibly does not use tickets to prioritize users and quality! It’s quite possible that the project uses an alternative medium to prioritize the issues raised by the tickets and simply does not track the tickets themselves. This is especially germaine to us few debating this matter on just such an alternative medium.
So really, on close consideration, the claims presented here are specious - plausible but ultimately fallacious.
Okay speaking seriously now: I fail to ever see the point in coming to an open space/community/project and complaining that the project isn’t doing enough to either a) meet someone’s needs b) attain some standard. If you feel there’s something amiss with the ratio of tickets to new features then by all means jump in! Start triaging! Start patching! Be the change you want to see in the world! And if you do it well, and you do it graciously, the community will be greatful. But otherwise “Whereof one cannot speak, thereof one must be silent.”
I’d like to avoid focusing on number of opened issues, focusing on treating old bugs seriously instead. In my experience with old Clang bugs, 1 out of 10 old bugs still reproduce.
2 Likes
Unsubstantiated new claims? 
You’re entitled to your opinions but you could state them in a kinder way.
Meeting someone’s needs is pretty much what the project is all about, no? My contributions are all (well, mostly) about meeting my employer’s needs. And the project certainly has standards that it tries to attain. Discussions about what the needs are, how to meet them, and what standards to apply are discussions we have all the time.
If you don’t “ever see the point” and insist on complaining about those discussions, let me point out that no one is making you participate in them.
6 Likes
Trying to get back to a more productive answer to the original question (in line with @pogo59 and @akorobeynikov ), high tickets count might indicate a combination of:
- we’re not triaging tickets enough,
- we’re not prioritizing fixing issues reported by users,
- we’re not good at closing tickets when a bug has been fixed (and a large part of this is that bugs are independently found and the person fixing it does not even know about the ticket!)
- a ticket does not mean “a bug”, it can also be a feature request or other things.
Now in the context of a highly heterogeneous projects like LLVM (many subprojects and many contributors spread around a number of organization). Also LLVM is a collection of libraries, as well as toolchain components, and it is used in so many different scenario that it is bound to have many bugs that only exist in very specific deployment situation: but LLVM rely on whoever is packaging these to contribute back bug-fixes.
I don’t think it makes sense to make broad statement like “we’re doing too much of feature work and not enough bug fixes”. It might be different if we were looking at clang bug specifically tags as standard defects and making claiming about “how much we care about being c++ standard compliant”.
The “feature vs bug” statement may work in the context of a small team working on a well defined project (I would even say “product”), this isn’t the case here and looking at the bug tracker globally does not say a lot about the project and its community I believe (other than: we’re not using the bug tracker as a fundamental tracking tool universally, some subproject may).
12 Likes
More likely lack of interaction and bad quality.
That is another issue that this heterogenic causes that all issue tickets are on single pile and no one knows how many tickets are against each subsystem.
You may try to filter by label, for example here are the 34 tickets about crashes in MLIR: Issues · llvm/llvm-project · GitHub
Note that the reporter seems to use some sort of fuzzer on test passes (that is: this passes aren’t even part of the distribution!), they don’t correlate to any real world uses that we know of, so they are unlikely to get prioritized.
We could auto-close them after 1y, that would reduce the count, but that would be artificial and not reflect on the quality of the software in any way.
3 Likes
I think the incoming rate is also impossible to keep up with. I file an issue, and less than a day later it’s already pushed to the second page of issues ordered by newly created.
1 Like
Back in May, I remember Insides tab suggesting a 1:1 ratio between opened and closed issues for any available period (1 day, 3 days, a week, a month).
There are no tracking issues. The issues are complains about the project: bugs and features requests. The number is too high. It makes the project look bad. There should be more effort in closing/rejecting issues.
Currently, it’s 2:1 in favour of closed issues for the last week/month. This suggests at least some degree of issue reduction (net minus of almost 400 open bugs over the last 31 days).
I think auto-closing issues is problematic (and often seen as hostile to reporters), but on the other end of the spectrum, the amount of care in closing issues suggested in Triaging old Clang bugs is perhaps a tad excessive even though it is laudable (e.g. if a bug doesn’t reproduce on main, I think it’d be valid to close, as a pragmatic trade-off that takes old issues seriously but leans towards cleaning up the tracker).
The larger issue is IMO that most people are paid (or at least more interested) to work on features, and cleaning up the backlog is a hard sell for that, even though it’s really necessary long-term. The backlog would look quite different if people spent 5-10% of their weekly LLVM time on the bug tracker (and other tech debt).
Agree. For instance, a crash report with reproducer attached should be enough for us to treat the report seriously, even an old one.
I’d agree with you two months ago, but my instance of Compiler Explorer with assertion builds of Clang showcased how the right tooling can improve quality and speed of triaging (in this case for crash reports).
In my experience, the time-consuming part of triaging is test case reduction (even with C-Reduce), which is needed sometimes. Labeling issues correctly or pulling couple of tricks in Compiler Explorer in order to reproduce pales in comparison with that.
I consider labeling important, because our big issue database can become a good set of regression tests. We’ve already ran into a situation of a decade-old crash resurfacing recently because of lack of such regression testing (GH17283).
I agree with that, but I’d like to point out that pool of bugs that can be triaged without decent background knowledge is limited. Crashes are nice in this regard, which is the reason I work through them, but I estimate those as couple of thousands, and we worked through hundreds of them already.
At some not-so-distant point we’ll be facing a choice between taking bugs less seriously or eating up already scarce reviewer time to continue taking them seriously.
1 Like