From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 68387C433DF for ; Thu, 18 Jun 2020 00:40:47 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 4C19121556 for ; Thu, 18 Jun 2020 00:40:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726919AbgFRAkp (ORCPT ); Wed, 17 Jun 2020 20:40:45 -0400 Received: from kvm5.telegraphics.com.au ([98.124.60.144]:33172 "EHLO kvm5.telegraphics.com.au" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726845AbgFRAkp (ORCPT ); Wed, 17 Jun 2020 20:40:45 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by kvm5.telegraphics.com.au (Postfix) with ESMTP id 2C6062073E; Wed, 17 Jun 2020 20:40:40 -0400 (EDT) Date: Thu, 18 Jun 2020 10:40:37 +1000 (AEST) From: Finn Thain To: "Martin K. Petersen" cc: Chris Boot , James Bottomley , Johannes Thumshirn , Bart Van Assche , "linuxppc-dev@lists.ozlabs.org" , "target-devel@vger.kernel.org" , "linux-scsi@vger.kernel.org" , "linux1394-devel@lists.sourceforge.net" , "linux-kernel@vger.kernel.org" , Chuhong Yuan , Nicholas Bellinger , Stefan Richter Subject: Re: [PATCH] scsi: target/sbp: remove firewire SBP target driver In-Reply-To: Message-ID: References: <01020172acd3d10f-3964f076-a820-43fc-9494-3f3946e9b7b5-000000@eu-west-1.amazonses.com> <7ad14946-5c25-fc49-1e48-72d37a607832@boo.tc> <8da0c285-d707-a3d2-063e-472af5cc560f@boo.tc> <8cbab988-fba7-8e27-7faf-9f7aa36ca235@acm.org> <1592321667.4394.5.camel@HansenPartnership.com> <5e512185-45d1-61eb-9bec-91e9f9d53ea3@boo.tc> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 16 Jun 2020, Martin K. Petersen wrote: > > However, keeping code around is not free. Right. And removing code isn't free either, if it forces people to find workarounds. > Core interfaces change frequently. Nobody enjoys having to tweak host > templates for 50 devices they have never even heard about. And yet some people seem to enjoy writing patches that are as trivial as they are invasive... You seem to be making an argument for more automation here, not an argument for less code. Or is there some upper bound to the size of the kernel, that might be lifted by adding maintainers? (Can you deliver a better product by adding more developers to your project?) > Also, we now live in a reality where there is a constant barrage of > build bots and code analyzers sending mail. So the effective cost of > keeping code around in the tree is going up. But if maintenance cost rises due to good analysis, the value of the code should rise too. So what's the problem? It seems to me that the real problem is too many analyses that generate pedantic noise and no tangible improvement in code quality or value. > I get a substantial amount of code analysis mail about drivers nobody > have touched in a decade or more. > When stable, mature code fails analysis, the analysis is also questionable (in the absence of real examples). > Consequently, I am much more inclined to remove drivers than I have been > in the past. But I am also very happy to bring them back if somebody > uses them or - even better - are willing to step up and maintain them. > You seem to be saying that 1) a driver should be removed when it no longer meets the present threshold for code quality and 2) that a low quality driver is eligible for re-addition because someone wants to use it. I don't think you can have it both ways. > I don't particularly like the notion of a driver being orphaned because > all that really means is that the driver transitions from being (at > least partially) somebody else's problem to being mine and mine alone. > Yes it's your problem but only on a best-effort basis. Many issues detected by automatic analyzers can be fixed with automatic code transformation tools. This kind of solution works tree-wide, so even if some defect in your driver is "yours and yours alone", the solution will probably come from others. This email, like yours, is just hand-waving. So feel free to ignore it or (preferably) provide evidence of real defects. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Finn Thain Date: Thu, 18 Jun 2020 00:40:37 +0000 Subject: Re: [PATCH] scsi: target/sbp: remove firewire SBP target driver Message-Id: List-Id: References: <01020172acd3d10f-3964f076-a820-43fc-9494-3f3946e9b7b5-000000@eu-west-1.amazonses.com> <7ad14946-5c25-fc49-1e48-72d37a607832@boo.tc> <8da0c285-d707-a3d2-063e-472af5cc560f@boo.tc> <8cbab988-fba7-8e27-7faf-9f7aa36ca235@acm.org> <1592321667.4394.5.camel@HansenPartnership.com> <5e512185-45d1-61eb-9bec-91e9f9d53ea3@boo.tc> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: "Martin K. Petersen" Cc: Chris Boot , James Bottomley , Johannes Thumshirn , Bart Van Assche , "linuxppc-dev@lists.ozlabs.org" , "target-devel@vger.kernel.org" , "linux-scsi@vger.kernel.org" , "linux1394-devel@lists.sourceforge.net" , "linux-kernel@vger.kernel.org" , Chuhong Yuan , Nicholas Bellinger , Stefan Richter On Tue, 16 Jun 2020, Martin K. Petersen wrote: > > However, keeping code around is not free. Right. And removing code isn't free either, if it forces people to find workarounds. > Core interfaces change frequently. Nobody enjoys having to tweak host > templates for 50 devices they have never even heard about. And yet some people seem to enjoy writing patches that are as trivial as they are invasive... You seem to be making an argument for more automation here, not an argument for less code. Or is there some upper bound to the size of the kernel, that might be lifted by adding maintainers? (Can you deliver a better product by adding more developers to your project?) > Also, we now live in a reality where there is a constant barrage of > build bots and code analyzers sending mail. So the effective cost of > keeping code around in the tree is going up. But if maintenance cost rises due to good analysis, the value of the code should rise too. So what's the problem? It seems to me that the real problem is too many analyses that generate pedantic noise and no tangible improvement in code quality or value. > I get a substantial amount of code analysis mail about drivers nobody > have touched in a decade or more. > When stable, mature code fails analysis, the analysis is also questionable (in the absence of real examples). > Consequently, I am much more inclined to remove drivers than I have been > in the past. But I am also very happy to bring them back if somebody > uses them or - even better - are willing to step up and maintain them. > You seem to be saying that 1) a driver should be removed when it no longer meets the present threshold for code quality and 2) that a low quality driver is eligible for re-addition because someone wants to use it. I don't think you can have it both ways. > I don't particularly like the notion of a driver being orphaned because > all that really means is that the driver transitions from being (at > least partially) somebody else's problem to being mine and mine alone. > Yes it's your problem but only on a best-effort basis. Many issues detected by automatic analyzers can be fixed with automatic code transformation tools. This kind of solution works tree-wide, so even if some defect in your driver is "yours and yours alone", the solution will probably come from others. This email, like yours, is just hand-waving. So feel free to ignore it or (preferably) provide evidence of real defects. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9001CC433E0 for ; Thu, 18 Jun 2020 00:42:26 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [203.11.71.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id F374321556 for ; Thu, 18 Jun 2020 00:42:25 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org F374321556 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=telegraphics.com.au Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Received: from bilbo.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 49nNSH50XtzDr13 for ; Thu, 18 Jun 2020 10:42:23 +1000 (AEST) Authentication-Results: lists.ozlabs.org; spf=none (no SPF record) smtp.mailfrom=telegraphics.com.au (client-ip=98.124.60.144; helo=kvm5.telegraphics.com.au; envelope-from=fthain@telegraphics.com.au; receiver=) Authentication-Results: lists.ozlabs.org; dmarc=none (p=none dis=none) header.from=telegraphics.com.au Received: from kvm5.telegraphics.com.au (kvm5.telegraphics.com.au [98.124.60.144]) by lists.ozlabs.org (Postfix) with ESMTP id 49nNQS54RCzDqvH for ; Thu, 18 Jun 2020 10:40:48 +1000 (AEST) Received: from localhost (localhost.localdomain [127.0.0.1]) by kvm5.telegraphics.com.au (Postfix) with ESMTP id 2C6062073E; Wed, 17 Jun 2020 20:40:40 -0400 (EDT) Date: Thu, 18 Jun 2020 10:40:37 +1000 (AEST) From: Finn Thain To: "Martin K. Petersen" Subject: Re: [PATCH] scsi: target/sbp: remove firewire SBP target driver In-Reply-To: Message-ID: References: <01020172acd3d10f-3964f076-a820-43fc-9494-3f3946e9b7b5-000000@eu-west-1.amazonses.com> <7ad14946-5c25-fc49-1e48-72d37a607832@boo.tc> <8da0c285-d707-a3d2-063e-472af5cc560f@boo.tc> <8cbab988-fba7-8e27-7faf-9f7aa36ca235@acm.org> <1592321667.4394.5.camel@HansenPartnership.com> <5e512185-45d1-61eb-9bec-91e9f9d53ea3@boo.tc> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Bart Van Assche , "linux-scsi@vger.kernel.org" , Johannes Thumshirn , Chuhong Yuan , "linux-kernel@vger.kernel.org" , Nicholas Bellinger , James Bottomley , "target-devel@vger.kernel.org" , Chris Boot , "linux1394-devel@lists.sourceforge.net" , "linuxppc-dev@lists.ozlabs.org" , Stefan Richter Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Tue, 16 Jun 2020, Martin K. Petersen wrote: > > However, keeping code around is not free. Right. And removing code isn't free either, if it forces people to find workarounds. > Core interfaces change frequently. Nobody enjoys having to tweak host > templates for 50 devices they have never even heard about. And yet some people seem to enjoy writing patches that are as trivial as they are invasive... You seem to be making an argument for more automation here, not an argument for less code. Or is there some upper bound to the size of the kernel, that might be lifted by adding maintainers? (Can you deliver a better product by adding more developers to your project?) > Also, we now live in a reality where there is a constant barrage of > build bots and code analyzers sending mail. So the effective cost of > keeping code around in the tree is going up. But if maintenance cost rises due to good analysis, the value of the code should rise too. So what's the problem? It seems to me that the real problem is too many analyses that generate pedantic noise and no tangible improvement in code quality or value. > I get a substantial amount of code analysis mail about drivers nobody > have touched in a decade or more. > When stable, mature code fails analysis, the analysis is also questionable (in the absence of real examples). > Consequently, I am much more inclined to remove drivers than I have been > in the past. But I am also very happy to bring them back if somebody > uses them or - even better - are willing to step up and maintain them. > You seem to be saying that 1) a driver should be removed when it no longer meets the present threshold for code quality and 2) that a low quality driver is eligible for re-addition because someone wants to use it. I don't think you can have it both ways. > I don't particularly like the notion of a driver being orphaned because > all that really means is that the driver transitions from being (at > least partially) somebody else's problem to being mine and mine alone. > Yes it's your problem but only on a best-effort basis. Many issues detected by automatic analyzers can be fixed with automatic code transformation tools. This kind of solution works tree-wide, so even if some defect in your driver is "yours and yours alone", the solution will probably come from others. This email, like yours, is just hand-waving. So feel free to ignore it or (preferably) provide evidence of real defects.