From: Sven Eckelmann <sven@narfation.org>
Cc: Jakub Kicinski <kuba@kernel.org>,
Konstantin Ryabitsev <konstantin@linuxfoundation.org>,
Paolo Abeni <pabeni@redhat.com>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
Ao Zhou <n05ec@lzu.edu.cn>, Haoze Xie <royenheart@gmail.com>,
Jiexun Wang <wangjiexun2025@gmail.com>,
Juefei Pu <tomapufckgml@gmail.com>,
Luxing Yin <tr0jan@lzu.edu.cn>, Ruide Cao <caoruide123@gmail.com>,
Xin Liu <bird@lzu.edu.cn>, Yifan Wu <yifanwucs@gmail.com>,
Yuan Tan <yuantan098@gmail.com>, Joe Perches <joe@perches.com>
Subject: Re: [PATCH batadv 0/8] batman-adv: follow up fixes
Date: Tue, 05 May 2026 09:20:03 +0200 [thread overview]
Message-ID: <2313096.ZfL8zNpBrT@ripper> (raw)
In-Reply-To: <c75c7d50-36b2-4397-8355-891c83d663c9@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 3651 bytes --]
On Tuesday, 5 May 2026 07:21:13 CEST Matthieu Baerts wrote:
[...]
> >>> Are you CCing netdev to get this reviewed by Sashiko?
> >>> Please don't..
> >>> We delegate code to sub-sub-systems to lower the patch volume :(
> >>>
> >>
> >> Because of `b4 prep --auto-to-cc`. Will now manually remove you.
> >
> > To speed up the discussion: @Konstantin, is there a way in b4 to say "stop at
> > the sub-sub-systems" when doing `b4 prep --auto-to-cc`? I am just trying to get the
> > `b4` workflow somehow working with the netdev requirements.
>
> Maybe a new option could be added, but that seems difficult to guess
> where to stop, and to which subsystems to apply this.
>
> Can you not simply omit using `b4 prep --auto-to-cc` when working
> with "internal" patches?
Yes, no, maybe :)
I will for the moment ignore the .b4-config part and talk about it at the end
of the mail.
b4 is trying to (afaik) to have a good common work flow for kernel related
projects (and more). Independent of my role (if I am the maintainer or just
another contributor), it will nag before a send: "Hey, please run
--auto-to-cc, --check, --check-deps before you submit this patch(set) - you
know how embarrassing it is when you notice some obvious problem 2 seconds
after the SMTP server accepted your mail."
And I agree with this and also try to convince people to try b4 because I
think it is really helpful. Or at least ask them to use
`./scripts/get_maintainer.pl` and NOT send patches with the prefix "net" or
"net-next" when it actually targets our tree. But as it turns out, these
recommendation seem to have been wrong and I am sorry about this.
And I know, b4 is a good tool but adding a bazillion options just for every
special case doesn't make a lot of sense and might make it a worse tool. I was
therefore more thinking about `scripts/get_maintainer.pl` (see `b4.send-auto-
cc-cmd`) which also called by b4 with various options to avoid adding too many
people.
I don't say that any of these tools need to change. I am guessing more that I
have to adjust something (MAINTAINERS, ...) to avoid that people are sending
batman-adv sub-sub-system patches directly to netdev. I am just not aware of
what this should be. But it sounds to me like there is at least a need for it
(from the netdev maintainers perspective).
> On my side, that's what I'm doing. I added a .b4-config file with this
> content, not to have to specify --set-prefix nor --to:
Regarding the .b4-config - yes, this is helpful and I should add it to
batctl.git. I was more thinking about the normal contributor to
net/batman-adv/. Regardless of this person taking as base net/net-next.git or
our repo.
The fixes from Ren Wei (and associates) and some other people were sent with
"net" in the prefix, were Cc'ing netdev and didn't seem to use our tree as
base. This is of course not correct and they should have targeted our tree
instead. I didn't complain because the fix was otherwise extremely helpful and
I though that there was no harm done. As it looks now, I should have and I am
sorry for not communicating this.
And I am at the moment not sure how to fix this without overloading
contributers with "when you are contributing to some sub-subsystem of netdev
..., but when you are contributing to ext4, other rules apply .... don't
forget about i2c rules for patch submission, ...".
But maybe I am just ignorant and this is already quite simple (and there are
no special "netdev" rules) - I am just not aware of it. In this case, please
point me in the right direction, just to avoid reproducing wrong
recommendations to other people.
Regards,
Sven
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
next prev parent reply other threads:[~2026-05-05 7:20 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-03 12:22 [PATCH batadv 0/8] batman-adv: follow up fixes Sven Eckelmann
2026-05-03 12:22 ` [PATCH batadv 1/8] batman-adv: tp_meter: fix tp_num leak on kmalloc failure Sven Eckelmann
2026-05-03 12:22 ` [PATCH batadv 2/8] batman-adv: bla: prevent use-after-free when deleting claims Sven Eckelmann
2026-05-03 12:22 ` [PATCH batadv 3/8] batman-adv: bla: only purge non-released claims Sven Eckelmann
2026-05-03 12:22 ` [PATCH batadv 4/8] batman-adv: tt: fix negative tt_buff_len Sven Eckelmann
2026-05-03 12:22 ` [PATCH batadv 5/8] batman-adv: tt: reject oversized local TVLV buffers Sven Eckelmann
2026-05-03 12:22 ` [PATCH batadv 6/8] batman-adv: tt: fix TOCTOU race for reported vlans Sven Eckelmann
2026-05-03 12:22 ` [PATCH batadv 7/8] batman-adv: tt: avoid empty VLAN responses Sven Eckelmann
2026-05-03 12:22 ` [PATCH batadv 8/8] batman-adv: tt: prevent TVLV entry number overflow Sven Eckelmann
2026-05-05 0:10 ` [PATCH batadv 0/8] batman-adv: follow up fixes Jakub Kicinski
2026-05-05 4:46 ` Sven Eckelmann
2026-05-05 5:00 ` Sven Eckelmann
2026-05-05 5:21 ` Matthieu Baerts
2026-05-05 7:20 ` Sven Eckelmann [this message]
2026-05-05 23:02 ` Yuan Tan
2026-05-06 0:20 ` Jakub Kicinski
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=2313096.ZfL8zNpBrT@ripper \
--to=sven@narfation.org \
--cc=bird@lzu.edu.cn \
--cc=caoruide123@gmail.com \
--cc=joe@perches.com \
--cc=konstantin@linuxfoundation.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=n05ec@lzu.edu.cn \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=royenheart@gmail.com \
--cc=tomapufckgml@gmail.com \
--cc=tr0jan@lzu.edu.cn \
--cc=wangjiexun2025@gmail.com \
--cc=yifanwucs@gmail.com \
--cc=yuantan098@gmail.com \
/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