I haven’t read it yet so maybe this opinion may be slightly off topic but I think there is nothing wrong Google Sending bug reports. It only gets fucked when they actually request features
I agree… I mean they are not forced to fix the issues, if the issue is obscure and not many people are affected, then there’s no reason why they can’t just mark it as “patches welcome” and leave it there. I feel this is a problem in the policy the project might have for prioritization, not really a problem in QA / issue report.
For context:
The latest episode was sparked after a Google AI agent found an especially obscure bug in FFmpeg. How obscure? This “medium impact issue in ffmpeg,” which the FFmpeg developers did patch, is “an issue with decoding LucasArts Smush codec, specifically the first 10-20 frames of Rebel Assault 2, a game from 1995.”
To me, the problem shouldn’t be the report, but categorizing it as “medium impact” if they think fixing it isn’t “a valuable use of an assembly programmer’s time”.
Also:
the former maintainer of libxml2 […] recently resigned from maintaining libxml2 because he had to “spend several hours each week dealing with security issues reported by third parties. Most of these issues aren’t critical, but it’s still a lot of work.
Would it be truely better if the issues wouldn’t be reported? what’s the difference between the issue not being reported and the issue not being fixed because it’s not seen as a priority?
what’s the difference between the issue not being reported and the issue not being fixed because it’s not seen as a priority
Triaging and investigation take time. Plus having a bunch of open security issues even if they’re not critical destroys public confidence in the software
Sure, but if it wasn’t triaged why consider it “medium impact”? I feel when tight on resources, it’s best to default to “low priority” for all issues whose effect (ie. to the end-user, or to the software depending on it) isn’t clearly scoped and explained by the reporter. If the reporters (or those affected) have not done the job to make it easy to quickly see why it’s important to have this fixed then it’s probably not so important for them to have it fixed. Some projects even have bots that automatically close issues whenever there has not been activity for a certain time (though I’d prefer labeling it / categorizing as “low engagement” or something so it can be filtered out when swamped, instead of simply closing it).
About “public confidence”, I feel that this would rather be “misplaced confidence” if it’s based on a number that is “massaged” to hide issues. Also this is an open source project we are talking about, there isn’t an investment fund behind it or a need for people to have absolute loyalty or blind trust. The code is objectively there, the trust should never be blind. If there wasn’t a long list of reports I’d be more suspicious of a project as popular, frequently updated & ubiquitous as ffmpeg. Specially if they are (allegedly) not triaged. Anyone who decides to choose ffmpeg based on the number of issues open without actually investigating from their end how relevant that number actually is… well… they can go look for a different software.
I haven’t read it yet so maybe this opinion may be slightly off topic but I think there is nothing wrong Google Sending bug reports. It only gets fucked when they actually request features
Google spent money to find bugs but won’t spend money to fix them. That simply makes the devs’ lives worse. It’s an asshole move.
I agree… I mean they are not forced to fix the issues, if the issue is obscure and not many people are affected, then there’s no reason why they can’t just mark it as “patches welcome” and leave it there. I feel this is a problem in the policy the project might have for prioritization, not really a problem in QA / issue report.
For context:
To me, the problem shouldn’t be the report, but categorizing it as “medium impact” if they think fixing it isn’t “a valuable use of an assembly programmer’s time”.
Also:
Would it be truely better if the issues wouldn’t be reported? what’s the difference between the issue not being reported and the issue not being fixed because it’s not seen as a priority?
Triaging and investigation take time. Plus having a bunch of open security issues even if they’re not critical destroys public confidence in the software
Sure, but if it wasn’t triaged why consider it “medium impact”? I feel when tight on resources, it’s best to default to “low priority” for all issues whose effect (ie. to the end-user, or to the software depending on it) isn’t clearly scoped and explained by the reporter. If the reporters (or those affected) have not done the job to make it easy to quickly see why it’s important to have this fixed then it’s probably not so important for them to have it fixed. Some projects even have bots that automatically close issues whenever there has not been activity for a certain time (though I’d prefer labeling it / categorizing as “low engagement” or something so it can be filtered out when swamped, instead of simply closing it).
About “public confidence”, I feel that this would rather be “misplaced confidence” if it’s based on a number that is “massaged” to hide issues. Also this is an open source project we are talking about, there isn’t an investment fund behind it or a need for people to have absolute loyalty or blind trust. The code is objectively there, the trust should never be blind. If there wasn’t a long list of reports I’d be more suspicious of a project as popular, frequently updated & ubiquitous as ffmpeg. Specially if they are (allegedly) not triaged. Anyone who decides to choose ffmpeg based on the number of issues open without actually investigating from their end how relevant that number actually is… well… they can go look for a different software.