From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753214AbdJaI2z (ORCPT ); Tue, 31 Oct 2017 04:28:55 -0400 Received: from mout.web.de ([212.227.15.14]:54542 "EHLO mout.web.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752495AbdJaI2v (ORCPT ); Tue, 31 Oct 2017 04:28:51 -0400 Subject: Re: Adjustments for a lot of function implementations To: Hans Verkuil , Mauro Carvalho Chehab , linux-media@vger.kernel.org Cc: Julia Lawall , Jan Kara , Lorenzo Stoakes , Michal Hocko , Muralidharan Karicheri , LKML , kernel-janitors@vger.kernel.org References: <356f75b2-d303-7f10-b76c-95e2f686bd3c@xs4all.nl> <14619198-bebe-d215-5324-a14fbc2103fb@users.sourceforge.net> From: SF Markus Elfring Message-ID: Date: Tue, 31 Oct 2017 09:27:56 +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: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:I34B9blSKP8c07utQvN+jFmgOqDIon4YkZXAT5a1u5aPPx+zoqg UxOABqyLs6N1/xQL8H0wLsUrIqQ9E5FPly6unzUWa/L2HVpBOo8nJldbRnK7l+XgOPeijvW 1JNDgTRt6Rpt5pjiEyjKynYPnAjNsPU2r6w6bObDo/qWFjLdrfbfg/7C9G6HKEWNDgwOCX/ eVv9zHAYgXotAnb4owWeg== X-UI-Out-Filterresults: notjunk:1;V01:K0:Rd9oeVx5Wic=:QHwYQdUsD3p0frs6FbXnYc iajMppc8A49BxRaAg9/YJrP/x8AqNywjFhZ606gV7k3rUlFighBl8RQRaeXd2HpZpIJOXWwZY ur20+8vPMWGZqX21SIZ8tKSv64+RKPhEui82v0szb9+AaK+XwsYDcioS9bNfYAr0MYz0hm/Rz 8i2I1skp/yAIZZpYlkCiKIWYG8TVoPTua1QK6WB/cZpJYoUFu9C58+QpscDhGKmPq0yoEGwL8 9pHT5kZNfdeZJTPdlSrqU1N6BVSnonxQtlXB9La9KP/3/jsiW0uHxnqWA+VuLzZOomk4j+frc qB/UqU5nk0GktjNTjwyrJAmE1BB9PAk+gqBY2H9SjNSIUZHjG+i59wwiOdfcT+S22Dih4n0hw 6VkizMlllkKkfgnpzCv/IH8m+aJFYU7jRQ2Qo1qdwin5Kwib9CxLszUxab9K/rLc3FZpQtDZQ AwxLlMCAAUw8e3orJk2dRd8ZvensnZQTd1JjBSEzZ0hHls9n9PdAdAx3q4CLWVM8q6zU2e2Cr 0ExCcqKZU5f9KAFH0UjXW7O6ZIbiM9eu3AyXx4CKvo0fOfA2W4nXcGenM1flFrTZAiS0m63qe xh2NGVIu63SVtgDsp3C2aQxIq87sSe+x07nncNiudAYOber83xsL659W6mQbrLTi4kRfc4Ti0 myHf7OF2AiuyuQCSe8USmY67ewEjd8r67xfaTffHXPOtlx2DvDJv+Doq0NWocV9RJ9gmcXZG2 emKXwVzRybP06UDjsfslu9FG+awDvnmEylUfMqCVqFF8oCIiWlxE1wSf8qdbxmFmvbkeIl6BA d9L4QjeVgRc9kMANEGxf6LZsILd1tRSqS4BSW6L9PXk33fyIJE= Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org >>>> but will reject the others, not just this driver but all of them >>>> that are currently pending in our patchwork (https://patchwork.linuxtv.org). I find it very surprising that you rejected 146 useful update suggestions so easily. >>>> 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. > > For the record: this only applies to drivers/media. What does this software area make it so special in comparison to other Linux subsystems? > We discussed what do to with series like this during our media summit > last Friday and this was the conclusion of that. * Have you taken any other solution approaches into account than a quick “rejection”? * Could your reaction have been different if the remarkable number of change possibilities were sent by different authors (and not only me)? * How should possibly remaining disagreements about affected implementation details be resolved now? * Are you looking for further improvements around development tools like “patchwork” and “quilt”? * Will you accept increasing risks because of bigger patch sizes? >>>> or fixing all issues for a single driver. >>> >>> I find that I did this already. * Can such an information lead to differences in the preferred patch granularity? * How do you think about this detail? >>>> 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. How would you ever like to clean up stuff in affected source files which was accumulated (or preserved somehow) over years? >>>> Just so you know, I'll reject any future patch series that do not follow these rules. I guess that this handling will trigger more communication challenges. >>>> Just use common sense when posting these things in the future. Our “common sense” seems to be occasionally different in significant ways. >>>> I would also suggest that your time might be spent more productively >>>> if you would work on some more useful projects. I distribute my software development capacity over several areas. Does your wording indicate a questionable signal for further contributions? Regards, Markus