Guidelines for Submitting an RFC PATCH

Guidelines for Submitting an RFC PATCH

[Joe Smith]

Hi All,

I understand the guidelines for submitting a PATCH and they are quite
rigorous. What about submitting an RFC, since RFC is just to get early
comments do I have to make sure that each patch in the RFC compiles or
is it OK if all patches together compile and are there any other
corners that I can cut.

Regards

-- 
JS

Guidelines for Submitting an RFC PATCH

[valdis.kletnieks at vt.edu]

On Mon, 12 Mar 2018 12:26:38 -0700, Joe Smith said:
> I understand the guidelines for submitting a PATCH and they are quite
> rigorous. What about submitting an RFC, since RFC is just to get early
> comments do I have to make sure that each patch in the RFC compiles or
> is it OK if all patches together compile and are there any other
> corners that I can cut.

The fewer corners you cut at the RFC stage, the less fixing you'll have to do
if response is favorable.  In particular, making sure the patch series is
bisectable (by making sure the kernel will still build and run after each patch
in the series) will save you a lot of restructuring of your commits later.

Plus, there's always the danger that the subsystem maintainer will see the
series, decide it's both (a) needed and (b) just fine as it is, and commit it. :)

-------------- 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/20180312/f5245420/attachment.sig>

Guidelines for Submitting an RFC PATCH

[Greg KH]

On Mon, Mar 12, 2018 at 03:56:31PM -0400, valdis.kletnieks at vt.edu wrote:
> On Mon, 12 Mar 2018 12:26:38 -0700, Joe Smith said:
> > I understand the guidelines for submitting a PATCH and they are quite
> > rigorous. What about submitting an RFC, since RFC is just to get early
> > comments do I have to make sure that each patch in the RFC compiles or
> > is it OK if all patches together compile and are there any other
> > corners that I can cut.
> 
> The fewer corners you cut at the RFC stage, the less fixing you'll have to do
> if response is favorable.  In particular, making sure the patch series is
> bisectable (by making sure the kernel will still build and run after each patch
> in the series) will save you a lot of restructuring of your commits later.
> 
> Plus, there's always the danger that the subsystem maintainer will see the
> series, decide it's both (a) needed and (b) just fine as it is, and commit it. :)

Or they could be like me, and choose (c) and just ignore RFC patches as
obviously the submitter doesn't think it is worthy enough to be
committed, so why review it?  :)

thanks,

greg k-h

Guidelines for Submitting an RFC PATCH

[Joe Smith]

Thanks, Greg and Valdis.
An RFC patch by definition is not intended for submission. In cases
where the design is involved and the developer needs early input, why
go through all the hassle. The community could say I do not like it
and the whole effort would be useless. Once there is agreement then I
can see the need for all patches to be conformant.

Thanks,

On Mon, Mar 12, 2018 at 1:42 PM, Greg KH <greg@kroah.com> wrote:
> On Mon, Mar 12, 2018 at 03:56:31PM -0400, valdis.kletnieks at vt.edu wrote:
>> On Mon, 12 Mar 2018 12:26:38 -0700, Joe Smith said:
>> > I understand the guidelines for submitting a PATCH and they are quite
>> > rigorous. What about submitting an RFC, since RFC is just to get early
>> > comments do I have to make sure that each patch in the RFC compiles or
>> > is it OK if all patches together compile and are there any other
>> > corners that I can cut.
>>
>> The fewer corners you cut at the RFC stage, the less fixing you'll have to do
>> if response is favorable.  In particular, making sure the patch series is
>> bisectable (by making sure the kernel will still build and run after each patch
>> in the series) will save you a lot of restructuring of your commits later.
>>
>> Plus, there's always the danger that the subsystem maintainer will see the
>> series, decide it's both (a) needed and (b) just fine as it is, and commit it. :)
>
> Or they could be like me, and choose (c) and just ignore RFC patches as
> obviously the submitter doesn't think it is worthy enough to be
> committed, so why review it?  :)
>
> thanks,
>
> greg k-h



