From: "Theodore Ts'o" <tytso@mit.edu>
To: David Sterba <dsterba@suse.cz>
Cc: Steven Rostedt <rostedt@goodmis.org>,
Johannes Thumshirn <Johannes.Thumshirn@wdc.com>,
Chris Mason <clm@meta.com>, Christoph Hellwig <hch@lst.de>,
Chris Mason <clm@fb.com>, Josef Bacik <josef@toxicpanda.com>,
David Sterba <dsterba@suse.com>,
Damien Le Moal <Damien.LeMoal@wdc.com>,
Naohiro Aota <Naohiro.Aota@wdc.com>, Qu Wenruo <wqu@suse.com>,
Jens Axboe <axboe@kernel.dk>,
"Darrick J. Wong" <djwong@kernel.org>,
"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
"linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>
Subject: Re: consolidate btrfs checksumming, repair and bio splitting
Date: Wed, 2 Nov 2022 22:54:48 -0400 [thread overview]
Message-ID: <Y2MteFkep2ko1UKA@mit.edu> (raw)
In-Reply-To: <20221031121912.GY5824@twin.jikos.cz>
On Mon, Oct 31, 2022 at 01:19:12PM +0100, David Sterba wrote:
> > The policy is simple. If someone requires a copyright notice for their
> > code, you simply add it, or do not take their code. You can be specific
> > about what that code is that is copyrighted. Perhaps just around the code in
> > question or a description at the top.
>
> Let's say it's OK for substantial amount of code. What if somebody
> moves existing code that he did not write to a new file and adds a
> copyright notice? We got stuck there, both sides have different answer.
> I see it at minimum as unfair to the original code authors if not
> completely wrong because it could appear as "stealing" ownership.
So for whatever it's worth, my personal opinion is that it should be
the Maintainer's call, subject to override by Linus. I don't think
it's really worthwhile to try to come up to a formal policy which
would need to define "substantial amount of code". This is an area
where I think it makes sense to assume that Maintainers will be
reasonable and make decisions that makes sense. Ultimately, I think
Chris's phrasing is the one that makes sense. How much do you want
the contribution? If you want the contribution, and the contributor
requests that they want an explicit copyright notification --- make a
choice. You can either tell Christoph no, and revert the changes, or
accept his request to include a copyright statement.
I understand your concern about "fairness" to other contributors ---
is this a hypothetical, or actual concern? Are there other
significant contributors who have explicitly told you that they will
be mortally offended if Cristoph's request is honored, and their code
contribution was not so recognized? It's unclear to whether this is a
theoretical or practical concern?
If it is a practical concern, how many contributors have contributed
more than Cristoph that have asked, and how many extra lines of
copyright statements are we're talking about? 2? 3? 10? 100?
Remember, if someone sends you whitespace fixups or doubled word fixes
found using checkpatch, and demeands a copyright acknowledgement,
you're free to reject the patch. (Heck, some maintainers reject
checkpatch --file fixups on general principles. :-) So this is why I
think the overall "Linux project standard" should be: "maintainer
discretion".
Cheers,
- Ted
next prev parent reply other threads:[~2022-11-03 2:55 UTC|newest]
Thread overview: 101+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-01 7:41 consolidate btrfs checksumming, repair and bio splitting Christoph Hellwig
2022-09-01 7:42 ` [PATCH 01/17] block: export bio_split_rw Christoph Hellwig
2022-09-01 8:02 ` Johannes Thumshirn
2022-09-01 8:54 ` Qu Wenruo
2022-09-05 6:44 ` Christoph Hellwig
2022-09-05 6:51 ` Qu Wenruo
2022-09-07 17:51 ` Josef Bacik
2022-09-01 7:42 ` [PATCH 02/17] btrfs: stop tracking failed reads in the I/O tree Christoph Hellwig
2022-09-01 8:55 ` Qu Wenruo
2022-09-07 17:52 ` Josef Bacik
2022-09-01 7:42 ` [PATCH 03/17] btrfs: move repair_io_failure to volumes.c Christoph Hellwig
2022-09-07 17:54 ` Josef Bacik
2022-09-01 7:42 ` [PATCH 04/17] btrfs: handle checksum validation and repair at the storage layer Christoph Hellwig
2022-09-01 9:04 ` Qu Wenruo
2022-09-05 6:48 ` Christoph Hellwig
2022-09-05 6:59 ` Qu Wenruo
2022-09-05 14:31 ` Christoph Hellwig
2022-09-05 22:34 ` Qu Wenruo
2022-09-06 4:34 ` Christoph Hellwig
2022-09-07 18:15 ` Josef Bacik
2022-09-12 13:57 ` Christoph Hellwig
2022-09-01 7:42 ` [PATCH 05/17] btrfs: handle checksum generation in " Christoph Hellwig
2022-09-07 20:33 ` Josef Bacik
2022-09-01 7:42 ` [PATCH 06/17] btrfs: handle recording of zoned writes " Christoph Hellwig
2022-09-01 9:44 ` Johannes Thumshirn
2022-09-07 20:36 ` Josef Bacik
2022-09-12 6:11 ` Naohiro Aota
2022-09-01 7:42 ` [PATCH 07/17] btrfs: allow btrfs_submit_bio to split bios Christoph Hellwig
2022-09-01 9:47 ` Johannes Thumshirn
2022-09-07 20:55 ` Josef Bacik
2022-09-12 13:58 ` Christoph Hellwig
2022-09-12 0:20 ` Qu Wenruo
2022-09-12 13:55 ` Christoph Hellwig
2022-09-12 22:23 ` Qu Wenruo
2022-09-01 7:42 ` [PATCH 08/17] btrfs: pass the iomap bio to btrfs_submit_bio Christoph Hellwig
2022-09-07 21:00 ` Josef Bacik
2022-09-01 7:42 ` [PATCH 09/17] btrfs: remove stripe boundary calculation for buffered I/O Christoph Hellwig
2022-09-07 21:04 ` Josef Bacik
2022-09-01 7:42 ` [PATCH 10/17] btrfs: remove stripe boundary calculation for compressed I/O Christoph Hellwig
2022-09-01 9:56 ` Johannes Thumshirn
2022-09-05 6:49 ` Christoph Hellwig
2022-09-07 21:07 ` Josef Bacik
2022-09-01 7:42 ` [PATCH 11/17] btrfs: remove stripe boundary calculation for encoded I/O Christoph Hellwig
2022-09-01 9:58 ` Johannes Thumshirn
2022-09-07 21:08 ` Josef Bacik
2022-09-01 7:42 ` [PATCH 12/17] btrfs: remove struct btrfs_io_geometry Christoph Hellwig
2022-09-07 21:10 ` Josef Bacik
2022-09-01 7:42 ` [PATCH 13/17] btrfs: remove submit_encoded_read_bio Christoph Hellwig
2022-09-01 10:02 ` Johannes Thumshirn
2022-09-07 21:11 ` Josef Bacik
2022-09-01 7:42 ` [PATCH 14/17] btrfs: remove now spurious bio submission helpers Christoph Hellwig
2022-09-01 10:14 ` Johannes Thumshirn
2022-09-07 21:12 ` Josef Bacik
2022-09-01 7:42 ` [PATCH 15/17] btrfs: calculate file system wide queue limit for zoned mode Christoph Hellwig
2022-09-01 11:28 ` Johannes Thumshirn
2022-09-05 6:50 ` Christoph Hellwig
2022-09-02 1:56 ` Damien Le Moal
2022-09-02 1:59 ` Damien Le Moal
2022-09-05 6:54 ` Christoph Hellwig
2022-09-01 7:42 ` [PATCH 16/17] btrfs: split zone append bios in btrfs_submit_bio Christoph Hellwig
2022-09-02 1:46 ` Damien Le Moal
2022-09-05 6:55 ` Christoph Hellwig
2022-09-05 13:15 ` Johannes Thumshirn
2022-09-05 14:25 ` Christoph Hellwig
2022-09-05 14:31 ` Johannes Thumshirn
2022-09-05 14:39 ` Christoph Hellwig
2022-09-05 14:43 ` Johannes Thumshirn
2022-09-05 15:30 ` Johannes Thumshirn
2022-09-07 21:17 ` Josef Bacik
2022-09-01 7:42 ` [PATCH 17/17] iomap: remove IOMAP_F_ZONE_APPEND Christoph Hellwig
2022-09-01 10:46 ` Johannes Thumshirn
2022-09-02 1:38 ` Damien Le Moal
2022-09-05 6:50 ` Christoph Hellwig
2022-09-05 6:57 ` Damien Le Moal
2022-09-07 21:18 ` Josef Bacik
2022-09-02 15:18 ` consolidate btrfs checksumming, repair and bio splitting Johannes Thumshirn
2022-10-24 8:12 ` Johannes Thumshirn
2022-10-24 8:20 ` Qu Wenruo
2022-10-24 9:07 ` Johannes Thumshirn
2022-10-24 9:18 ` Qu Wenruo
2022-10-24 10:21 ` Johannes Thumshirn
2022-10-24 14:44 ` Christoph Hellwig
2022-10-24 15:25 ` Chris Mason
2022-10-24 17:10 ` David Sterba
2022-10-24 17:34 ` Chris Mason
2022-10-24 22:18 ` Damien Le Moal
2022-10-26 7:36 ` Johannes Thumshirn
2022-10-26 11:41 ` Steven Rostedt
2022-10-27 13:54 ` Johannes Thumshirn
2022-10-31 12:19 ` David Sterba
2022-10-31 16:06 ` Chris Mason
2022-11-02 4:00 ` Steven Rostedt
2022-11-02 6:29 ` Christoph Hellwig
2022-11-02 14:00 ` Chris Mason
2022-11-02 14:05 ` Josef Bacik
2022-11-02 14:06 ` Christoph Hellwig
2022-11-02 20:20 ` Andreas Dilger
2022-11-02 22:07 ` Chris Mason
2022-11-03 8:49 ` Christoph Hellwig
2022-11-03 2:54 ` Theodore Ts'o [this message]
2022-11-11 17:57 ` David Sterba
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y2MteFkep2ko1UKA@mit.edu \
--to=tytso@mit.edu \
--cc=Damien.LeMoal@wdc.com \
--cc=Johannes.Thumshirn@wdc.com \
--cc=Naohiro.Aota@wdc.com \
--cc=axboe@kernel.dk \
--cc=clm@fb.com \
--cc=clm@meta.com \
--cc=djwong@kernel.org \
--cc=dsterba@suse.com \
--cc=dsterba@suse.cz \
--cc=hch@lst.de \
--cc=josef@toxicpanda.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=rostedt@goodmis.org \
--cc=wqu@suse.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).