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
On Tue, Mar 13, 2012 at 12:56:40PM +0100, Ingo Molnar wrote:
>
> * Russell King <rmk@arm.linux.org.uk> wrote:
>
> > On Tue, Mar 13, 2012 at 11:19:00AM +0100, Ingo Molnar wrote:
> > >
> > > * Russell King <rmk@arm.linux.org.uk> 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
> ...

Why am _I_ responsible for which kernel version _Catalin_ used for _his_
patches when _he_ committed them?

You're insane. Totally.

--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:


\
 
 \ /
  Last update: 2012-03-13 13:03    [W:0.078 / U:23.032 seconds]
©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site