-- 
JS

Guidelines for Submitting an RFC PATCH

[Greg KH]

On Mon, Mar 12, 2018 at 03:48:52PM -0700, Joe Smith wrote:
> Thanks, Greg and Valdis.
> An RFC patch by definition is not intended for submission. In cases
> where the design is involved and the developer needs early input, why
> go through all the hassle. The community could say I do not like it
> and the whole effort would be useless. Once there is agreement then I
> can see the need for all patches to be conformant.

What do you mean exactly by "conformant"?  Why would you not write
"conformant" patches to start with?  You don't want to have to do double
the work by writing code in the wrong style first, and then having to go
back and rewrite it.

Anyway, be careful about RFC patches, you want to make it as easy as
possible for others to review your work, so don't give anyone an excuse
to _not_ read it.

thanks,

greg k-h

Guidelines for Submitting an RFC PATCH

[Joe Smith]

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.


On Tue, Mar 13, 2018 at 12:28 AM, Greg KH <greg@kroah.com> wrote:
> On Mon, Mar 12, 2018 at 03:48:52PM -0700, Joe Smith wrote:
>> Thanks, Greg and Valdis.
>> An RFC patch by definition is not intended for submission. In cases
>> where the design is involved and the developer needs early input, why
>> go through all the hassle. The community could say I do not like it
>> and the whole effort would be useless. Once there is agreement then I
>> can see the need for all patches to be conformant.
>
> What do you mean exactly by "conformant"?  Why would you not write
> "conformant" patches to start with?  You don't want to have to do double
> the work by writing code in the wrong style first, and then having to go
> back and rewrite it.
>
> Anyway, be careful about RFC patches, you want to make it as easy as
> possible for others to review your work, so don't give anyone an excuse
> to _not_ read it.
>
> thanks,
>
> greg k-h



-- 
JS

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>

Guidelines for Submitting an RFC PATCH

[Greg KH]

On Tue, Mar 13, 2018 at 08:52:01AM -0700, Joe Smith wrote:
> 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.

If you want other people to do work for you in reviewing code, you need
to make it as easy as possible for them to do that.  By showing that you
put in as little effort as necessary, that indicates to me that I should
put in little, if no, effort as well.  How do I know you are going to
then later on do the correct thing?  If not, that means my limited time
that I gave to you was wasted.

If you show that you care enough to do the job correctly, then I know
you are more invested in doing the right thing and so, I too will put in
the effort.

And really, this goes for almost everything in life, not just boring
kernel patches :)

good luck!

greg k-h

Guidelines for Submitting an RFC PATCH

[Joe Smith]

OK. Thanks.

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

Re: Guidelines for Submitting an RFC PATCH

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 854 bytes --]

On Mon 2018-03-12 16:01:08, Joe Smith wrote:
> Hi All,
> 
> What are the guidelines for submitting an RFC patch? If a developer
> wants to get early input on a design is it fine to submit a patch that
> is in reasonable shape but does not fully meets the requirements of a
> regular patch, for example, the patch consists of a series of patches,
> it only compiles when all patches in the series are applied. Going
> through the process of meeting all the patch requirements for an RFC
> patch seems too much.

There are not many guidelines for that. Just mark it RFC :-).

Series that only compiles when full would be fine for example. (But
you may get complains from 0 day testing bots, not sure).
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Guidelines for Submitting an RFC PATCH

[Joe Smith]

Hi All,

What are the guidelines for submitting an RFC patch? If a developer
wants to get early input on a design is it fine to submit a patch that
is in reasonable shape but does not fully meets the requirements of a
regular patch, for example, the patch consists of a series of patches,
it only compiles when all patches in the series are applied. Going
through the process of meeting all the patch requirements for an RFC
patch seems too much.

Regards


-- 
JS