On Wed, Dec 29, 2021 at 03:45:12PM +0800, Dave Young wrote:
> BTW, I would suggest to wait for reviewers to response (eg. one week at
> least, or more due to the holidays) before updating another version
>
> Do not worry to miss the 5.17. I would say take it easy if it will
> miss then let's just leave with it and continue to work on the future
> improvements. I think one reason this issue takes too long time is that it was
> discussed some time but no followup and later people need to warm up
> again. Just keep it warm and continue to engage in the improvements, do
> not hurry for the specific mainline release.
Can you tell this to *all* patch submitters please?
I can't count the times where people simply hurry to send the new
revision just to get it in the next kernel, and make silly mistakes
while doing so. Or not think things straight and misdesign it all.
And what this causes is the opposite of what they wanna achieve - pissed
maintainers and ignored threads.
And they all *know* that the next kernel is around the corner. So why
the hell does it even matter when?
What most submitters fail to realize is, the moment your code hits
upstream, it becomes the maintainers' problem and submitters can relax.
But maintainers get to deal with this code forever. So after a while
maintainers learn that they either accept ready code and it all just
works or they make the mistake to take half-baked crap in and then they
themselves get to clean it up and fix it.
So maintainers learn quickly to push back.
But it is annoying and it would help immensely if submitters would
consider this and stop hurrying the code in but try to do a *good* job
first, design-wise and code-wise by thinking hard about what they're
trying to do.
Yeah, things could be a lot simpler and easier - it only takes a little
bit of effort...
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
_______________________________________________
kexec mailing list
kexec@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/kexec
