Comment by NicuCalcea
4 days ago
> Other people who would like to have this bug fixed can't commit it from their name or reuse the code present in the mail list from assumingly sanctioned entity
> The bug is forced to be fixed in some other way, not in a way it has been fixed by the bug fix contributor
I'm not quite following, why is this the case? If another non-Russian contributor submits the same fix, why wouldn't it be merged? If the project is GPL-licensed, surely that means the author of the fix doesn't retain any "patent" rights as the author describes it?
I suppose it's not about patents or copyright but rather the fear that a re-submitted patch can't be trusted because the original patch is considered not trustworthy, or that the resubmission is carried out by the sanction person itself or a friend under an email address that doesn't fall under the sanctions. Either way, it could be seen as a liability.
Suppose the issue was an incorrect constant used, e.g. a change from a 0 to a 1.
As long as somebody verifies that is the correct thing to do and submits a patch, I can't see anybody would complain about that. How else would you fix it?
But that's not what the article is complaining about. From their description, they removed a simple workaround, introduced a whole different approach to sending a message, relying instead on a watchdog timer. That's not a trivial refactor, and there could easily be a bug hidden in the change, intentional or not. That is the real issue.
Aside from anything else, the author was complaining about something going from no delay to having a 1ms delay, which broke his device. His solution was to rewrite it such that there was a variable delay, from 0ms to 275ms. That sounds even less desirable. A quarter of a second delay could easily be enough to cause data corruption on a drive after unmounting and before unplugging, if its logic on how to ensure data was flushed relied on that feature.
Such a major change needs extensive testing on basically most USB devices before it's randomly integrated into the kernel, especially when the fix it's undoing is over 20 years old, so the hardware it affects must be even older than that (and nobody else has used it in the last 20 years) and so most of the maintainers won't even be able to test whether the fix works anyway. It's just a big change explained away by a "trust me bro".