lkml.org 
[lkml]   [2012]   [Mar]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [GIT PULL/NEXT] sched/arch: Introduce the finish_arch_post_lock_switch() scheduler callback

* Ingo Molnar <mingo@elte.hu> 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


\
 
 \ /
  Last update: 2012-03-13 13:13    [from the cache]
©2003-2011 Jasper Spaans