Re: [PATCH] docs: submit-checklist: structure by category

[Randy Dunlap <rdunlap@infradead.org>]

Hi Lukas,

I'll review the file changes separately. This is just replying
to the patch description comments.


On 2/26/24 02:46, Lukas Bulwahn wrote:
> While going through the submit checklist, the list order seemed rather
> random, probably just by historical coincidences of always adding yet the
> next point someone thought of at the end of the list.

Probably.

> Structure and order them by the category of such activity,
> reviewing, documenting, checking with tools, building and testing.
> 
> As the diff of the reordering is large:
> Review code now includes previous points 1, 5 and 22.
> Review Kconfig includes previous 6, 7 and 8.
> Documenting includes previous 11, 15, 16, 17, 18 and 23.
> Checking with tools includes previous 5, 9 and 10.
> Building includes previous 2, 3, 20 and 24.
> Testing includes previous 12, 13, 14, 19 and 21.
> 
...

> 
> The recommendation to test with the -mm patchset (previous 21, now
> testing, point 5) was updated to the current state of affairs to test with
> a recent tag of linux-next.

ack.

> Note that the previous first point still remains the first list even after
> reordering. Based on some vague memory, the first point was important to
> Randy to stay the first one in any reordering.

Yes, I have said that. Stephen Rothwell wanted it to be first in the list.


> While at it, the reference to CONFIG_SLUB_DEBUG was replaced by
> CONFIG_DEBUG_SLAB.

I don't understand this comment. DEBUG_SLAB is gone.
I think those 2 symbols might be reversed in your comments. ?


> Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
> ---
> So far, no point disappeared and nothing new was added.
> 

That's a good start IMO.

> Points/Ideas for further improvements (based on my knowledge and judgement):
> 
>   - The Review Kconfig changes makes sense, but I am not sure if they are
>     so central during review. If we keep it, let us see if there are other
>     parts for review that are also important similar to Kconfig changes.
>    
>   - Concerning checking with tools, checkpatch probably still makes sense;
>     it pointed out in several places. If sparse and checkstack are really
>     the next two tools to point out, I am not so sure about.

I doubt that ckeckstack is important since gcc & clang warn us about
stack usage.

>     sparse has a lot of false positives nowadays, and many things are not
>     fixed just because sparse complains about it.
>     And I have never used make checkstack and have not found much
>     documentation about it.
>     So, maybe other tools deserve to be mentioned here instead?
> 
> I am happy to get feedback---I will work through submitting-patches next
> and do some clean-up there. While doing that, I might learn what really
> should go into a better future 'submit-checklist' documentation.
> 
>  Documentation/process/submit-checklist.rst | 157 +++++++++++----------
>  1 file changed, 84 insertions(+), 73 deletions(-)


-- 
#Randy