> While we do not mind cleanup patches, the way you post them (one fix per file) I find it safer in this way while I was browsing through the landscape of Linux software components. > is really annoying and takes us too much time to review. It is just the case that there are so many remaining open issues. > I'll take the "Fix a possible null pointer" patch since it is an actual bug fix, Thanks for a bit of change acceptance. > but will reject the others, not just this driver but all of them that are currently > pending in our patchwork (https://patchwork.linuxtv.org). Will any chances evolve to integrate 146 patches in any other combination? > Feel free to repost, but only if you organize the patch as either fixing the same type of > issue for a whole subdirectory (media/usb, media/pci, etc) Can we achieve an agreement on the shown change patterns? Is a consensus possible for involved update candidates? > or fixing all issues for a single driver. I find that I did this already. > Actual bug fixes (like the null pointer patch in this series) can still be posted as > separate patches, but cleanups shouldn't. I got an other software development opinion. > Just so you know, I'll reject any future patch series that do not follow these rules. > Just use common sense when posting these things in the future. Do we need to try any additional communication tools out? > I would also suggest that your time might be spent more productively if you would > work on some more useful projects. I hope that various change possibilities (from my selection) will become useful for more Linux users. How will the clarification evolve further? Regards, Markus -- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html