On Mon, May 8, 2017 at 7:03 PM, Michael Ellerman <mpe@xxxxxxxxxxxxxx> wrote:
> You mean this conflict, or was there more? Sure it's annoying, but it's
> hardly the worst conflict ever. I really think Linus could have coped
> with it.
Yeah, I do tens of conflicts a day during the merge window, no worries
about conflicts.
I do tend to want to be *notified* about the conflicts, though.
That's not because conflicts are bad per se, or because I'd find them
hard to resolve (most are trivial). It's mostly because I want to know
that both parties knew about the conflict and it was seen in -next,
which just makes me feel a lot better about the it.
Why? Exactly the same way I don't want submaintainers to silently fix
up conflicts for me, because I want to be aware of where conflicts
happened, I also want to know in turn that the submaintainers knew
about it too.
So to me, it's largely about *awareness*, not about "conflicts are
hard to handle". I want to be aware of the conflicts, but I also want
the people who caused them to be aware of them, and realize that
"oops, we're stepping on each others toes".
So conflicts aren't bad per se. Conflicts are really only bad if they
cause subtle problems because people weren't even aware of them, or if
they *keep*on* happening.
The occasional random conflict that people knew about just isn't a problem.
But if the same subsystem just keeps on generating conflicts with
others time and again, _that_ is indicative of a real problem. And
then the problem isn't the conflict per se, but the fact that two
submaintainers keep on stepping on each others toes, and we need to
figure out why, and how to solve it. So even then, the problem isn't
about resolving the conflict itself, but about resolving whatever
issue in our code flow that keeps causing that kind of annoying
friction.
The same is true of cherry-picking and even the occasional rebase. If
a cherry-pick happens once in a blue moon and we have a duplicate
commit, that's *fine*. It can cause conflicts too (perhaps the
cherry-pick was followed by new development of the same area on one of
the branches), but there are perfectly natural and valid reasons why
the same commit could show up on multiple branches.
It's only if it ends up being a "pattern" - some developer keeps on
duplicating the commits in one branch that I see in other branches too
- that it is a problem. That, again, indicates that there's something
wrong in the process.
Linus
--
To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
