3 ms·

>Sorry, just because you found this trivially fixable array mismatch doesn't mean your buggy patch has to be accepted the way it is. I know reading is hard, bu

>Sorry, just because you found this trivially fixable array mismatch doesn't mean your buggy patch has to be accepted the way it is. I know reading is hard, but it's not an excuse to put words in other people's mouths. >>I told him that I would really appreciate if he could accept a patch from me, so that I could receive credit for fixing this issue and become a kernel contributor. I was also open to working with him, addressing his feedback and sending subsequent versions of patches.

fsdjkflsjfsoij 3y ago
So the maintainer now has to tutor this guy for god knows how long until he gets it right? All three issues brought up by kazinator are reasonable grounds for ignoring the patch. Do you think that the already overworked maintainers should have to spend significant amounts of their time tutoring every potential contributor? Are you going to pay them for that?
- SeenNotHeard 3y ago
  It doesn't sound like you've ever maintained an active free software project. It's not "tutoring" to perform a code review and request additional changes to the patch. That's a standard feedback mechanism in free software development. kazinator's analysis may be right, but it doesn't sound like it would have taken the maintainer more than a few minutes to explain his objections and given the contributor a chance to shore up his patch. There's plenty of examples in the history of the kernel project of much larger patches going round and round until they land. From kazinator's description, it's possible the patch could have been made ready in a single review round. > All three issues brought up by kazinator are reasonable grounds for ignoring the patch. The patch (and bug report) wasn't ignored. That's kind of the point.
- kazinator 3y ago
  Miculas is not dumb; he's obviously a self-starter who pulled the investigation together through gdb, and the kernel interface, plus surrounding research into the history of the problem. He got excited to close the array access problem and lost sight of the necessity to fix only that and not change anything else, like the bounds check on the index. All it needed was a nudge to put his attention to that detail.
nolist_policy 3y ago
He could just have asked as a review of the the maintainers patch[1], e.g. work with the maintaner to fix it. [1] https://lore.kernel.org/all/20220609133245.573565-1-mpe@ellerman.id.au/t/#u https://lore.kernel.org/all/20220609133245.573565-1-mpe@elle...
- hnfong 3y ago
  I honestly don't know how two people could "work together to fix it" for an apparently straightforward patch where less than 20 lines are changed...
Chris2048 3y ago
> I told him that.. Is this true though?

fsdjkflsjfsoij 3y ago

So the maintainer now has to tutor this guy for god knows how long until he gets it right? All three issues brought up by kazinator are reasonable grounds for ignoring the patch. Do you think that the already overworked maintainers should have to spend significant amounts of their time tutoring every potential contributor? Are you going to pay them for that?

SeenNotHeard 3y ago
It doesn't sound like you've ever maintained an active free software project. It's not "tutoring" to perform a code review and request additional changes to the patch. That's a standard feedback mechanism in free software development. kazinator's analysis may be right, but it doesn't sound like it would have taken the maintainer more than a few minutes to explain his objections and given the contributor a chance to shore up his patch. There's plenty of examples in the history of the kernel project of much larger patches going round and round until they land. From kazinator's description, it's possible the patch could have been made ready in a single review round. > All three issues brought up by kazinator are reasonable grounds for ignoring the patch. The patch (and bug report) wasn't ignored. That's kind of the point.
kazinator 3y ago
Miculas is not dumb; he's obviously a self-starter who pulled the investigation together through gdb, and the kernel interface, plus surrounding research into the history of the problem. He got excited to close the array access problem and lost sight of the necessity to fix only that and not change anything else, like the bounds check on the index. All it needed was a nudge to put his attention to that detail.

nolist_policy 3y ago

He could just have asked as a review of the the maintainers patch[1], e.g. work with the maintaner to fix it. [1] https://lore.kernel.org/all/20220609133245.573565-1-mpe@ellerman.id.au/t/#u https://lore.kernel.org/all/20220609133245.573565-1-mpe@elle...

hnfong 3y ago
I honestly don't know how two people could "work together to fix it" for an apparently straightforward patch where less than 20 lines are changed...

Chris2048 3y ago

> I told him that.. Is this true though?