From: Matthieu Baerts <matttbe@kernel.org>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Jakub Kicinski <kuba@kernel.org>,
davem@davemloft.net, netdev@vger.kernel.org, edumazet@google.com,
pabeni@redhat.com, corbet@lwn.net, workflows@vger.kernel.org,
linux-doc@vger.kernel.org, andrew@lunn.ch,
jesse.brandeburg@intel.com, sd@queasysnail.net,
horms@verge.net.au, przemyslaw.kitszel@intel.com,
f.fainelli@gmail.com, jiri@resnulli.us, ecree.xilinx@gmail.com
Subject: Re: [PATCH net-next] docs: try to encourage (netdev?) reviewers
Date: Tue, 10 Oct 2023 19:06:21 +0200 [thread overview]
Message-ID: <5dae1994-cc61-4c4e-bbb0-55511e2fc5dd@kernel.org> (raw)
In-Reply-To: <CAMuHMdXXO3jHWkry6NNuvF_nQkvfb87b_Ca8E_so=1LWghrV9w@mail.gmail.com>
Hi Geert,
On 10/10/2023 17:52, Geert Uytterhoeven wrote:
> Hi Matt,
>
> On Tue, Oct 10, 2023 at 5:19 PM Matthieu Baerts <matttbe@kernel.org> wrote:
>> On 10/10/2023 00:56, Jakub Kicinski wrote:
>>> Add a section to netdev maintainer doc encouraging reviewers
>>> to chime in on the mailing list.
>>>
>>> The questions about "when is it okay to share feedback"
>>> keep coming up (most recently at netconf) and the answer
>>> is "pretty much always".
>>>
>>> Extend the section of 7.AdvancedTopics.rst which deals
>>> with reviews a little bit to add stuff we had been recommending
>>> locally.
>>
>> Good idea to encourage everybody to review, even the less experimented
>> ones. That might push me to send more reviews, even when I don't know
>> well the area that is being modified, thanks! :)
>>
>> (...)
>>
>>> diff --git a/Documentation/process/7.AdvancedTopics.rst b/Documentation/process/7.AdvancedTopics.rst
>>> index bf7cbfb4caa5..415749feed17 100644
>>> --- a/Documentation/process/7.AdvancedTopics.rst
>>> +++ b/Documentation/process/7.AdvancedTopics.rst
>>> @@ -146,6 +146,7 @@ pull. The git request-pull command can be helpful in this regard; it will
>>> format the request as other developers expect, and will also check to be
>>> sure that you have remembered to push those changes to the public server.
>>>
>>> +.. _development_advancedtopics_reviews:
>>>
>>> Reviewing patches
>>> -----------------
>>> @@ -167,6 +168,12 @@ comments as questions rather than criticisms. Asking "how does the lock
>>> get released in this path?" will always work better than stating "the
>>> locking here is wrong."
>>
>> The paragraph just above ("it is OK to question the code") is very nice!
>> When I'm cced on some patches modifying some code I'm not familiar with
>> and there are some parts that look "strange" to me, I sometimes feel
>> like I only have two possibilities: either I spend quite some time
>> understanding that part or I give up if I don't have such time. I often
>> feel like I cannot say "I don't know well this part, but this looks
>> strange to me: are you sure it is OK to do that in such conditions?",
>> especially when the audience is large and/or the author of the patch is
>> an experienced developer.
>
> Yes you can (even experienced developers can make mistakes ;-)!
Thank you for your reply!
> If it is not obvious that something is safe, it is better to point it
> out, so the submitter (or someone else) can give it a (second) thought.
> In case it is safe, and you didn't miss the ball completely, it probably
> warrants a comment in the code, or an improved patch description.
Indeed, good point!
It is good then to have that written in the doc -- I only discovered it
recently -- because, at least for me, it is easy to think that
experienced developers never make mistakes ( ;) ) and questioning their
code can only be done if we have double or triple checked that there is
likely an issue :)
Cheers,
Matt
--
Tessares | Belgium | Hybrid Access Solutions
www.tessares.net
prev parent reply other threads:[~2023-10-10 17:07 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-09 22:56 [PATCH net-next] docs: try to encourage (netdev?) reviewers Jakub Kicinski
2023-10-10 8:41 ` Donald Hunter
2023-10-10 15:19 ` Matthieu Baerts
2023-10-10 15:52 ` Geert Uytterhoeven
2023-10-10 17:06 ` Matthieu Baerts [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5dae1994-cc61-4c4e-bbb0-55511e2fc5dd@kernel.org \
--to=matttbe@kernel.org \
--cc=andrew@lunn.ch \
--cc=corbet@lwn.net \
--cc=davem@davemloft.net \
--cc=ecree.xilinx@gmail.com \
--cc=edumazet@google.com \
--cc=f.fainelli@gmail.com \
--cc=geert@linux-m68k.org \
--cc=horms@verge.net.au \
--cc=jesse.brandeburg@intel.com \
--cc=jiri@resnulli.us \
--cc=kuba@kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=przemyslaw.kitszel@intel.com \
--cc=sd@queasysnail.net \
--cc=workflows@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.