* Ingo Molnar <mingo@xxxxxxx> wrote: > [...] > > Having a patch applied to an old scheduler tree that is barely > out of -rc1 and then pushing it out into linux-next at -rc8, > without even checking how it integrates with upstream, barely > a few days before the merge window is just plain stupid. So, while I cannot know what Linus will think and do once he gets such a conflict (my guess is that he'd just fix it up silently - it's really trivial), I can tell you what the conflict told *me*: that the communication channels between the ARM tree and the scheduler tree are not in the best of shape. And that is what worried me enough to write a reply while recognizing that PeterZ acked the patch - not the triviality of the patch or the triviality of the conflict. And dammit, I have the right and the duty to be concerned about a conflict in the scheduler code if I see it for the first time, not just Linus. Conflicts aren't magically just for Linus to be interested and act upon, they can occasionally be informative at subsystem maintainer levels just as well - like here... What we should not do in terms of conflict avoidance are *excessive* cross-subsystem merges: for example you indiscriminately merging the totality of all pending scheduler changes into the ARM tree and thus forcing Linus's hand in terms of not being able to reject to pull the scheduler tree. But if I got it right, working together on a trivial, well-isolated callback patch to make life easier is not frowned upon by Linus at all ... Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
