Why is the fix by the author inferior? By all we know it could even be better. Not taking sides, just pointing out that your response seems kinda biased against the author.
> Also, the only reason you put so much effort into this was to fix your own problem
Isn't this the case with most problems? Fix the problems that impact you first, then other ones. That's completely normal.
It very often happens in FOSS that a contribution is well-intentioned, but doesn't match all qualities of the project, and asking them to fix it vs. rewriting wastes a lot of time. I've seen this pattern several times before: First-time contributor delivers patch, reviewer thinks "The idea is great, but it's faster if I just rewrite it rather than give feedback."
Consequence is, first-time contributor will not contribute to this project again.
FOSS maintainers can learn some pedagogy here.
I tried having a patch rejected only to see the maintainer rewrite my patch that introduced bugs.
I have a similar experience with a bug fix I submitted and the decision to delay my fix to literally change the whole architecture of the project left a bad taste in my mouth. After that I stopped contributing to the project and just kept my fixes to myself.
It's especially annoying when the maintainer asks for help and pulls this. Architecture changes after proposing small fixes to projects has been a somewhat common occurrence for me.
Accepting drive-by patches carries an enormous cost. It’s very common to need to rewrite them substantially.
Regardless, this individual received a reported-by credit. That’s more than adequate.
"just fine" is not what we aim for. "just fine" is probably what they thought of the OpenSSL library before heartbleed.
> Accepting drive-by patches carries an enormous cost. It’s very common to need to rewrite them substantially.
Sure but it sounds like you're making a generalization about a specific instance you know nothing about. There doesn't seem to be an enormous cost detailed by the maintainer in the email thread. Just that he'd rather gatekeep the project and rob someone of the opportunity for contribution.
This individual wasn’t robbed of the opportunity for a contribution. He received credit for his contribution via a reported-by flag. It’s a tiny patch — all the work was in identifying the bug, which is what he received credit for.
He did something valuable, and has every right to write it up, but clearly has limited understanding of the development process he’s participating in. It was wildly inappropriate of him to of put anyone on blast in response to this.
In another situation, I was using an emulator and it didn't read a file correctly. I read its source code for the first time, I fixed it, in what I thought was the right way. I supplied the bug report and the patch. The maintainer thanked me and fixed it a different way - a way that wasn't obvious from their code, but was a better fit.
In another situation, I found a library that sticks out like a sore thumb and doesn't accept values that other libraries do (the standard they're all aiming for says the value is "implementation defined" so this is technically allowed but it annoys me). I raised a bug. I offered a patch. The maintainer had a bug up his ass about this particular value and told me he was changing nothing. Not much I can do about that.
In conclusion:
FOSS maintainers aren't endless fonts of personal validation for you. Some of them don't even want contributors. They already gave you the software for free, _and_ the legal means to fix it yourself. You can patch it, you can fork it. Your fork might be better than theirs!
They might accept your bug report. They might review your patch. They might accept your patch. They might mentor in you how their project works. They might devote all their time to contribution management and never have time to write their own project. Each of these takes their time and energy. They don't owe you any of that. Not every project is a popularity contest, not every project wants your help. This is all OK.
You are correct in that it is the maintainers's choice. No doubt about it. But now, a potential contributor who invested a significant amount of time in a problem clearly nobody else had solved up to that point, was snubbed. The work was capitalized on, used as a foundation for a solution, and not even a comment giving credit was given.
This sends a terrible message not only to them, but to future contributors as well on a project that needs a new generation of talent to perpetuate it. This isn't just any OSS project; this is the Linux kernel, something millions if not billions rely on. Scale up this behavior, and it won't end well.
It can be sustainable; not all FOSS projects need every possible contributor. Being a good leader is not a prerequisite, either. Direct cooperation isn’t even necessary!
The fact that source code is available allows anyone to fork and compete with the original authors. On average, only mismanaged projects will get out-competed by their forks.
Beyond the morality of doing this, there is a practical consideration of copyright issues. OP did that as part of his job. OP and his employer have some sort of agreement of ownership of these 30 lines of code and the maintainer putting his name on it and putting it into the kernel could someday be a problem.
The maintainer deemed it inferior and they are the one to decide. By posting on a security list, the maintainer went out of their way to give the issue critical priority, speedy processing and extra critical correctness review. We all like the feeling of credit, but this context is very important.
It's too bad the proposed fix wasn't good enough, but getting the issue resolved is always first priority, above getting claim to the fix.
Exactly, this is why a field "co-authored-by:" is a nice middle ground that allows for providing partial credit to the original author while maintaining maintainer's freedom to rewrite the whole damn thing.
There was no Signed-off-by in the original patch, and the rules say Co-developed-by also requires a Signed-off-by.
It was a security issue and was fixed ASAP, not waiting to hear back from the submitter.
https://kernel.org/doc/html/latest/process/submitting-patche...
That hasn't been proven, we need to see the patches.
It was decided by the maintainer, the only person who can make the decision.
> we need to see the patches.
... they are linked in the post.