netdev - Re: pull request: bluetooth 2024-10-16

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAHk-=wgQhFPvneqAVXjUZDq=ahpATdgfg6LZ9n07MSSUGkQWuA@mail.gmail.com>
Date: Mon, 21 Oct 2024 11:06:45 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Thorsten Leemhuis <regressions@...mhuis.info>
Cc: Luiz Augusto von Dentz <luiz.dentz@...il.com>, davem@...emloft.net, kuba@...nel.org, 
	linux-bluetooth@...r.kernel.org, netdev@...r.kernel.org, 
	Linux kernel regressions list <regressions@...ts.linux.dev>, Eric Dumazet <edumazet@...gle.com>, 
	Paolo Abeni <pabeni@...hat.com>
Subject: Re: pull request: bluetooth 2024-10-16

On Mon, 21 Oct 2024 at 01:22, Thorsten Leemhuis
<regressions@...mhuis.info> wrote:
>
> Just to clarify: I assume it's the "taking things directly and thus
> bypassing -net" that is the problem here?

Well, it's not a *problem* per se. It's just not something I want to
be a regular occurrence, because then the lines of responsibility get
less clear.

And we've seen (many times) how that causes a kind of "bystander
effect" where everybody kind of just expects somebody else to handle
it, and things start falling through the cracks.

IOW: having clear lines of "this goes here" just avoids a lot of waffling.

So that's actually one of the main things about being a maintainer:
sure, there's the whole "enough technical knowledge to be able to
handle it", but a *lot* of maintainership is literally just about
being responsible (and responsive) for some area, and people _knowing_
you're responsible for that area, so that there is less of the "who
should take care of this patch" confusion.

That said, in situations like this, where some small part missed a
regular subsystem pull request, I don't think it's problematic to just
go "let's bypass the subsystem, and get just this thing fixed asap".

Not when it happens rarely (like this time), and not when it happens
in a way where everybody is aware of it (like this time).

So I think in this case it was probably *better* to just pull a very
small and targeted fix for bluetooth issues, than have the networking
tree send me out-of-sequence pull request that had other things too in
addition to a high-priority bluetooth fix.

Put another way: having clear lines of maintainership is important,
but it's also important to not make things *too* black-and-white.

Exceptions are fine, as long as they clearly remain the unusual case
and people explain them.

(That is basically true of pretty much everything. A lot of the
development rules like "don't rebase" are things where the occasional
exception with an _explanation_ for why it happened is perfectly fine)

Developers are people. Black-and-white rules are for machines.

                Linus