Recent searches
Search options
"[…] Instead of accepting my [#LinuxKernel] patch or guiding me towards a better solution, he went ahead and implemented his own fix, giving me credit only for reporting the issue […]
My first contribution to the [#Linux] #kernel was a really frustrating and discouraging experience, dealing with people who do not think it’s important to get proper recognition for your work. […]"
https://ariel-miculas.github.io/How-I-got-robbed-of-my-first-kernel-contribution/
1/ Side note: I sometimes wonder if…
2/…patches from new or rare contributors should have some kind of tag to indicate things like
(1) I have no interest in learning how to do things better, I just want it fixed; I'm thus happy if someone dramatically changes the patch or writes a better one.
(2) I'd really like to learn how to do this properly, hence would be grateful if someone could guide me somewhat.
Why? Well, misunderstandings here can be annoying and a waste of time for both sides (and lead to situations like the above).
Yeah, this is a tricky one! The reverse can also be an issue: for instance, I often feel bad for asking (potential) contributors to do more work when I ask them to rework stuff. I usually do so anyway, and don't write a fix myself until they've had a chance to do that (which some do and some don't).
@kernellogger as a kernel contributor, I've definitely found it frustrating when i send a patch to a new subsystem and get (often vague) feedback asking me to rework it. Usually im actively trying to learn about other parts of the kernel and being asked to learn this additional subsystem is just more of a burden to progress with the areas i care about.
in this case I'd generally prefer feedback that offers more context about the subsystem, although it's obviously hard to gauge levels here...
haha what about a tool that tells you how many patches someone has in the relevant subsystem and overall to the kernel?
"what about a tool that tells you how many patches": that's just a few fingertips away (or did I misunderstood what you meant?)
git log --oneline --author='gregkh@linuxfoundation.org' origin/master -- drivers/net/ | wc -l
@kernellogger hah yeah something like that. obviously it's bad to assume, but maybe if maintainers did checks like this when reviewing patches from new contributors it would help with finding the right tone - is this someone with no kernel experience or are they just new to this subsystem?
that being said, it probably comes down to bandwidth as it generally seems to these days
Of course it's silly and over complication. But at the same it makes something explicit that in an ideal world might be wise for everyone to make explicit, as people will forget to spell it out (and maintainers will forget to ask which of the two it is).