linux-kernel - Re: [PATCH docs] docs: maintainers: suggest including lore link for conflicts known to linux-next

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] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 13 Jul 2023 17:47:18 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     corbet@....net, workflows@...r.kernel.org,
        linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH docs] docs: maintainers: suggest including lore link for
 conflicts known to linux-next

On Thu, 13 Jul 2023 at 16:04, Jakub Kicinski <kuba@...nel.org> wrote:
>
> I'm not completely sure what is the best practice for notifying Linus
> about conflicts which have already been resolved in linux-next.
> I presume they are a no-op to him, so maybe we shouldn't even call
> them out?

No, I do *not* somehow auto-merge stuff that has been merged in
linux-next. I will do my own merge, and see the conflicts, and I will
resolve them independently of anything that has happened in
linux-next.

I may then check what linux-next did, particularly if the merge was
non-trivial, but honestly, that's fairly rare. And if the merge was so
non-trivial that I check what happened in linux-next, it's actually
not all that unlikely that I ended up resolving it differently anyway.
I send out emails saying "that was wrong in linux-next" somewhat
regularly.

So if you were notified by Stephen that there is a conflict in
linux-next, and it has been resolved there, that means that as far as
linux-next is concerned - and *only* as fat as linux-next is concerned
- that resolution will now continue to be done in linux-next.

But you should preferably mention said conflict when you then send the
pull request to me.

It's perfectly fine to just mention it - say "there's a conflict in
so-and-so with the pull from tree so-and-so". That will give me a
heads-up to not be surprised about it.

You can point to the email that Stephen sent (using lore), or you can
quote his resolution (or your own, if you do a test-merge, like many
people do) if you want.  It's not a requirement.

But I do kind of want to see the "there's a conflict" mention, not
just to have a heads-up. It's also a sign that you are actually
keeping track of what happens in linux-next and are on top of things.

Because I've had _too_ many pull requests that actually turned out to
have had problems in linux-next - merge related or not - and the
developer having not tracked anything at all despite having been told
about said problems, and just sent the resulting untested crap to me.

So the "there's a conflict" note ends up having that kind of secondary
meaning. It gives me the warm and fuzzies that the developer has
actually reacted to what happened in linux-next.

The corollary to that is that when I see a conflict - even if it's
completely trivial - and I see it in linux-next too, and the conflict
was never mentioned, I go "ok, this maintainer never actually reacted
to anything that Stephen said about his tree".

That often says more about the situation in general than about the
particular conflict.

             Linus