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 at 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