From: FMDF <fmdefrancesco@gmail.com>
To: "Valdis Klētnieks" <valdis.kletnieks@vt.edu>,
kernelnewbies <kernelnewbies@kernelnewbies.org>
Subject: Fwd: Commit messages in a series of patches
Date: Mon, 20 Sep 2021 11:17:22 +0200 [thread overview]
Message-ID: <CAPj211t0SbbsXELRRtGq2n4C35OLpy9ysoTXgAgj7E2BVFPmTg@mail.gmail.com> (raw)
In-Reply-To: <CAPj211ufxfjritLEc8n11=OLXFFjGSAMacvgOAb2usOeS0LEwg@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 3680 bytes --]
I'm sorry but, for some reason, the address of kernelnewbies list was
missing in my reply to Valdis. So I had to resend it.
---------- Forwarded message ---------
From: FMDF <fmdefrancesco@gmail.com>
Date: Mon, 20 Sep 2021, 11:13
Subject: Re: Commit messages in a series of patches
To: Valdis Klētnieks <valdis.kletnieks@vt.edu>
On Fri, 17 Sep 2021, 23:58 Valdis Klētnieks, <valdis.kletnieks@vt.edu>
wrote:
> On Fri, 17 Sep 2021 11:12:45 +0200, FMDF said:
>
> > My question is: why "This patch is preparation for _io_ops [future]
> > structure removal." is good while "Eventually this function will be
> > deleted but some of the code will be reused later." is not.
>
My fault. I should have provided more context to you: here I copy-paste the
relevant part of the commit message...
>"Clean up usbctrl_vendoreq () in usb_ops_linux.c. Eventually this function
> will be deleted but some of the code will be reused later. This cleanup
> makes code reuse easier.".
The first is specific about what is being changed
This is about what is being changed: "Clean up usbctrl_vendoreq () in
usb_ops_linux.c".
and why,
"This cleanup makes code reuse easier.".
and tells the
> reviewer what to watch for.
"Eventually this function [it is clear we're still talking about
usbctrl_vendorreq()] will be deleted but some of the code will be reused
later.".
Also, the reviewer now knows where to look for
> justification - there is hopefully a 0/N patch that explains why and how
> this
> structure is being removed.
>
Yes, patch 14/19 delete that _io_ops structure and explains why . In the
same way, 18/19 has the deletion of usbctrl_vendorreq() and the commit
message explains why. That should provide the "why and how this structure
is being removed" (obviously, replace "structure" with "function").
The second doesn't say which "this function" is being removed,
Again, usbctrl_vendorreq(). Please re-read the commit message I pasted here
if you have doubts.
why this is
> being done,
Again, this is explained later in 18/19, exactly how (later) in 14/19 is
also explained why _io_ops structure is removed. I can't see any conceptual
difference, can you?
or whether the changes were internal to the function, or in other
> functions.
It is pretty clear that, when we write ""Eventually this function [it is
clear we're still talking about usbctrl_vendorreq()] will be deleted but
some of the code will be reused later.", we make it clear that the
cleaned-up code cannot be reused in the original function because it is
going to be deleted. Anyway this is not the point: the Reviewer writes that
"[he] is not interested in our future plans", so he asks for the removal of
the phrase "Eventually this function will be deleted...".
Why didn't he ask also for the removal of "This patch is in preparation of
the _io_ops removal"? That is the question: why didn't he say that he is
not also interested in [future] plans about _io_ops?
It also doesn't explain why or how code will be re-used.
>
Do you mean that I should have mentioned the names of the two new functions
that we create in later patches? I mean those functions that reuse part of
the code of the deleted usbctrl_vendorreq? If so, what about "we are not
interested in your future plans"?
The distinction matters, because the biggest point of reviewing is "Does
> this
> commit do what was intended?" Answering that question is a lot easier when
> it's clear what was intended.
>
I'm sorry but, after all that has already been said, I am not able to
understand the comment above.
Thanks,
Fabio
[-- Attachment #1.2: Type: text/html, Size: 7040 bytes --]
[-- Attachment #2: Type: text/plain, Size: 170 bytes --]
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
prev parent reply other threads:[~2021-09-20 9:22 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-17 9:12 Commit messages in a series of patches FMDF
2021-09-17 21:58 ` Valdis Klētnieks
[not found] ` <CAPj211ufxfjritLEc8n11=OLXFFjGSAMacvgOAb2usOeS0LEwg@mail.gmail.com>
2021-09-20 9:17 ` FMDF [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=CAPj211t0SbbsXELRRtGq2n4C35OLpy9ysoTXgAgj7E2BVFPmTg@mail.gmail.com \
--to=fmdefrancesco@gmail.com \
--cc=kernelnewbies@kernelnewbies.org \
--cc=valdis.kletnieks@vt.edu \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).