Guidelines for Submitting an RFC PATCH

[Joe Smith]

OK. Thanks.

On Tue, Mar 13, 2018 at 11:10 AM,  <valdis.kletnieks at vt.edu> wrote:
> 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.
>



-- 
JS