Re: [GIT PULL/NEXT] sched/arch: Introduce thefinish_arch_post_lock_switch() scheduler callback

[Ingo Molnar]

* Russell King <rmk@xxxxxxxxxxxxxxxx> wrote:

> On Tue, Mar 13, 2012 at 11:19:00AM +0100, Ingo Molnar wrote:
> > 
> > * Russell King <rmk@xxxxxxxxxxxxxxxx> wrote:
> > 
> > > On Tue, Mar 13, 2012 at 10:26:49AM +0100, Ingo Molnar wrote:
> > > >
> > > > As I said it in my first mail, doing that is unnecessary - 
> > > > but if you insist on being difficult then Catalin, feel free 
> > > > to pull the patch from tip:sched/arch:
> > > 
> > > Nope, I'm not taking the tree anymore, [...]
> > 
> > So instead of saying "sure, lets avoid conflicts next time 
> > around" you are now *refusing* to take technically perfectly 
> > fine patches just because another maintainer asked you to use a 
> > different workflow for future patches? Wow ...
> 
> No, I'm pissed off at how you're treating me over this trivial issue,
> so I'm taking the easy way out and getting out of the way.  If you want
> to run your bit of the tree with idiotic rules about zero conflicts,
> and "git solutions" then that's your perogative.  Just don't expect
> other people to play with you.
> 
> The fact of the matter is that Peter Z. was fully aware of what was
> happening.  He was aware that he'd been asked for his ack for that
> patch (because I'd explicitly asked Peter for it, but not by email) -
> and he provided his ack for that patch to Catalin:
> 
> http://lists.arm.linux.org.uk/lurker/message/20120227.144813.5614e7f8.en.html
> 
> Catalin sent a pull request to me, copying Peter Z on the 27th Feb:
> 
> http://lists.arm.linux.org.uk/lurker/message/20120227.164502.6b58a37e.en.html
> 
> I pulled it into my tree for testing, and pushed it out in the last
> couple of days.
> 
> Moreover, these kinds of trivial conflicts are the type of things which
> Linus wants to see between trees.  It allows him to get a feel for what's
> going on, and makes Linus feel like he's more on top of things.  Linus
> said that he would like to see these trivial conflicts (he said so to me
> in an email dated 15th Jan 2011).
> 
> So please, stop your insistance on this zero conflict crap.

While I still think this is a storm in a teacup, I think you are 
subtly misunderstanding Linus's position about conflicts and you 
are seriously misrepresenting my request and my position as 
well:

The thing is, most conflicts are fine in general. So on one hand 
you are right, we *do* allow and quite often *keep* conflicts in 
place even within our own topic branches.

Those are *real* conflicts that Linus would arguably be 
interested in: two teams working on two things in parallel that 
somehow conflict at the code level content-wise or concept-wise 
- high level maintainers rightfully are curious about those 
kinds of conflicts because while often they are just fine, it 
might also be the canary of possible workflow problems or it 
might also be the canary of the code being shaped in some 
inefficient way.

On the other hand, this particular conflict you pushed to 
linux-next is *neither*, and this is what got my attention. This 
is a plain *STUPID* conflict.

Look into the fine conflict report Russell: it conflicts with 
*Linus's* tree, because it's based off some random 
barely-beyond-rc1 development window -rc3 base. Even at the 
commit date of Feb 27 we had a more stable base tree available - 
and especially when you pulled it, several weeks down the line, 
-rc3 was not a defensible base for the integrated result.

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.

While nothing of what you talked to PeterZ is visible in the 
public record, I'm quite sure had you asked him about what base 
kernel to use, he'd have suggested something much more stable 
...

Thanks,

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/