4 ms·

As jwz put it > This is, I think, the most common way for my bug reports to open source software projects to ever become closed. I report bugs; they go unread

As jwz put it > This is, I think, the most common way for my bug reports to open source software projects to ever become closed. I report bugs; they go unread for a year, sometimes two; and then (surprise!) that module is rewritten from scratch—and the new maintainer can’t be bothered to check whether his new version has actually solved any of the known problems that existed in the previous version.

hackermatic 3y ago
It's like that with security findings, too.
neilv 3y ago
And a variation on that: the issue was reported against one major release, but a new major release (just incremental changes, not rewrite) is coming out, so close all issues against the old release, because the problem might no longer exist.
- RaisingSpear 3y ago
  Or simply: > report issue > issue is automatically closed 6 months later due to lack of activity ...with absolutely no change to or comment on the issue.
jauntywundrkind 3y ago
Make a PR with some tests that should pass, but are instead marked skipped. That way when the rebuild comes around, there's an easy path for the rebuild to see how it's doing, see if things are at all improved. If you care about it, you should put a test on it.
- erik_seaberg 3y ago
  I’m probably not enough of an expert on their code to write that unit test. And I don’t have much faith in a team who blindly closes bugs to unskip tests and upgrade them to the new API.
- hedora 3y ago
  How would help with jwz’s issue? He’s specifically talking about projects that just reimplement all the bugs from scratch in a new, incompatible code base. Such teams certainly don’t port passing unit tests, let alone skipped ones! For the full article, search for: jwz cadt
IshKebab 3y ago
This is bullshit. I've submitted hundreds of bugs to open source projects. This situation happens but it is extremely rare. Much less common than the bug being fixed, ignored, or closed by bloody stalebot.
turquoisevar 3y ago
Wouldn’t it be more reasonable for projects with few maintainers, or even run solo, to have the individuals who reported a bug to each spend 10-15 minutes to validate if the issue still exists instead of the sole maintainer having to spend days if not weeks to do the validation? Especially considering that the reporter is likely better attuned to observing the bug if it’s a bit more fickle or complex than the maintainer who may or may not be able to reproduce it on their end to begin with? This might shift a bit when there’s a bigger team involved or when it’s a companion project to a commercial service. What I tend to see with many (F)OSS projects is that very few are willing to roll up their sleeves while simultaneously spending significant amount of time to make it known how essential the project is to them, making demands and giving copious suggestions. The vast majority just create new issues to make their wishlist known and/or supply a very vague bug report. A subset of them might bother to submit a decent bug report and that’s about the extent their willingness to contribute goes. Personally I don’t have the character to maintain a project simply due to not having the will to handle most of the comments I often see in a diplomatic manner. That said, I do always try to track down the cause of an issue and submit a PR to fix the issue I’m reporting in an effort to do my part.
xnx 3y ago
Also my experience for closed source software projects.

hackermatic 3y ago

It's like that with security findings, too.

neilv 3y ago

And a variation on that: the issue was reported against one major release, but a new major release (just incremental changes, not rewrite) is coming out, so close all issues against the old release, because the problem might no longer exist.

RaisingSpear 3y ago
Or simply: > report issue > issue is automatically closed 6 months later due to lack of activity ...with absolutely no change to or comment on the issue.

jauntywundrkind 3y ago

Make a PR with some tests that should pass, but are instead marked skipped. That way when the rebuild comes around, there's an easy path for the rebuild to see how it's doing, see if things are at all improved. If you care about it, you should put a test on it.

erik_seaberg 3y ago
I’m probably not enough of an expert on their code to write that unit test. And I don’t have much faith in a team who blindly closes bugs to unskip tests and upgrade them to the new API.
hedora 3y ago
How would help with jwz’s issue? He’s specifically talking about projects that just reimplement all the bugs from scratch in a new, incompatible code base. Such teams certainly don’t port passing unit tests, let alone skipped ones! For the full article, search for: jwz cadt

IshKebab 3y ago

This is bullshit. I've submitted hundreds of bugs to open source projects. This situation happens but it is extremely rare. Much less common than the bug being fixed, ignored, or closed by bloody stalebot.

turquoisevar 3y ago

Wouldn’t it be more reasonable for projects with few maintainers, or even run solo, to have the individuals who reported a bug to each spend 10-15 minutes to validate if the issue still exists instead of the sole maintainer having to spend days if not weeks to do the validation? Especially considering that the reporter is likely better attuned to observing the bug if it’s a bit more fickle or complex than the maintainer who may or may not be able to reproduce it on their end to begin with? This might shift a bit when there’s a bigger team involved or when it’s a companion project to a commercial service. What I tend to see with many (F)OSS projects is that very few are willing to roll up their sleeves while simultaneously spending significant amount of time to make it known how essential the project is to them, making demands and giving copious suggestions. The vast majority just create new issues to make their wishlist known and/or supply a very vague bug report. A subset of them might bother to submit a decent bug report and that’s about the extent their willingness to contribute goes. Personally I don’t have the character to maintain a project simply due to not having the will to handle most of the comments I often see in a diplomatic manner. That said, I do always try to track down the cause of an issue and submit a PR to fix the issue I’m reporting in an effort to do my part.

xnx 3y ago

Also my experience for closed source software projects.