Guidelines for Submitting an RFC PATCH

[valdis.kletnieks at vt.edu]

On Tue, 13 Mar 2018 08:52:01 -0700, Joe Smith said:
> By conformant I mean for example that it has to compile or if the
> patch consists of a series of patches each patch applied individually
> should compile. That is a lot of work for something that is just being
> presented to ask for an opinion.

You'll have to do that "make the series bisectable" eventually. Doing it
correctly right from the start adds less effort than you'll spend trying to
carve up one creeping-horror monster patch into pieces.

If you make it bisectable up front, it will make it easier for you to debug
your code - bisecting through 20 or 30 patches is a lot faster than scratching
your head and going through one big patch line by line, or going through 20 or
30 patches linearly.

And yes, stuff like "patch 17 exposes a previously untested bug
in patch 2" happens.  All The Time.

As Greg mentioned, it's a lot easier to review a set of 10 50 line patches
each of which does one small thing that a reviewer can wrap their brain around
than one 500 line patch that does 10 things - and little to no indication of
which of the 10 things any one piece does.  It's particularly painful when one
chunk of the diff has both a "change to a new API" component and then a "now
that we have a new API, we can make this simplification" component.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 486 bytes
Desc: not available
URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20180313/5546ca4a/attachment.sig>