On 09/05/2017 04:17, Linus Torvalds wrote: > 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". Good, that was my understanding - and I wanted to single out this conflict because 1) I wasn't even sure if Paul was aware of it, since the conflict surprised me when doing my own trial merge. I'd like to be aware of arch vs. KVM conflicts, just like Linus, so that I can relay the information to him precisely; 2) I'm not sure about why PPC/KVM conflicts keep on happening. KVM on PPC seems to be more tightly integrated with non-KVM code than other architectures. _But it's also the other way round_ which seems less healthy to me. I'm not sure if that is really necessary, but if not, please refactor things so that we don't step on each other's toes unnecessarily. Perhaps real mode handlers should be in arch/powerpc/kernel/ and only arch/powerpc/kvm/, so that the latter only cares about virtualization? Maybe the whole napping and CPU thread management should be done outside arch/powerpc/kvm/? Not sure if that makes any sense, but to my eyes there are definitely too many KVM parts in hardware enablement patches (and BTW it's just crazy that PPC has about 4k lines of assembly). Maybe PPC *is* the special snowflake where interaction should be primarily with arch maintainers rather than myself. Then let's just have topic branches for the occasional API patch (new KVM_CAP_* constants would be the gist of it) and otherwise let Michael merge KVM/PPC patches. But in any case, to my eyes there _is_ a pattern, and a problem. It doesn't matter that the canary is a cherry-pick conflict that Linus could solve blinded and with one hand tied behind his back. Paolo > 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
