From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752485AbdJ3JRP (ORCPT ); Mon, 30 Oct 2017 05:17:15 -0400 Received: from mout.web.de ([212.227.17.12]:50413 "EHLO mout.web.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752057AbdJ3JRN (ORCPT ); Mon, 30 Oct 2017 05:17:13 -0400 Subject: Re: Adjustments for a lot of function implementations To: Hans Verkuil , Mauro Carvalho Chehab , linux-media@vger.kernel.org Cc: Jan Kara , Lorenzo Stoakes , Michal Hocko , Muralidharan Karicheri , Vaibhav Hiremath , LKML , kernel-janitors@vger.kernel.org References: <356f75b2-d303-7f10-b76c-95e2f686bd3c@xs4all.nl> From: SF Markus Elfring Message-ID: <14619198-bebe-d215-5324-a14fbc2103fb@users.sourceforge.net> Date: Mon, 30 Oct 2017 10:16:22 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <356f75b2-d303-7f10-b76c-95e2f686bd3c@xs4all.nl> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:OZQ8e4KiIUk4LmQ+JFs+UsvnLtGd+HOaD/8/GylWF+Q02SV9t2y UpkraXd4GCQJms1ykhwi+cJU44uGtFGNvge3kKzganGobZUMKCz8qd6WM/unazqWHdVBo31 TPrBDUO+QhvYUdRTSjM3JUTj0Hq36yLXWkGf7PTy1snwNSM7dL7clN5McTXHzOQUUG0B4BG 3vk0/iI5Ukje1/ehF15aQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:062BcdjUFrk=:+WMmh/Uz5pif+NS9zlzUOz qcHUX+7doze/khQjlcF5SJLemtSOJ9HUjxCnqTJN+m73aBha5u4bTBOSjqoZ093yxCOI1qe6e IXSphSfgsrO8gkAqGpnX30ZgFfsScgFsWO7zG3zeNRXyHHOIru1kEufnCUF31vWrUgu8wh1rN +fwiot64/+0k880AXTqwmu3HgpCLvU4v7/XBzbcKZhW6Np8FYBShSwBkmfqwNewaSYo/54sxk eXpOm56q0b7ACYB8bs+scMewcljKTngDNrXHgy7jClDdyXdthKLQ6FTKr676jBgf86BeBgIvL PIO9Ny4B5wHCASeqI0mieXujTzDRUHr8jpbiLPo9LIqxNSA3DCvWj9AygShoPL/J+V26SVBJh A0Q3Mx+8asCb6OeR4FO5pkGb3uw6JbkmoSbpFPw/K+yWS1NnYN3dQNzHaB2n9JxRbNc70627A 9FleGDFh4757FPAbNnkf/jXmGmBU1OWwbpZPAaz62Qk/2Fh10/MyzFuq5X6j1dkGOauGkORax DhdHGYhKtDVmMKAlGVEODS5Xb4iQiI5wheXHPrfJZ0vcp9Ysjk60JfHcF2Ctqzjaaq/2DGODg Sd8N2skbh+wDoa/DHebKz5K5j797n8AOMW+Lj5Ob+zgc1WLk9oEphbrNsv7WlEy3mpRaqnlIh oOEXBcvDvVzFs6Yk0x5KVq1+u//Ov7wlyc9hwj0xrWCguKrz2NzbhfjRHvN3s7bKMS+BdopsE iYNDwSwqarNv+luSXGEfxUuXLRb3bPjkPi+PmzW8KkqqI1AkKlDE0VVvHCBF6F3WQMys345wF dRIIzOybDa9m23n5jND/2HbqQpsutDvaUNSGPZWZxQX/dQ74ak= Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > 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