Re: [LSF/MM TOPIC] Patch Submission process and Handling Internal Conflict

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]
  Powered by Linux