From: Ross Zwisler <ross.zwisler@linux.intel.com>
To: Dave Chinner <david@fromorbit.com>
Cc: Theodore Ts'o <tytso@mit.edu>,
Matthew Wilcox <mawilcox@microsoft.com>,
linux-nvdimm@lists.01.org, linux-kernel@vger.kernel.org,
Christoph Hellwig <hch@lst.de>,
linux-xfs@vger.kernel.org, linux-mm@kvack.org,
Andreas Dilger <adilger.kernel@dilger.ca>,
Alexander Viro <viro@zeniv.linux.org.uk>,
Jan Kara <jack@suse.com>,
linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH v4 00/12] re-enable DAX PMD support
Date: Thu, 29 Sep 2016 21:03:43 -0600 [thread overview]
Message-ID: <20160930030343.GA12464@linux.intel.com> (raw)
In-Reply-To: <20160929234345.GG27872@dastard>
On Fri, Sep 30, 2016 at 09:43:45AM +1000, Dave Chinner wrote:
> Finally: none of the patches in your tree have reviewed-by tags.
> That says to me that none of this code has been reviewed yet.
> Reviewed-by tags are non-negotiable requirement for anything going
> through my trees. I don't have time right now to review this code,
> so you're going to need to chase up other reviewers before merging.
>
> And, really, this is getting very late in the cycle to be merging
> new code - we're less than one working day away from the merge
> window opening and we've missed the last linux-next build. I'd
> suggest that we'd might be best served by slipping this to the PMD
> support code to the next cycle when there's no time pressure for
> review and we can get a decent linux-next soak on the code.
I absolutely support your policy of only sending code to Linux that has passed
peer review.
However, I do feel compelled to point out that this is not new code. I didn't
just spring it on everyone in the hours before the v4.8 merge window. I
posted the first version of this patch set on August 15th, *seven weeks ago*:
https://lkml.org/lkml/2016/8/15/613
This was the day after v4.7-rc2 was released.
Since then I have responded promptly to the little review feedback that I've
received. I've also reviewed and tested other DAX changes, like the struct
iomap changes from Christoph. Those changes were first posted to the mailing
list on September 9th, four weeks after mine. Nevertheless, I was happy to
rebase my changes on top of his, which meant a full rewrite of the DAX PMD
fault handler so it would be based on struct iomap. His changes are going to
be merged for v4.9, and mine are not.
Please, help me understand what I can do to get my code reviewed. Do I need
to more aggressively ping my patch series, asking people by name for reviews?
Do we need to rework our code flow to Linus so that the DAX changes go through
a filesystem tree like XFS or ext4, and ask the developers of that filesystem
to help with reviews? Something else?
I'm honestly very frustrated by this because I've done my best to be open to
constructive criticism and I've tried to respond promptly to the feedback that
I've received. In the end, though, a system where it's a requirement that all
upstreamed code be peer reviewed but in which I can't get any feedback is
essentially a system where I'm not allowed to contribute.
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
WARNING: multiple messages have this Message-ID (diff)
From: Ross Zwisler <ross.zwisler@linux.intel.com>
To: Dave Chinner <david@fromorbit.com>
Cc: Ross Zwisler <ross.zwisler@linux.intel.com>,
linux-kernel@vger.kernel.org, "Theodore Ts'o" <tytso@mit.edu>,
Alexander Viro <viro@zeniv.linux.org.uk>,
Andreas Dilger <adilger.kernel@dilger.ca>,
Andrew Morton <akpm@linux-foundation.org>,
Christoph Hellwig <hch@lst.de>,
Dan Williams <dan.j.williams@intel.com>, Jan Kara <jack@suse.com>,
Matthew Wilcox <mawilcox@microsoft.com>,
linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-mm@kvack.org, linux-nvdimm@ml01.01.org,
linux-xfs@vger.kernel.org
Subject: Re: [PATCH v4 00/12] re-enable DAX PMD support
Date: Thu, 29 Sep 2016 21:03:43 -0600 [thread overview]
Message-ID: <20160930030343.GA12464@linux.intel.com> (raw)
In-Reply-To: <20160929234345.GG27872@dastard>
On Fri, Sep 30, 2016 at 09:43:45AM +1000, Dave Chinner wrote:
> Finally: none of the patches in your tree have reviewed-by tags.
> That says to me that none of this code has been reviewed yet.
> Reviewed-by tags are non-negotiable requirement for anything going
> through my trees. I don't have time right now to review this code,
> so you're going to need to chase up other reviewers before merging.
>
> And, really, this is getting very late in the cycle to be merging
> new code - we're less than one working day away from the merge
> window opening and we've missed the last linux-next build. I'd
> suggest that we'd might be best served by slipping this to the PMD
> support code to the next cycle when there's no time pressure for
> review and we can get a decent linux-next soak on the code.
I absolutely support your policy of only sending code to Linux that has passed
peer review.
However, I do feel compelled to point out that this is not new code. I didn't
just spring it on everyone in the hours before the v4.8 merge window. I
posted the first version of this patch set on August 15th, *seven weeks ago*:
https://lkml.org/lkml/2016/8/15/613
This was the day after v4.7-rc2 was released.
Since then I have responded promptly to the little review feedback that I've
received. I've also reviewed and tested other DAX changes, like the struct
iomap changes from Christoph. Those changes were first posted to the mailing
list on September 9th, four weeks after mine. Nevertheless, I was happy to
rebase my changes on top of his, which meant a full rewrite of the DAX PMD
fault handler so it would be based on struct iomap. His changes are going to
be merged for v4.9, and mine are not.
Please, help me understand what I can do to get my code reviewed. Do I need
to more aggressively ping my patch series, asking people by name for reviews?
Do we need to rework our code flow to Linus so that the DAX changes go through
a filesystem tree like XFS or ext4, and ask the developers of that filesystem
to help with reviews? Something else?
I'm honestly very frustrated by this because I've done my best to be open to
constructive criticism and I've tried to respond promptly to the feedback that
I've received. In the end, though, a system where it's a requirement that all
upstreamed code be peer reviewed but in which I can't get any feedback is
essentially a system where I'm not allowed to contribute.
WARNING: multiple messages have this Message-ID (diff)
From: Ross Zwisler <ross.zwisler@linux.intel.com>
To: Dave Chinner <david@fromorbit.com>
Cc: Ross Zwisler <ross.zwisler@linux.intel.com>,
linux-kernel@vger.kernel.org, Theodore Ts'o <tytso@mit.edu>,
Alexander Viro <viro@zeniv.linux.org.uk>,
Andreas Dilger <adilger.kernel@dilger.ca>,
Andrew Morton <akpm@linux-foundation.org>,
Christoph Hellwig <hch@lst.de>,
Dan Williams <dan.j.williams@intel.com>, Jan Kara <jack@suse.com>,
Matthew Wilcox <mawilcox@microsoft.com>,
linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-mm@kvack.org, linux-nvdimm@lists.01.org,
linux-xfs@vger.kernel.org
Subject: Re: [PATCH v4 00/12] re-enable DAX PMD support
Date: Thu, 29 Sep 2016 21:03:43 -0600 [thread overview]
Message-ID: <20160930030343.GA12464@linux.intel.com> (raw)
In-Reply-To: <20160929234345.GG27872@dastard>
On Fri, Sep 30, 2016 at 09:43:45AM +1000, Dave Chinner wrote:
> Finally: none of the patches in your tree have reviewed-by tags.
> That says to me that none of this code has been reviewed yet.
> Reviewed-by tags are non-negotiable requirement for anything going
> through my trees. I don't have time right now to review this code,
> so you're going to need to chase up other reviewers before merging.
>
> And, really, this is getting very late in the cycle to be merging
> new code - we're less than one working day away from the merge
> window opening and we've missed the last linux-next build. I'd
> suggest that we'd might be best served by slipping this to the PMD
> support code to the next cycle when there's no time pressure for
> review and we can get a decent linux-next soak on the code.
I absolutely support your policy of only sending code to Linux that has passed
peer review.
However, I do feel compelled to point out that this is not new code. I didn't
just spring it on everyone in the hours before the v4.8 merge window. I
posted the first version of this patch set on August 15th, *seven weeks ago*:
https://lkml.org/lkml/2016/8/15/613
This was the day after v4.7-rc2 was released.
Since then I have responded promptly to the little review feedback that I've
received. I've also reviewed and tested other DAX changes, like the struct
iomap changes from Christoph. Those changes were first posted to the mailing
list on September 9th, four weeks after mine. Nevertheless, I was happy to
rebase my changes on top of his, which meant a full rewrite of the DAX PMD
fault handler so it would be based on struct iomap. His changes are going to
be merged for v4.9, and mine are not.
Please, help me understand what I can do to get my code reviewed. Do I need
to more aggressively ping my patch series, asking people by name for reviews?
Do we need to rework our code flow to Linus so that the DAX changes go through
a filesystem tree like XFS or ext4, and ask the developers of that filesystem
to help with reviews? Something else?
I'm honestly very frustrated by this because I've done my best to be open to
constructive criticism and I've tried to respond promptly to the feedback that
I've received. In the end, though, a system where it's a requirement that all
upstreamed code be peer reviewed but in which I can't get any feedback is
essentially a system where I'm not allowed to contribute.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Ross Zwisler <ross.zwisler@linux.intel.com>
To: Dave Chinner <david@fromorbit.com>
Cc: Ross Zwisler <ross.zwisler@linux.intel.com>,
linux-kernel@vger.kernel.org, Theodore Ts'o <tytso@mit.edu>,
Alexander Viro <viro@zeniv.linux.org.uk>,
Andreas Dilger <adilger.kernel@dilger.ca>,
Andrew Morton <akpm@linux-foundation.org>,
Christoph Hellwig <hch@lst.de>,
Dan Williams <dan.j.williams@intel.com>, Jan Kara <jack@suse.com>,
Matthew Wilcox <mawilcox@microsoft.com>,
linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-mm@kvack.org, linux-nvdimm@lists.01.org,
linux-xfs@vger.kernel.org
Subject: Re: [PATCH v4 00/12] re-enable DAX PMD support
Date: Thu, 29 Sep 2016 21:03:43 -0600 [thread overview]
Message-ID: <20160930030343.GA12464@linux.intel.com> (raw)
In-Reply-To: <20160929234345.GG27872@dastard>
On Fri, Sep 30, 2016 at 09:43:45AM +1000, Dave Chinner wrote:
> Finally: none of the patches in your tree have reviewed-by tags.
> That says to me that none of this code has been reviewed yet.
> Reviewed-by tags are non-negotiable requirement for anything going
> through my trees. I don't have time right now to review this code,
> so you're going to need to chase up other reviewers before merging.
>
> And, really, this is getting very late in the cycle to be merging
> new code - we're less than one working day away from the merge
> window opening and we've missed the last linux-next build. I'd
> suggest that we'd might be best served by slipping this to the PMD
> support code to the next cycle when there's no time pressure for
> review and we can get a decent linux-next soak on the code.
I absolutely support your policy of only sending code to Linux that has passed
peer review.
However, I do feel compelled to point out that this is not new code. I didn't
just spring it on everyone in the hours before the v4.8 merge window. I
posted the first version of this patch set on August 15th, *seven weeks ago*:
https://lkml.org/lkml/2016/8/15/613
This was the day after v4.7-rc2 was released.
Since then I have responded promptly to the little review feedback that I've
received. I've also reviewed and tested other DAX changes, like the struct
iomap changes from Christoph. Those changes were first posted to the mailing
list on September 9th, four weeks after mine. Nevertheless, I was happy to
rebase my changes on top of his, which meant a full rewrite of the DAX PMD
fault handler so it would be based on struct iomap. His changes are going to
be merged for v4.9, and mine are not.
Please, help me understand what I can do to get my code reviewed. Do I need
to more aggressively ping my patch series, asking people by name for reviews?
Do we need to rework our code flow to Linus so that the DAX changes go through
a filesystem tree like XFS or ext4, and ask the developers of that filesystem
to help with reviews? Something else?
I'm honestly very frustrated by this because I've done my best to be open to
constructive criticism and I've tried to respond promptly to the feedback that
I've received. In the end, though, a system where it's a requirement that all
upstreamed code be peer reviewed but in which I can't get any feedback is
essentially a system where I'm not allowed to contribute.
next prev parent reply other threads:[~2016-09-30 3:03 UTC|newest]
Thread overview: 189+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-29 22:49 [PATCH v4 00/12] re-enable DAX PMD support Ross Zwisler
2016-09-29 22:49 ` Ross Zwisler
2016-09-29 22:49 ` Ross Zwisler
2016-09-29 22:49 ` Ross Zwisler
2016-09-29 22:49 ` [PATCH v4 01/12] ext4: allow DAX writeback for hole punch Ross Zwisler
2016-09-29 22:49 ` Ross Zwisler
2016-09-29 22:49 ` Ross Zwisler
2016-09-29 22:49 ` Ross Zwisler
2016-09-29 22:49 ` Ross Zwisler
2016-09-29 22:49 ` [PATCH v4 02/12] ext4: tell DAX the size of allocation holes Ross Zwisler
2016-09-29 22:49 ` Ross Zwisler
2016-09-29 22:49 ` Ross Zwisler
2016-09-29 22:49 ` Ross Zwisler
2016-09-29 22:49 ` [PATCH v4 03/12] dax: remove buffer_size_valid() Ross Zwisler
2016-09-29 22:49 ` Ross Zwisler
2016-09-29 22:49 ` Ross Zwisler
2016-09-29 22:49 ` Ross Zwisler
2016-09-30 8:49 ` Christoph Hellwig
2016-09-30 8:49 ` Christoph Hellwig
2016-09-30 8:49 ` Christoph Hellwig
2016-09-30 8:49 ` Christoph Hellwig
2016-09-29 22:49 ` [PATCH v4 04/12] ext2: remove support for DAX PMD faults Ross Zwisler
2016-09-29 22:49 ` Ross Zwisler
2016-09-29 22:49 ` Ross Zwisler
2016-09-29 22:49 ` Ross Zwisler
2016-09-29 22:49 ` Ross Zwisler
2016-09-30 8:49 ` Christoph Hellwig
2016-09-30 8:49 ` Christoph Hellwig
2016-09-30 8:49 ` Christoph Hellwig
2016-09-30 8:49 ` Christoph Hellwig
2016-10-03 9:35 ` Jan Kara
2016-10-03 9:35 ` Jan Kara
2016-10-03 9:35 ` Jan Kara
2016-10-03 9:35 ` Jan Kara
2016-09-29 22:49 ` [PATCH v4 05/12] dax: make 'wait_table' global variable static Ross Zwisler
2016-09-29 22:49 ` Ross Zwisler
2016-09-29 22:49 ` Ross Zwisler
2016-09-29 22:49 ` Ross Zwisler
2016-09-29 22:49 ` Ross Zwisler
2016-09-30 8:50 ` Christoph Hellwig
2016-09-30 8:50 ` Christoph Hellwig
2016-09-30 8:50 ` Christoph Hellwig
2016-09-30 8:50 ` Christoph Hellwig
2016-10-03 9:36 ` Jan Kara
2016-10-03 9:36 ` Jan Kara
2016-10-03 9:36 ` Jan Kara
2016-10-03 9:36 ` Jan Kara
2016-10-03 9:36 ` Jan Kara
2016-09-29 22:49 ` [PATCH v4 06/12] dax: consistent variable naming for DAX entries Ross Zwisler
2016-09-29 22:49 ` Ross Zwisler
2016-09-29 22:49 ` Ross Zwisler
2016-09-29 22:49 ` Ross Zwisler
2016-09-29 22:49 ` Ross Zwisler
2016-09-30 8:50 ` Christoph Hellwig
2016-09-30 8:50 ` Christoph Hellwig
2016-09-30 8:50 ` Christoph Hellwig
2016-09-30 8:50 ` Christoph Hellwig
2016-09-30 8:50 ` Christoph Hellwig
2016-10-03 9:37 ` Jan Kara
2016-10-03 9:37 ` Jan Kara
2016-10-03 9:37 ` Jan Kara
2016-10-03 9:37 ` Jan Kara
2016-10-03 9:37 ` Jan Kara
2016-09-29 22:49 ` [PATCH v4 07/12] dax: coordinate locking for offsets in PMD range Ross Zwisler
2016-09-29 22:49 ` Ross Zwisler
2016-09-29 22:49 ` Ross Zwisler
2016-09-29 22:49 ` Ross Zwisler
2016-09-29 22:49 ` Ross Zwisler
2016-09-30 9:44 ` Christoph Hellwig
2016-09-30 9:44 ` Christoph Hellwig
2016-10-03 9:55 ` Jan Kara
2016-10-03 9:55 ` Jan Kara
2016-10-03 9:55 ` Jan Kara
2016-10-03 9:55 ` Jan Kara
2016-10-03 18:40 ` Ross Zwisler
2016-10-03 18:40 ` Ross Zwisler
2016-10-03 18:40 ` Ross Zwisler
2016-10-03 18:40 ` Ross Zwisler
2016-10-03 18:40 ` Ross Zwisler
2016-09-29 22:49 ` [PATCH v4 08/12] dax: remove dax_pmd_fault() Ross Zwisler
2016-09-29 22:49 ` Ross Zwisler
2016-09-29 22:49 ` Ross Zwisler
2016-09-29 22:49 ` Ross Zwisler
2016-09-29 22:49 ` Ross Zwisler
2016-09-30 8:50 ` Christoph Hellwig
2016-09-30 8:50 ` Christoph Hellwig
2016-09-30 8:50 ` Christoph Hellwig
2016-09-30 8:50 ` Christoph Hellwig
2016-09-30 8:50 ` Christoph Hellwig
2016-10-03 9:56 ` Jan Kara
2016-10-03 9:56 ` Jan Kara
2016-10-03 9:56 ` Jan Kara
2016-10-03 9:56 ` Jan Kara
2016-09-29 22:49 ` [PATCH v4 09/12] dax: correct dax iomap code namespace Ross Zwisler
2016-09-29 22:49 ` Ross Zwisler
2016-09-29 22:49 ` Ross Zwisler
2016-09-29 22:49 ` Ross Zwisler
2016-09-30 8:51 ` Christoph Hellwig
2016-09-30 8:51 ` Christoph Hellwig
2016-09-30 8:51 ` Christoph Hellwig
2016-09-30 8:51 ` Christoph Hellwig
2016-10-03 9:57 ` Jan Kara
2016-10-03 9:57 ` Jan Kara
2016-10-03 9:57 ` Jan Kara
2016-10-03 9:57 ` Jan Kara
2016-09-29 22:49 ` [PATCH v4 10/12] dax: add struct iomap based DAX PMD support Ross Zwisler
2016-09-29 22:49 ` Ross Zwisler
2016-09-29 22:49 ` Ross Zwisler
2016-09-29 22:49 ` Ross Zwisler
2016-09-29 22:49 ` Ross Zwisler
[not found] ` <1475189370-31634-11-git-send-email-ross.zwisler-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2016-09-30 9:56 ` Christoph Hellwig
2016-09-30 9:56 ` Christoph Hellwig
2016-09-30 9:56 ` Christoph Hellwig
[not found] ` <20160930095627.GB5299-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
2016-10-03 21:16 ` Ross Zwisler
2016-10-03 21:16 ` Ross Zwisler
2016-10-03 21:16 ` Ross Zwisler
2016-10-03 10:59 ` Jan Kara
2016-10-03 10:59 ` Jan Kara
2016-10-03 10:59 ` Jan Kara
2016-10-03 10:59 ` Jan Kara
2016-10-03 16:37 ` Christoph Hellwig
2016-10-03 16:37 ` Christoph Hellwig
2016-10-03 16:37 ` Christoph Hellwig
2016-10-03 21:05 ` Ross Zwisler
2016-10-03 21:05 ` Ross Zwisler
2016-10-03 21:05 ` Ross Zwisler
2016-10-04 5:55 ` Jan Kara
2016-10-04 5:55 ` Jan Kara
2016-10-04 5:55 ` Jan Kara
2016-10-04 5:55 ` Jan Kara
2016-10-04 15:39 ` Ross Zwisler
2016-10-04 15:39 ` Ross Zwisler
2016-10-04 15:39 ` Ross Zwisler
2016-10-04 15:39 ` Ross Zwisler
2016-10-05 5:50 ` Jan Kara
2016-10-05 5:50 ` Jan Kara
2016-10-05 5:50 ` Jan Kara
2016-10-05 5:50 ` Jan Kara
2016-10-05 5:50 ` Jan Kara
2016-10-06 21:34 ` Ross Zwisler
2016-10-06 21:34 ` Ross Zwisler
2016-10-06 21:34 ` Ross Zwisler
2016-10-06 21:34 ` Ross Zwisler
2016-10-06 21:34 ` Ross Zwisler
2016-10-07 2:58 ` Ross Zwisler
2016-10-07 2:58 ` Ross Zwisler
2016-10-07 2:58 ` Ross Zwisler
2016-10-07 2:58 ` Ross Zwisler
2016-10-07 7:24 ` Jan Kara
2016-10-07 7:24 ` Jan Kara
2016-10-07 7:24 ` Jan Kara
2016-10-07 7:24 ` Jan Kara
2016-10-07 7:24 ` Jan Kara
2016-09-29 22:49 ` [PATCH v4 11/12] xfs: use struct iomap based DAX PMD fault path Ross Zwisler
2016-09-29 22:49 ` Ross Zwisler
2016-09-29 22:49 ` Ross Zwisler
2016-09-29 22:49 ` Ross Zwisler
2016-09-29 22:49 ` [PATCH v4 12/12] dax: remove "depends on BROKEN" from FS_DAX_PMD Ross Zwisler
2016-09-29 22:49 ` Ross Zwisler
2016-09-29 22:49 ` Ross Zwisler
2016-09-29 22:49 ` Ross Zwisler
2016-09-29 22:49 ` Ross Zwisler
2016-09-29 23:43 ` [PATCH v4 00/12] re-enable DAX PMD support Dave Chinner
2016-09-29 23:43 ` Dave Chinner
2016-09-29 23:43 ` Dave Chinner
2016-09-29 23:43 ` Dave Chinner
2016-09-29 23:43 ` Dave Chinner
2016-09-30 3:03 ` Ross Zwisler [this message]
2016-09-30 3:03 ` Ross Zwisler
2016-09-30 3:03 ` Ross Zwisler
2016-09-30 3:03 ` Ross Zwisler
2016-09-30 4:00 ` Darrick J. Wong
2016-09-30 4:00 ` Darrick J. Wong
2016-10-03 18:54 ` Ross Zwisler
2016-10-03 18:54 ` Ross Zwisler
2016-09-30 6:48 ` Dave Chinner
2016-09-30 6:48 ` Dave Chinner
2016-09-30 6:48 ` Dave Chinner
2016-09-30 6:48 ` Dave Chinner
2016-10-03 21:11 ` Ross Zwisler
2016-10-03 21:11 ` Ross Zwisler
2016-10-03 21:11 ` Ross Zwisler
2016-10-03 21:11 ` Ross Zwisler
2016-10-03 23:05 ` Ross Zwisler
2016-10-03 23:05 ` Ross Zwisler
2016-10-03 23:05 ` Ross Zwisler
2016-10-03 23:05 ` Ross Zwisler
2016-09-30 11:46 ` Christoph Hellwig
2016-09-30 11:46 ` Christoph Hellwig
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=20160930030343.GA12464@linux.intel.com \
--to=ross.zwisler@linux.intel.com \
--cc=adilger.kernel@dilger.ca \
--cc=akpm@linux-foundation.org \
--cc=david@fromorbit.com \
--cc=hch@lst.de \
--cc=jack@suse.com \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-nvdimm@lists.01.org \
--cc=linux-xfs@vger.kernel.org \
--cc=mawilcox@microsoft.com \
--cc=tytso@mit.edu \
--cc=viro@zeniv.linux.org.uk \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.