diff mbox series

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

Message ID 20230713230417.1504773-1-kuba@kernel.org
State New
Headers
Series [docs] docs: maintainers: suggest including lore link for conflicts known to linux-next |

Commit Message

Jakub Kicinski July 13, 2023, 11:04 p.m. UTC 
  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(-)

Comments

Linus Torvalds July 14, 2023, 12:47 a.m. UTC | #1 
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
Theodore Ts'o July 14, 2023, 3:16 a.m. UTC | #2 
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
Jakub Kicinski July 14, 2023, 3:44 p.m. UTC | #3 
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".
diff mbox series

Patch

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.