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?

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.

Miculas is not dumb; he's obviously a self-starter who pulled the investigation together through gdb, and the kernel interface. 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.

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@elle...

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...

> I told him that..

Is this true though?