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

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

[Jakub Kicinski]

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?

That's the question I was hoping to answer by reading this doc :)

For the small-time maintainers who aren't Linus including a lore link
to the resolution from linux-next is the most optimal way in my experience.
Sometimes people put the whole resolution diff into the PR message
which occasionally confuses merge prep scripts making a mess of things...

If Stephen already resolved the problem, just include the link.

Cc: torvalds@linux-foundation.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
---
 Documentation/maintainer/rebasing-and-merging.rst | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/Documentation/maintainer/rebasing-and-merging.rst b/Documentation/maintainer/rebasing-and-merging.rst
index 85800ce95ae5..4134e63528fe 100644
--- a/Documentation/maintainer/rebasing-and-merging.rst
+++ b/Documentation/maintainer/rebasing-and-merging.rst
@@ -175,7 +175,11 @@ So what should a maintainer do when there is a conflict between their
 subsystem branch and the mainline?  The most important step is to warn
 Linus in the pull request that the conflict will happen; if nothing else,
 that demonstrates an awareness of how your branch fits into the whole.  For
-especially difficult conflicts, create and push a *separate* branch to show
+conflicts already resolved in linux-next include a lore link to the posted
+resolution.
+
+For especially difficult conflicts and when linux-next resolution is
+not available, create and push a *separate* branch to show
 how you would resolve things.  Mention that branch in your pull request,
 but the pull request itself should be for the unmerged branch.
 
-- 
2.41.0

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

[Linus Torvalds]

On Thu, 13 Jul 2023 at 16:04, Jakub Kicinski <kuba@kernel.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

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

[Theodore Ts'o]

On Thu, Jul 13, 2023 at 05:47:18PM -0700, Linus Torvalds wrote:
> 
> 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.

Yeah, I normally do my own test merge.  I might check to see if it's
the same as the one which is in linux-next, but the more importantly,
I then run a full set of regression tests and make sure there are no
new test failures caused by the merge resolution.

					- Ted

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

[Jakub Kicinski]

On Thu, 13 Jul 2023 23:16:24 -0400 Theodore Ts'o wrote:
> On Thu, Jul 13, 2023 at 05:47:18PM -0700, Linus Torvalds wrote:
> > 
> > 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.  
> 
> Yeah, I normally do my own test merge.  I might check to see if it's
> the same as the one which is in linux-next, but the more importantly,
> I then run a full set of regression tests and make sure there are no
> new test failures caused by the merge resolution.

Alright, I guess we all end up intuiting in a similar way :)
In this case let's ditch the patch, it may do more harm than good.
Someone may read it as "if Stephen posted something - just point 
at it without thinking".