On Wed, Sep 30, 2020 at 12:33:39PM -0700, Joe Perches wrote:
quoted
On Tue, 2020-09-29 at 12:37 +0100, Mark Brown wrote:
quoted
Feel free to submit patches to b4.
Have you tried the existing option to send
thank you's on a specific ranges of patches?
I am relying on b4 to identify which patches that I've downloaded are in
the pushed branches. Given that it explicitly lists the patches that
are applied it appears to be doing an OK job here.
I'm not so sure about that.
The commit merge description in -next shows 23 files
modified but the commit range shown in the merge shows
only a single patch applied:
From next-20201002:
(I've removed some of the commit description below)
$ git log --stat -1 2defc3fa18a68963a330187f5386968e50832d06
commit 2defc3fa18a68963a330187f5386968e50832d06
Merge: eb45df24fe82 7f4a122d0b50
Author: Mark Brown [off-list ref]
Date: Mon Sep 28 18:28:48 2020 +0100
Merge series "use semicolons rather than commas to separate statements" from Julia Lawall [off-list ref]:
These patches replace commas by semicolons. This was done using the
Coccinelle semantic patch (http://coccinelle.lip6.fr/) shown below.
[some of the long description elided]
---
drivers/acpi/processor_idle.c | 4 +++-
drivers/ata/pata_icside.c | 21 +++++++++++++--------
drivers/base/regmap/regmap-debugfs.c | 2 +-
drivers/bcma/driver_pci_host.c | 4 ++--
drivers/block/drbd/drbd_receiver.c | 6 ++++--
drivers/char/agp/amd-k7-agp.c | 2 +-
drivers/char/agp/nvidia-agp.c | 2 +-
drivers/char/agp/sworks-agp.c | 2 +-
drivers/char/hw_random/iproc-rng200.c | 8 ++++----
drivers/char/hw_random/mxc-rnga.c | 6 +++---
drivers/char/hw_random/stm32-rng.c | 8 ++++----
drivers/char/ipmi/bt-bmc.c | 6 +++---
drivers/clk/meson/meson-aoclk.c | 2 +-
drivers/clk/mvebu/ap-cpu-clk.c | 2 +-
drivers/clk/uniphier/clk-uniphier-cpugear.c | 2 +-
drivers/clk/uniphier/clk-uniphier-mux.c | 2 +-
drivers/clocksource/mps2-timer.c | 6 +++---
drivers/clocksource/timer-armada-370-xp.c | 8 ++++----
drivers/counter/ti-eqep.c | 2 +-
drivers/crypto/amcc/crypto4xx_alg.c | 2 +-
drivers/crypto/atmel-tdes.c | 2 +-
drivers/crypto/hifn_795x.c | 4 ++--
drivers/crypto/talitos.c | 8 ++++----
23 files changed, 60 insertions(+), 51 deletions(-)
But the commit range of the merge shows only the single commit:
$ git log --stat eb45df24fe82..7f4a122d0b50
commit 7f4a122d0b50b40c64d24a5cf7aafe26dd9487ee
Author: Julia Lawall [off-list ref]
Date: Sun Sep 27 21:12:24 2020 +0200
regmap: debugfs: use semicolons rather than commas to separate statements
Replace commas with semicolons. What is done is essentially described by
the following Coccinelle semantic patch (http://coccinelle.lip6.fr/):
// <smpl>
@@ expression e1,e2; @@
e1
-,
+;
e2
... when any
// </smpl>
Signed-off-by: Julia Lawall [off-list ref]
Link: https://lore.kernel.org/r/1601233948-11629-15-git-send-email-Julia.La>
Signed-off-by: Mark Brown [off-list ref]
drivers/base/regmap/regmap-debugfs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Konstantin Ryabitsev <hidden> Date: 2020-10-03 19:15:08
On Sat, Oct 03, 2020 at 11:40:48AM -0700, Joe Perches wrote:
(Adding tools and Konstantin Ryabitsev)
There seems to be some mismatch between b4's use of the
cover letter to a patch series and what maintainers that
apply a subset of the patches in the patch series.
The merge description shows the entire patch series as
applied, but the actual merge is only a subset of the
series.
Can this be improved in b4?
So, the following logic should be applied:
- if the entire series was applied, reply to 0/n
- if a subset only is applied, reply to each n/n of the patch that was
cherry-picked out of the series
Is that an accurate summary?
-K
From: Julia Lawall <julia.lawall@inria.fr> Date: 2020-10-03 19:18:57
On Sat, 3 Oct 2020, Konstantin Ryabitsev wrote:
On Sat, Oct 03, 2020 at 11:40:48AM -0700, Joe Perches wrote:
quoted
(Adding tools and Konstantin Ryabitsev)
There seems to be some mismatch between b4's use of the
cover letter to a patch series and what maintainers that
apply a subset of the patches in the patch series.
The merge description shows the entire patch series as
applied, but the actual merge is only a subset of the
series.
Can this be improved in b4?
So, the following logic should be applied:
- if the entire series was applied, reply to 0/n
- if a subset only is applied, reply to each n/n of the patch that was
cherry-picked out of the series
Is that an accurate summary?
From: Joe Perches <joe@perches.com> Date: 2020-10-03 19:27:11
On Sat, 2020-10-03 at 15:15 -0400, Konstantin Ryabitsev wrote:
On Sat, Oct 03, 2020 at 11:40:48AM -0700, Joe Perches wrote:
quoted
(Adding tools and Konstantin Ryabitsev)
There seems to be some mismatch between b4's use of the
cover letter to a patch series and what maintainers that
apply a subset of the patches in the patch series.
The merge description shows the entire patch series as
applied, but the actual merge is only a subset of the
series.
Can this be improved in b4?
So, the following logic should be applied:
- if the entire series was applied, reply to 0/n
- if a subset only is applied, reply to each n/n of the patch that was
cherry-picked out of the series
Is that an accurate summary?
From: Konstantin Ryabitsev <hidden> Date: 2020-10-03 19:31:51
On Sat, Oct 03, 2020 at 09:18:51PM +0200, Julia Lawall wrote:
quoted
quoted
There seems to be some mismatch between b4's use of the
cover letter to a patch series and what maintainers that
apply a subset of the patches in the patch series.
The merge description shows the entire patch series as
applied, but the actual merge is only a subset of the
series.
Can this be improved in b4?
So, the following logic should be applied:
- if the entire series was applied, reply to 0/n
- if a subset only is applied, reply to each n/n of the patch that was
cherry-picked out of the series
Is that an accurate summary?
That sounds good.
I'm worried that this can get unwieldy for series of 50 patches where 49
got applied. Would the following be better:
-----
From: ...
To: ...
Subject: Re: [PATCH 00/18] use semicolons...
On Sun...
These patches...
[...]
A subset of these patches was applied to
https://...
Thanks!
[5/18] regmap: debugfs:
commit:
(etc)
-----
In other words, we:
- specifically say that it's a subset
- instead of just enumerating the number of patches that were applied,
as is currently the case ([1/1]) we list the exact numbers out of the
posted series (e.g. [5/18])
I think this is a better solution than potentially flooding everyone
with 49 emails.
-K
From: Joe Perches <joe@perches.com> Date: 2020-10-03 19:36:20
On Sat, 2020-10-03 at 12:27 -0700, Joe Perches wrote:
On Sat, 2020-10-03 at 15:15 -0400, Konstantin Ryabitsev wrote:
quoted
On Sat, Oct 03, 2020 at 11:40:48AM -0700, Joe Perches wrote:
quoted
(Adding tools and Konstantin Ryabitsev)
There seems to be some mismatch between b4's use of the
cover letter to a patch series and what maintainers that
apply a subset of the patches in the patch series.
The merge description shows the entire patch series as
applied, but the actual merge is only a subset of the
series.
Can this be improved in b4?
So, the following logic should be applied:
- if the entire series was applied, reply to 0/n
- if a subset only is applied, reply to each n/n of the patch that was
cherry-picked out of the series
Is that an accurate summary?
Exactly so, thanks.
And there's no need to commit the [0/n] cover letter as a
part of the merge unless the entire series was committed.
Or perhaps trim the cover letter to exclude the files
modified by the patch series and show only the actual files
committed.
And I believe b4 inserts this line ahead of the 0/n series
cover letter description for the merge:
Merge series "<series>" from <author>:
Perhaps that like could be "partial merge of" when a partial
merge occurs or left as is if the entire series is applied.
cheers, Joe
From: Joe Perches <joe@perches.com> Date: 2020-10-03 19:43:23
On Sat, 2020-10-03 at 15:31 -0400, Konstantin Ryabitsev wrote:
On Sat, Oct 03, 2020 at 09:18:51PM +0200, Julia Lawall wrote:
quoted
quoted
quoted
There seems to be some mismatch between b4's use of the
cover letter to a patch series and what maintainers that
apply a subset of the patches in the patch series.
The merge description shows the entire patch series as
applied, but the actual merge is only a subset of the
series.
Can this be improved in b4?
So, the following logic should be applied:
- if the entire series was applied, reply to 0/n
- if a subset only is applied, reply to each n/n of the patch that was
cherry-picked out of the series
Is that an accurate summary?
That sounds good.
I'm worried that this can get unwieldy for series of 50 patches where 49
got applied. Would the following be better:
-----
From: ...
To: ...
Subject: Re: [PATCH 00/18] use semicolons...
On Sun...
quoted
These patches...
[...]
A subset of these patches was applied to
https://...
Thanks!
[5/18] regmap: debugfs:
commit:
(etc)
-----
In other words, we:
- specifically say that it's a subset
- instead of just enumerating the number of patches that were applied,
as is currently the case ([1/1]) we list the exact numbers out of the
posted series (e.g. [5/18])
I think this is a better solution than potentially flooding everyone
with 49 emails.
I think it would be better to reply individually as
the likelihood that the maintainer skips just a few
patches of a large series is relatively low.
It's more likely for a treewide or multi-subsystem
patch set for a maintainer to apply just a single one
or a selected few of the patches and individual
replies make it much easier to determine which ones
were applied.
thanks, Joe
From: Mark Brown <broonie@kernel.org> Date: 2020-10-05 16:53:15
On Sat, Oct 03, 2020 at 12:43:13PM -0700, Joe Perches wrote:
On Sat, 2020-10-03 at 15:31 -0400, Konstantin Ryabitsev wrote:
quoted
I'm worried that this can get unwieldy for series of 50 patches where 49
got applied. Would the following be better:
...
quoted
A subset of these patches was applied to
https://...
Thanks!
[5/18] regmap: debugfs:
commit:
It's definitely an improvement but TBH I'm not sure how much it's going
to help those struggling to parse the current messages.
quoted
I think this is a better solution than potentially flooding everyone
with 49 emails.
I would tend to prefer cutting down on mail volume but I don't think
there's any way to keep everyone happy with this stuff.
I think it would be better to reply individually as
the likelihood that the maintainer skips just a few
patches of a large series is relatively low.
It's not at all unusual for driver updates to both add new DT bindings
(either for entirely new drivers or new properties/compatibles for
existing drivers) and also have DTS file updates using those bindings,
these go via separate trees.