Hacker News Reader

Comment by stormbrew | Hacker News Reader

Is there some kind of cultural reason in the process of submitting patches to linux that someone else couldn't come along and, while giving due credit, do the style fixups on one or the other of the patches themselves and submit that as a v3/v2?

Like, why should every attempt start from scratch as people lose interest?

View on HN

That's exactly what I was mulling over in my head today (I'm the author of this blog post). If there's some way to simply provide a v3 of this patch while leaving the credit with the original author, I'd love to do it. I just didn't want to step on anybody's toes, and I don't know the etiquette. I think this kind of thing happens more often than we realize. I've seen similar situations before on other drivers.

Download the raw patch from lore.kernel.org, apply it with "git am", fix up the commit message with "git commit --amend", add your "Signed-off-by" below the existing one, submit with "git-send-email" or "git format-patch" + "msmtp".

That way the commit author remains the same because "git format-patch" includes a "From:" line in the message body which "git am" will interpret as the commit author when the maintainer applies the patch.

Your Signed-off-by is necessary to keep the DCO chain intact: https://www.kernel.org/doc/html/latest/process/submitting-pa...

However, that is now done: https://lore.kernel.org/netdev/086b426f44bc24360cc89476fe18d...

Thank you for the report.

Thank you! That is very useful to know for the future.

Honestly, fuck the ettiquite. Reubsmit the patch with fixedup styling and attribution to the original author. If it ruffles some feathers ? Who cares. Hopefully it shakes things up.

Yes, that's roughly the jist of my comment. There are often people with the skills to fix stuff that want to contribute back. But, there's typically a line for them. They fixed it for their own purposes, but are only willing to invest so much time in learning and aligning to project wishes and practices.

I get there are opposite examples of contributors just being contrary and rude, but some sort of workflow to quickly make good, but standards-flawed fixes compliant has merit.

Your idea of a simple way to let someone else take over a pull request seems good.

In general, a lot of contribution workflows are fairly daunting to newcomers–when I tried to submit a fairly small patch to the Linux kernel it took me a while before I figured out what to do, and even then I messed it up and it didn't end up going in. (Full disclaimer: I commented about it here and someone was extremely kind in sending me resources on how to actually do this. I haven't yet followed that advice, sorry!) But even with this, it's still really complicated to figure out how each project does things. I understand many don't really care about one-line patches, but it would be nice if this kind of thing (which I personally consider "outreach") was better supported.

Bravo. Sometimes those one-line patches are gold. I still use a one-line patch for a popular Perl serial/rs-232 module that some kind soul tried to contribute, but failed to get accepted. It's been that way for 10 years or so.

I have heard the other side, which is that many one-line patches require significant time from maintainers because it's often "hand-holding" to get them to where they need to be and often they are not really correct or have some other issues. But even with that I think the case of "maintainer abandoned this patch" or "maintainer is actively looking for new contributors but does not make it easy to get your foot in the door" is the more common one.

When submitting a pull request upstream on GitHub there’s the option (I believe enabled by default) to allow members of the upstream repository to push to your branch, presumably for just this reason of it needing a few tweaks.

In cases like this where a new contributor has a patch with a minor style issue, the code reviewer should probably just accept the patch and repeat it themselves. Or have a group of intermediate contributors who can clean up or shepherd patches across the finish line.

That feels like a pretty easy "shephard" feature that GitHub and/or GitLab could implement.

I don't think there's generally a cultural reason. It just doesn't happen all that often because the "someone else" coming along probably isn't familiar with the project workflow either so they don't know the right way to do it.

What does happen more often I think is that one of the maintainers or regular devs will make minor fixups as part of accepting the patch. (I do this for the project I work on for new contributions at least some of the time.) But that does take time, and usually the people working regularly on the project have a full todo list of stuff they care about or are paid to care about already. So if the patch is for an obscure and unloved area of the codebase (like, say, support for a networking protocol used only by ancient Macs) it's more likely to fall through the cracks simply because nobody working regularly on the project cares about that area. Niche use-cases which have users but no developers are fundamentally in trouble long-term, I think.

Reply on news.ycombinator.com