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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 94878FA373D for ; Tue, 25 Oct 2022 00:03:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230037AbiJYAD0 (ORCPT ); Mon, 24 Oct 2022 20:03:26 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47770 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230363AbiJYADH (ORCPT ); Mon, 24 Oct 2022 20:03:07 -0400 Received: from esa3.hgst.iphmx.com (esa3.hgst.iphmx.com [216.71.153.141]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EC1634F3A2 for ; Mon, 24 Oct 2022 15:18:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=wdc.com; i=@wdc.com; q=dns/txt; s=dkim.wdc.com; t=1666649892; x=1698185892; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=AUarYESSBWuIiRFqSp6O0q+qq8tkbufoEKVSVje4Iy4=; b=Qi7ZDz9eHOeDC/QSQtOtXB/h6U4QwOeQ72Fqr0TKOG67oZ3G0Sxg/Yvs HI2M/bcMX4HAUYTP8N8z2XIy9bAJgS8IOQ0lq3VClcec4s3dMfSDO6lSZ Bn4j6kelvLyjqlMMyz0mmLB8aCKUK9byhgp7Fkq/aDMm6z4okYDveqf10 X09ciDIn68vL9PpS7ZS7ra38vCL4vZSxXqk2UDZsLgVyQlGEOllJ6kI+B kRuVYrZfzvQtp48YuQDn+ZqzWdd0zY06DlDxf9/PZSuRrAN8ItvkdnxiI 3scYrySdjpdEZeZ2A1gDKQR1VO2XGJbqYZba68+YTYUX23kFPPb/CN0LP g==; X-IronPort-AV: E=Sophos;i="5.95,210,1661788800"; d="scan'208";a="219792294" Received: from h199-255-45-14.hgst.com (HELO uls-op-cesaep01.wdc.com) ([199.255.45.14]) by ob1.hgst.iphmx.com with ESMTP; 25 Oct 2022 06:18:11 +0800 IronPort-SDR: gBQqVTlgZ4dImcZFwYR4MFgKLGaVNlQ5XJEDdVbhMjFj2FA+AKUHZOv8hCFcw1E7OLm70bVQ+Z cndbpCI9LqYDfbmcwyl3hLIpVGC5BmgWwpYJ/ydguHRXs3E/2+t2cOvtFaNBwL8IGKQa8q4UwP 0q9EN7jVxW33i1rULfr1cdGeCVfyJzI1D0nrAlLH0MEUxTDqa2VE9v80qsI2O61TNUD4DQjQPB /ZE3+8QxtsindX6YTRsN/qFLBjcO9TdUvU2VGXb/fS9Z9+VVZJvqmpoGpms6JuWPyuMfb7Ws+a IvvGaoL8K9/6qBCUr5EEHmkl Received: from uls-op-cesaip01.wdc.com ([10.248.3.36]) by uls-op-cesaep01.wdc.com with ESMTP/TLS/ECDHE-RSA-AES128-GCM-SHA256; 24 Oct 2022 14:37:33 -0700 IronPort-SDR: w+YimD/qN+abi8vRXxZXFkaEMDakQU6XRxCeUqAjT0KMMSshjRF+td+40WSR8tCGHf9L/Q8XBi oNbZr8JocZuDch27qu5WNELnViDG2idVRUHuQzJIayh/Dde6fBYT6DsZ5PtKtE0ZsqCSQRChvR 1p3/44NUsqAS39REYVV7Yb+GPijSNX6SZxyJ9Fktg+IplF4iXUpL8wcLu4vbGFmNPaB8tRNasT UIjcQoPCt/efRqz+cEH02PXYsnmKBsfJqhUDVA5T8s438/GPmvvKV9ncqTUBk/5nhwCSga1pLF z7Q= WDCIronportException: Internal Received: from usg-ed-osssrv.wdc.com ([10.3.10.180]) by uls-op-cesaip01.wdc.com with ESMTP/TLS/ECDHE-RSA-AES128-GCM-SHA256; 24 Oct 2022 15:18:10 -0700 Received: from usg-ed-osssrv.wdc.com (usg-ed-osssrv.wdc.com [127.0.0.1]) by usg-ed-osssrv.wdc.com (Postfix) with ESMTP id 4Mx8bP57qrz1RWy0 for ; Mon, 24 Oct 2022 15:18:09 -0700 (PDT) Authentication-Results: usg-ed-osssrv.wdc.com (amavisd-new); dkim=pass reason="pass (just generated, assumed good)" header.d=opensource.wdc.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d= opensource.wdc.com; h=content-transfer-encoding:content-type :in-reply-to:organization:from:references:to:content-language :subject:user-agent:mime-version:date:message-id; s=dkim; t= 1666649887; x=1669241888; bh=AUarYESSBWuIiRFqSp6O0q+qq8tkbufoEKV SVje4Iy4=; b=BTeM4sx7WaD0/FqfkAJRiv0MyL3ZRUYeQb/taFA/KB+vQgBAtIA Da8KBEeBLXmq+uy1X63DEtBHcRkjUcJ3LZZ2YmoM5B4rj/QXA7otcJhf06y/n4/W tlTwjJ9NgybBLNM5g0PKKdUtA7OO64fmuz7ce8X8tmJ4kRL/VB0Me4GExSwJZEJF wxG1j/Fqz9UJzLXyHdOd0o/a0XXu4NuLLM3dvP0SJrDnSF+2VxnIY7tHFwVIjH7+ r+dHxcRpHIWa8MnpMSBXeu5QwsfP6cnri5or5CLaAAsTkoqOibM8nQvryUuU5TiL WSCnh9OHblbFkntY85LMJgszkd6nmLxQrig== X-Virus-Scanned: amavisd-new at usg-ed-osssrv.wdc.com Received: from usg-ed-osssrv.wdc.com ([127.0.0.1]) by usg-ed-osssrv.wdc.com (usg-ed-osssrv.wdc.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id RMpcwLgbOWVG for ; Mon, 24 Oct 2022 15:18:07 -0700 (PDT) Received: from [10.225.163.8] (unknown [10.225.163.8]) by usg-ed-osssrv.wdc.com (Postfix) with ESMTPSA id 4Mx8bK1bjpz1RvLy; Mon, 24 Oct 2022 15:18:04 -0700 (PDT) Message-ID: <94ba6a25-b67f-4530-5236-63764711c4d5@opensource.wdc.com> Date: Tue, 25 Oct 2022 07:18:03 +0900 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.0 Subject: Re: consolidate btrfs checksumming, repair and bio splitting Content-Language: en-US To: Chris Mason , dsterba@suse.cz Cc: Christoph Hellwig , Johannes Thumshirn , Chris Mason , Josef Bacik , David Sterba , Damien Le Moal , Naohiro Aota , Qu Wenruo , Jens Axboe , "Darrick J. Wong" , "linux-block@vger.kernel.org" , "linux-btrfs@vger.kernel.org" , "linux-fsdevel@vger.kernel.org" References: <20220901074216.1849941-1-hch@lst.de> <347dc0b3-0388-54ee-6dcb-0c1d0ca08d05@wdc.com> <20221024144411.GA25172@lst.de> <773539e2-b5f1-8386-aa2a-96086f198bf8@meta.com> <20221024171042.GF5824@suse.cz> <891da9bf-f703-0ddb-15e8-74647da297ea@meta.com> From: Damien Le Moal Organization: Western Digital Research In-Reply-To: <891da9bf-f703-0ddb-15e8-74647da297ea@meta.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org On 10/25/22 02:34, Chris Mason wrote: > On 10/24/22 1:10 PM, David Sterba wrote: >> On Mon, Oct 24, 2022 at 11:25:04AM -0400, Chris Mason wrote: >>> On 10/24/22 10:44 AM, Christoph Hellwig wrote: >>>> On Mon, Oct 24, 2022 at 08:12:29AM +0000, Johannes Thumshirn wrote: >>>>> David, what's your plan to progress with this series? >>>> >>>> FYI, I object to merging any of my code into btrfs without a proper >>>> copyright notice, and I also need to find some time to remove my >>>> previous significant changes given that the btrfs maintainer >>>> refuses to take the proper and legally required copyright notice. >>>> >>>> So don't waste any of your time on this. >>> >>> Christoph's request is well within the norms for the kernel, given that >>> he's making substantial changes to these files. I talked this over with >>> GregKH, who pointed me at: >>> >>> https://www.linuxfoundation.org/blog/blog/copyright-notices-in-open-source-software-projects >>> >>> Even if we'd taken up some of the other policies suggested by this doc, >>> I'd still defer to preferences of developers who have made significant >>> changes. >> >> I've asked for recommendations or best practice similar to the SPDX >> process. Something that TAB can acknowledge and that is perhaps also >> consulted with lawyers. And understood within the linux project, >> not just that some dudes have an argument because it's all clear as mud >> and people are used to do things differently. > > The LF in general doesn't give legal advice, but the link above does > help describe common practices. > > It's up to us to bring in our own lawyers and make decisions about the > kinds of changes we're willing to accept. We could ask the TAB (btw, > I'm no longer on the TAB) to weigh in, but I think we'll find the normal > variety of answers based on subsystem. > > It's also up to contributors to decide on what kinds of requirements > they want to place on continued participation. Individuals and > corporations have their own preferences based on advice from their > lawyers, and as long as the change is significant, I think we can and > should honor their wishes. > > Does this mean going through and retroactively adding copyright lines? > I'd really rather not. If a major contributor comes in and shows a long > list of commits and asks for a copyright line, I personally would say yes. I am not aware of any long list of copyright holders in kernel source code files. I personally thought that the most common practice is to add a copyright notice for the creator (or his/her employer) of a new source file, or if for someone who almost completely rewrite a file. That is I think perfectly acceptable, as adding a new file generally means that a contribution is substantial. > >> >> The link from linux foundation blog is nice but unless this is codified >> into the process it's just somebody's blog post. Also there's a paragraph >> about "Why not list every copyright holder?" that covers several points >> why I don't want to do that. > > I'm also happy to gather advice about following the suggestions in the > LF post. I understand your concerns about listing every copyright > holder, but I don't think this has been a major problem in the kernel in > general. > >> >> But, if TAB says so I will do, perhaps spending hours of unproductive >> time looking up the whole history of contributors and adding year, name, >> company whatever to files. > > I can't imagine anyone asking you to spend time this way. > > -chris > -- Damien Le Moal Western Digital Research