Re: pull request: bluetooth 2024-10-16

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 21 Oct 2024 at 01:22, Thorsten Leemhuis
<regressions@xxxxxxxxxxxxx> 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




[Index of Archives]     [Bluez Devel]     [Linux Wireless Networking]     [Linux Wireless Personal Area Networking]     [Linux ATH6KL]     [Linux USB Devel]     [Linux Media Drivers]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Big List of Linux Books]

  Powered by Linux