On Mon, 30 Oct 2017, SF Markus Elfring wrote: > > 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) Just for the record, while this may work for media, it won't work for all subsystems. One will quickly get a complaint that the big patch needs to go into multiple trees. julia > > 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 > -- 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
