From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Mike Kravetz <mike.kravetz@oracle.com>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
linux-mm@kvack.org, linux-scsi <linux-scsi@vger.kernel.org>
Cc: lsf-pc@lists.linux-foundation.org
Subject: Re: [LSF/MM TOPIC] Patch Submission process and Handling Internal Conflict
Date: Wed, 24 Jan 2018 13:36:00 -0800 [thread overview]
Message-ID: <1516829760.3073.43.camel@HansenPartnership.com> (raw)
In-Reply-To: <c4598a9a-6995-d67a-dd1c-8e946470eeb4@oracle.com>
On Wed, 2018-01-24 at 11:20 -0800, Mike Kravetz wrote:
> On 01/24/2018 11:05 AM, James Bottomley wrote:
> >
> > I've got two community style topics, which should probably be
> > discussed
> > in the plenary
> >
> > 1. Patch Submission Process
> >
> > Today we don't have a uniform patch submission process across
> > Storage, Filesystems and MM. The question is should we (or at
> > least should we adhere to some minimal standards). The standard
> > we've been trying to hold to in SCSI is one review per accepted
> > non-trivial patch. For us, it's useful because it encourages
> > driver writers to review each other's patches rather than just
> > posting and then complaining their patch hasn't gone in. I can
> > certainly think of a couple of bugs I've had to chase in mm where
> > the underlying patches would have benefited from review, so I'd
> > like to discuss making the one review per non-trival patch our base
> > minimum standard across the whole of LSF/MM; it would certainly
> > serve to improve our Reviewed-by statistics.
>
> Well, the mm track at least has some discussion of this last year:
> https://lwn.net/Articles/718212/
The pushback in your session was mandating reviews would mean slowing
patch acceptance or possibly causing the dropping of patches that
couldn't get reviewed. Michal did say that XFS didn't have the
problem, however there not being XFS people in the room, discussion
stopped there. Having this as a plenary would allow people outside mm
to describe their experiences and for us to look at process based
solutions using our shared experience.
James
next prev parent reply other threads:[~2018-01-24 21:36 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-24 19:05 [LSF/MM TOPIC] Patch Submission process and Handling Internal Conflict James Bottomley
2018-01-24 19:20 ` Mike Kravetz
2018-01-24 21:36 ` James Bottomley [this message]
2018-01-24 23:43 ` Darrick J. Wong
2018-01-31 16:21 ` Eric Sandeen
2018-01-24 19:26 ` Bart Van Assche
2018-01-24 21:45 ` James Bottomley
2018-01-25 10:02 ` Jan Kara
2018-01-25 10:28 ` Jan Kara
2018-01-26 12:13 ` Goldwyn Rodrigues
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=1516829760.3073.43.camel@HansenPartnership.com \
--to=james.bottomley@hansenpartnership.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-scsi@vger.kernel.org \
--cc=lsf-pc@lists.linux-foundation.org \
--cc=mike.kravetz@oracle.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