linux-next: manual merge of the arm tree with Linus' tree

Hi Russell,

Today's linux-next merge of the arm tree got a conflict in
kernel/sched/core.c between commit 8c79a045fd59 ("sched/events: Revert
trace_sched_stat_sleeptime()") from Linus' tree and commit 1cf00341547a
("sched: Introduce the finish_arch_post_lock_switch() scheduler hook")
from the arm tree.

Just context changes. I fixed it up (see below) and can carry the fix as
necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au

diff --cc kernel/sched/core.c
index b342f57,ea13a09..0000000
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@@ -1932,6 -1932,8 +1932,7 @@@ static void finish_task_switch(struct r
local_irq_enable();
#endif /* __ARCH_WANT_INTERRUPTS_ON_CTXSW */
finish_lock_switch(rq, prev);
+ finish_arch_post_lock_switch();
- trace_sched_stat_sleeptime(current, rq->clock);

fire_sched_in_preempt_notifiers(current);
if (mm)

* Stephen Rothwell <sfr@canb.auug[email protected]> wrote:

> Hi Russell,
>
> Today's linux-next merge of the arm tree got a conflict in
> kernel/sched/core.c between commit 8c79a045fd59 ("sched/events: Revert
> trace_sched_stat_sleeptime()") from Linus' tree and commit 1cf00341547a
> ("sched: Introduce the finish_arch_post_lock_switch() scheduler hook")
> from the arm tree.
>
> Just context changes. I fixed it up (see below) and can carry the fix as
> necessary.

This commit seems simple enough and has PeterZ's ack, but if
there are more scheduler patches coming in this area then please
send it to the scheduler tree first: we can create a pullable,
stable topic branch for it which the ARM tree can then use.

That approach would also avoid conflicts as a side effect.

Thanks,

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

On Tue, Mar 13, 2012 at 07:16:22AM +0100, Ingo Molnar wrote:
>
> * Stephen Rothwell <[email protected]> wrote:
>
> > Hi Russell,
> >
> > Today's linux-next merge of the arm tree got a conflict in
> > kernel/sched/core.c between commit 8c79a045fd59 ("sched/events: Revert
> > trace_sched_stat_sleeptime()") from Linus' tree and commit 1cf00341547a
> > ("sched: Introduce the finish_arch_post_lock_switch() scheduler hook")
> > from the arm tree.
> >
> > Just context changes. I fixed it up (see below) and can carry the fix as
> > necessary.
>
> This commit seems simple enough and has PeterZ's ack, but if
> there are more scheduler patches coming in this area then please
> send it to the scheduler tree first: we can create a pullable,
> stable topic branch for it which the ARM tree can then use.
>
> That approach would also avoid conflicts as a side effect.

Please check your mailbox:

Date: Tue, 29 Nov 2011 12:22:27 +0000
From: Catalin Marinas <[email protected]>
To: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org
Cc: Ingo Molnar <[email protected]>, Peter Zijlstra <[email protected]>,
Russell King <[email protected]>
Subject: [RFC PATCH 1/6] sched: Introduce the finish_arch_post_lock_switch()
scheduler hook

Date: Mon, 19 Dec 2011 14:57:48 +0000
From: Catalin Marinas <[email protected]>
To: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org
Cc: Russell King <[email protected]>, Ingo Molnar <[email protected]>,
Peter Zijlstra <[email protected]>,
Catalin Marinas <[email protected]>,
Frank Rowand <[email protected]>
Subject: [RFC PATCH v2 1/6] sched: Introduce the finish_arch_post_lock_switch()
scheduler hook

Date: Fri, 20 Jan 2012 17:42:27 +0000
From: Catalin Marinas <[email protected]>
To: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Cc: Russell King <[email protected]>, Ingo Molnar <[email protected]>,
Peter Zijlstra <[email protected]>,
Will Deacon <[email protected]>,
Frank Rowand <[email protected]>
Subject: [PATCH v3 1/6] sched: Introduce the finish_arch_post_lock_switch()
scheduler hook

--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

* Russell King <[email protected]> wrote:

> On Tue, Mar 13, 2012 at 07:16:22AM +0100, Ingo Molnar wrote:
> >
> > * Stephen Rothwell <[email protected]> wrote:
> >
> > > Hi Russell,
> > >
> > > Today's linux-next merge of the arm tree got a conflict in
> > > kernel/sched/core.c between commit 8c79a045fd59 ("sched/events: Revert
> > > trace_sched_stat_sleeptime()") from Linus' tree and commit 1cf00341547a
> > > ("sched: Introduce the finish_arch_post_lock_switch() scheduler hook")
> > > from the arm tree.
> > >
> > > Just context changes. I fixed it up (see below) and can carry the fix as
> > > necessary.
> >
> > This commit seems simple enough and has PeterZ's ack, but if
> > there are more scheduler patches coming in this area then
> > please send it to the scheduler tree first: we can create a
> > pullable, stable topic branch for it which the ARM tree can
> > then use.
> >
> > That approach would also avoid conflicts as a side effect.
>
> Please check your mailbox:

I'm aware of that old thread, I'd just prefer to hear about your
plans patching the scheduler *before* you commit it to
linux-next ;-)

Please make sure none of these scheduler patches go to the ARM
tree without a proper Git space solution that involves the
scheduler folks.

Thanks,

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

On Tue, Mar 13, 2012 at 09:36:30AM +0100, Ingo Molnar wrote:
>
> * Russell King <[email protected]> wrote:
>
> > On Tue, Mar 13, 2012 at 07:16:22AM +0100, Ingo Molnar wrote:
> > >
> > > * Stephen Rothwell <[email protected]> wrote:
> > >
> > > > Hi Russell,
> > > >
> > > > Today's linux-next merge of the arm tree got a conflict in
> > > > kernel/sched/core.c between commit 8c79a045fd59 ("sched/events: Revert
> > > > trace_sched_stat_sleeptime()") from Linus' tree and commit 1cf00341547a
> > > > ("sched: Introduce the finish_arch_post_lock_switch() scheduler hook")
> > > > from the arm tree.
> > > >
> > > > Just context changes. I fixed it up (see below) and can carry the fix as
> > > > necessary.
> > >
> > > This commit seems simple enough and has PeterZ's ack, but if
> > > there are more scheduler patches coming in this area then
> > > please send it to the scheduler tree first: we can create a
> > > pullable, stable topic branch for it which the ARM tree can
> > > then use.
> > >
> > > That approach would also avoid conflicts as a side effect.
> >
> > Please check your mailbox:
>
> I'm aware of that old thread, I'd just prefer to hear about your
> plans patching the scheduler *before* you commit it to
> linux-next ;-)
>
> Please make sure none of these scheduler patches go to the ARM
> tree without a proper Git space solution that involves the
> scheduler folks.

Sorry, you're blaming the wrong person. I got the commit via a pull,
not via a patch.

If that's how you want to run your bit of the kernel, then please be more
responsive when you're sent patches and say how you want to handle things.
Don't ignore patches and then blame people when conflicts happen.

--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

* Russell King <[email protected]> wrote:

> Please check your mailbox:
>
> Date: Fri, 20 Jan 2012 17:42:27 +0000
> From: Catalin Marinas <[email protected]>
> To: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org
> Cc: Russell King <[email protected]>, Ingo Molnar <[email protected]>,
> Peter Zijlstra <[email protected]>,
> Will Deacon <[email protected]>,
> Frank Rowand <[email protected]>
> Subject: [PATCH v3 1/6] sched: Introduce the finish_arch_post_lock_switch()
> scheduler hook

Btw., are you losing emails? Because the reply from peterz to
those patches, a month ago, was pretty clear:

> > Russell, what's the status of these patches? I'd like to see
> > them land in 3.4 if possible. I'm fine either way, I'll
> >
> > probably ask Ingo to pull your tree so that I can stack some
> > other patches on top.

You never replied to PeterZ's request, you just ignored this
scheduler maintainer request and you just did it in some random
way that was most convenient to you many weeks after the thread
died down, ignoring everyone else's concerns - a pretty usual
pattern from you I have to say.

Had you followed PeterZ's request this conflict in linux-next
could have been avoided, amongst other things.

Given that the merge window is close I doubt there will be
other, more difficult to resolve conflicts, but this incident
again demonstrates your inability to communicate efficiently and
amicably, forcing me to highlight it in this trivial case
because it's a sadly reoccuring pattern.

Thanks,

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

* Russell King <[email protected]> wrote:

> Sorry, you're blaming the wrong person. I got the commit via
> a pull, not via a patch.

This is the most idiotic excuse I've ever read.

Dammit, don't pull code you don't maintain and which you have
not checked the background of, *especially* not if the
originating discussion very clearly asked *you* to do it in
another way.

We were modifying that very code in this development cycle, in
the scheduler tree - a fact highlighted by the conflict - which
you could have seen yourself, had you even attempted to
test-merge your tree to linux-next ...

Let me quote PeterZ again:

> > Russell, what's the status of these patches? I'd like to see
> > them land in 3.4 if possible. I'm fine either way, I'll
> >
> > probably ask Ingo to pull your tree so that I can stack some
> > other patches on top.

Russell, read and reply to your mail in a timely and reliable
fashion, that will avoid such mixups in the future.

> If that's how you want to run your bit of the kernel, then
> please be more responsive when you're sent patches and say how
> you want to handle things. Don't ignore patches and then blame
> people when conflicts happen.

Stop blaming others for your own mistakes, one of the the
scheduler maintainers replied to the patches a month ago, in an
absolutely constructive fashion:

http://lkml.org/lkml/2012/2/16/232

You never replied to PeterZ that I can see.

Again, fortunately it's not a big deal right now - both the
commit and the conflict is trivial - but your current attitute
towards applying patches and following discussions is rather sad
and could cause bigger problems in the future.

Thanks,

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

On Tue, Mar 13, 2012 at 09:48:03AM +0100, Ingo Molnar wrote:
>
> * Russell King <[email protected]> wrote:
>
> > Please check your mailbox:
> >
> > Date: Fri, 20 Jan 2012 17:42:27 +0000
> > From: Catalin Marinas <[email protected]>
> > To: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org
> > Cc: Russell King <[email protected]>, Ingo Molnar <[email protected]>,
> > Peter Zijlstra <[email protected]>,
> > Will Deacon <[email protected]>,
> > Frank Rowand <[email protected]>
> > Subject: [PATCH v3 1/6] sched: Introduce the finish_arch_post_lock_switch()
> > scheduler hook
>
> Btw., are you losing emails? Because the reply from peterz to
> those patches, a month ago, was pretty clear:
>
> > > Russell, what's the status of these patches? I'd like to see
> > > them land in 3.4 if possible. I'm fine either way, I'll
> > >
> > > probably ask Ingo to pull your tree so that I can stack some
> > > other patches on top.
>
> You never replied to PeterZ's request, you just ignored this
> scheduler maintainer request and you just did it in some random
> way that was most convenient to you many weeks after the thread
> died down, ignoring everyone else's concerns - a pretty usual
> pattern from you I have to say.

Sigh. You know, people communicate via other methods from time to time.
How the hell do you think PeterZ provided his ack for the patch?

Stop looking for people to blame. Instead, if you failed to communicate
about how you wanted to handle the patch, blame yourself instead.

--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Tue, Mar 13, 2012 at 09:56:28AM +0100, Ingo Molnar wrote:
>
> * Russell King <[email protected]> wrote:
>
> > Sorry, you're blaming the wrong person. I got the commit via
> > a pull, not via a patch.
>
> This is the most idiotic excuse I've ever read.

Sod this crap, I'm dropping Catalin's patches. Deal with the fucking thing
yourself. Catalin, sorry, put some people are just total idiots over
simple merge conflicts and blow things totally out of proportion.

--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

* Russell King <[email protected]> wrote:

> On Tue, Mar 13, 2012 at 09:48:03AM +0100, Ingo Molnar wrote:
> >
> > * Russell King <[email protected]> wrote:
> >
> > > Please check your mailbox:
> > >
> > > Date: Fri, 20 Jan 2012 17:42:27 +0000
> > > From: Catalin Marinas <[email protected]>
> > > To: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org
> > > Cc: Russell King <[email protected]>, Ingo Molnar <[email protected]>,
> > > Peter Zijlstra <[email protected]>,
> > > Will Deacon <[email protected]>,
> > > Frank Rowand <[email protected]>
> > > Subject: [PATCH v3 1/6] sched: Introduce the finish_arch_post_lock_switch()
> > > scheduler hook
> >
> > Btw., are you losing emails? Because the reply from peterz to
> > those patches, a month ago, was pretty clear:
> >
> > > > Russell, what's the status of these patches? I'd like to see
> > > > them land in 3.4 if possible. I'm fine either way, I'll
> > > >
> > > > probably ask Ingo to pull your tree so that I can stack some
> > > > other patches on top.
> >
> > You never replied to PeterZ's request, you just ignored this
> > scheduler maintainer request and you just did it in some
> > random way that was most convenient to you many weeks after
> > the thread died down, ignoring everyone else's concerns - a
> > pretty usual pattern from you I have to say.
>
> Sigh. You know, people communicate via other methods from
> time to time. How the hell do you think PeterZ provided his
> ack for the patch?

He provided it via email to lkml:

http://lkml.org/lkml/2012/2/27/210

But he asked *you* to do a proper Git space solution:

http://lkml.org/lkml/2012/2/16/232

You *never* replied to that request that I can see, you just
ignored it, why?

This discussion shows that you seem to have basic reading
comprehension problems.

Thanks,

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

From: Catalin Marinas <[email protected]>
To: Russell King - ARM Linux <[email protected]>
Cc: linux-arm-kernel@lists.infradead.org,
Peter Zijlstra <[email protected]>
Subject: [GIT PULL] ARM: Remove the __ARCH_WANT_INTERRUPTS_ON_CTXSW
definition
Delivery-date: Mon, 27 Feb 2012 16:45:17 +0000

Hi Russell,

Could you please pull the context switching patches for ARM, together
with a generic hook acked by PeterZ?

Thanks,

On Tue, Mar 13, 2012 at 10:06:12AM +0100, Ingo Molnar wrote:
>
> * Russell King <[email protected]> wrote:
>
> > On Tue, Mar 13, 2012 at 09:48:03AM +0100, Ingo Molnar wrote:
> > >
> > > * Russell King <[email protected]> wrote:
> > >
> > > > Please check your mailbox:
> > > >
> > > > Date: Fri, 20 Jan 2012 17:42:27 +0000
> > > > From: Catalin Marinas <[email protected]>
> > > > To: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org
> > > > Cc: Russell King <[email protected]>, Ingo Molnar <[email protected]>,
> > > > Peter Zijlstra <[email protected]>,
> > > > Will Deacon <[email protected]>,
> > > > Frank Rowand <[email protected]>
> > > > Subject: [PATCH v3 1/6] sched: Introduce the finish_arch_post_lock_switch()
> > > > scheduler hook
> > >
> > > Btw., are you losing emails? Because the reply from peterz to
> > > those patches, a month ago, was pretty clear:
> > >
> > > > > Russell, what's the status of these patches? I'd like to see
> > > > > them land in 3.4 if possible. I'm fine either way, I'll
> > > > >
> > > > > probably ask Ingo to pull your tree so that I can stack some
> > > > > other patches on top.
> > >
> > > You never replied to PeterZ's request, you just ignored this
> > > scheduler maintainer request and you just did it in some
> > > random way that was most convenient to you many weeks after
> > > the thread died down, ignoring everyone else's concerns - a
> > > pretty usual pattern from you I have to say.
> >
> > Sigh. You know, people communicate via other methods from
> > time to time. How the hell do you think PeterZ provided his
> > ack for the patch?
>
> He provided it via email to lkml:
>
> http://lkml.org/lkml/2012/2/27/210
>
> But he asked *you* to do a proper Git space solution:
>
> http://lkml.org/lkml/2012/2/16/232
>
> You *never* replied to that request that I can see, you just
> ignored it, why?

I talked to peterz by other means. He gave his ack after that message was
sent. He was fully aware of what was happening.

> This discussion shows that you seem to have basic reading
> comprehension problems.

And your a fucking idiot too. Go to hell Ingo and stop being an utter
prat.

--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Oh and one last thing. I'm never going to take any patch which touches
the scheduler ever again, no matter how trivial. If that means people
can't get their patches in, then that's not my loss - that's your loss.
Especially when they're removing a special case from the scheduler -
which I hasten to add was requested by PeterZ.

I really don't care what you have to say in reply, I'm no longer listening
to objectionable people like you who make a mountain out of a mole hill.

On Tue, Mar 13, 2012 at 10:06:12AM +0100, Ingo Molnar wrote:
>
> * Russell King <[email protected]> wrote:
>
> > On Tue, Mar 13, 2012 at 09:48:03AM +0100, Ingo Molnar wrote:
> > >
> > > * Russell King <[email protected]> wrote:
> > >
> > > > Please check your mailbox:
> > > >
> > > > Date: Fri, 20 Jan 2012 17:42:27 +0000
> > > > From: Catalin Marinas <[email protected]>
> > > > To: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org
> > > > Cc: Russell King <[email protected]>, Ingo Molnar <[email protected]>,
> > > > Peter Zijlstra <[email protected]>,
> > > > Will Deacon <[email protected]>,
> > > > Frank Rowand <[email protected]>
> > > > Subject: [PATCH v3 1/6] sched: Introduce the finish_arch_post_lock_switch()
> > > > scheduler hook
> > >
> > > Btw., are you losing emails? Because the reply from peterz to
> > > those patches, a month ago, was pretty clear:
> > >
> > > > > Russell, what's the status of these patches? I'd like to see
> > > > > them land in 3.4 if possible. I'm fine either way, I'll
> > > > >
> > > > > probably ask Ingo to pull your tree so that I can stack some
> > > > > other patches on top.
> > >
> > > You never replied to PeterZ's request, you just ignored this
> > > scheduler maintainer request and you just did it in some
> > > random way that was most convenient to you many weeks after
> > > the thread died down, ignoring everyone else's concerns - a
> > > pretty usual pattern from you I have to say.
> >
> > Sigh. You know, people communicate via other methods from
> > time to time. How the hell do you think PeterZ provided his
> > ack for the patch?
>
> He provided it via email to lkml:
>
> http://lkml.org/lkml/2012/2/27/210
>
> But he asked *you* to do a proper Git space solution:
>
> http://lkml.org/lkml/2012/2/16/232
>
> You *never* replied to that request that I can see, you just
> ignored it, why?
>
> This discussion shows that you seem to have basic reading
> comprehension problems.
>
> Thanks,
>
> Ingo

--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

* Russell King <[email protected]> wrote:

> On Tue, Mar 13, 2012 at 09:56:28AM +0100, Ingo Molnar wrote:
> >
> > * Russell King <[email protected]> wrote:
> >
> > > Sorry, you're blaming the wrong person. I got the commit via
> > > a pull, not via a patch.
> >
> > This is the most idiotic excuse I've ever read.
>
> Sod this crap, I'm dropping Catalin's patches. [...]

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:

git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git sched/arch

HEAD: 01f23e1630 sched/arch: Introduce the finish_arch_post_lock_switch() scheduler callback

it's v3.3-rc7 based so it will generate no conflict with
linux-next. It only contains this commit so you can use it
without pulling in other pending scheduler changes.

This is the trivial and easy Git based topic branch approach
PeterZ asked Russell a month ago to consider:

http://lkml.org/lkml/2012/2/16/232

which request Russell sadly ignored.

In any case, Catalin's ARM work is not blocked in any fashion.

Thanks,

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

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, you've refused to behave in a
reasonable way. Your problem to sort out now.

--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

* Russell King <[email protected]> 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 ...

Regardless of the imperfect workflow I certainly find Catalin's
work useful technically, so I'll send his preparatory commit to
Linus in this merge window - I hope you will see sense later and
won't block his subsequent ARM patches...

> [...] you've refused to behave in a reasonable way. Your
> problem to sort out now.

For the record, that's utter nonsense:

- *You* failed to reply on the public thread to sort this out
properly in the Git space, avoiding conflicts naturally:

http://lkml.org/lkml/2012/2/16/232

While generally we don't mind conflicts, I do mind
*avoidable* conflicts - and this was such a case.

- *You* created a conflict by taking a tree that patched some
rather old version of the scheduler, shortly before the merge
window, when maintainer capacity is the shortest. PeterZ
is a nice guy who will agree to just about any approach, but
I'm quite sure he did not tell you to do *that* ;-)

- *You* replied to me in a rather dismissive and increasingly
obnoxious style when I inquired about it constructively:

http://lkml.org/lkml/2012/3/13/79

There were several easy solutions - I cannot believe that we are
still arguing this:

- it literally took me two minutes to create a proper Git
solution, it's not rocket science. You could have done it, or
I could have done it for you (as I have done it).

- Or you could have replied to the public thread, explaining
why that is not desirable.

- Or you could have said "sure thing, lets do it that way next
time around".

Thanks,

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

Hi Ingo,

On Tue, Mar 13, 2012 at 09:26:49AM +0000, 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:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git sched/arch
>
> HEAD: 01f23e1630 sched/arch: Introduce the finish_arch_post_lock_switch() scheduler callback
>
> it's v3.3-rc7 based so it will generate no conflict with
> linux-next. It only contains this commit so you can use it
> without pulling in other pending scheduler changes.

Thanks for merging the scheduler hook.

So I'll send Russell another pull request after the 3.4-rc1, containing
only ARM patches. The only drawback is that the removal of
__ARCH_WANT_INTERRUPTS_ON_CTXSW will have to wait another release cycle.

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

On Tue, Mar 13, 2012 at 11:19:00AM +0100, Ingo Molnar wrote:
>
> * Russell King <[email protected]> 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.

--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

* Russell King <[email protected]> wrote:

> On Tue, Mar 13, 2012 at 11:19:00AM +0100, Ingo Molnar wrote:
> >
> > * Russell King <[email protected]> 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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Tue, Mar 13, 2012 at 12:56:40PM +0100, Ingo Molnar wrote:
>
> * Russell King <[email protected]> wrote:
>
> > On Tue, Mar 13, 2012 at 11:19:00AM +0100, Ingo Molnar wrote:
> > >
> > > * Russell King <[email protected]> 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:
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

* Ingo Molnar <[email protected]> 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-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Tue, Mar 13, 2012 at 12:56:40PM +0100, Ingo Molnar wrote:
> 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.

I'm not going to ask someone to rebase their patches after they've been
fully tested on a set of platforms. It has been stated many times that
rebasing invalidates the testing that the patches have been subjected
to, and these have been tested by several different people on a range
of platforms.

It seems what _you_ care more about is having nice clean git trees and
proper git flow at the detriment to dealing with tested changes.

The fact of the matter is that I took a set of well tested patches into
my tree which _you_ were copied on multiple times, that Peter Z. was
aware of what was happening, and which trivially conflict with some other
change which happened along the way. Such a trivial conflict does _NOT_
justify rebasing the patch set, thereby invalidating all the testing that
has done.

--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

* Russell King <[email protected]> wrote:

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

If you then pull that tree from him and push it out to
linux-next? Then *of course* you are responsible, it was your
decision to pull it.

I frequently reject pulls from subsystem maintainers on similar
(and sometimes lesser) grounds - because such mistakes tend to
compound with time.

The thing is, if you do Git pulls from someone then you must be
absolutely anal about it, because you cannot really fix things
up after the fact. The people you pull from must be your
extended arms, they must be doing an equal or better job than
you. That gives a basis of trust.

Once that is established, you can be permissive about mistakes.

But arguing that you are not responsible for what you pull is
absolutely grotesque and establishes a new low for this
discussion really...

Also, as I told you in the very first mail, I am *fine* with
this having happened, so you having zapped the commits is
indefensible IMO. Mistakes do happen and the patch is fine
technically and sfr and Linus could have handled the trivial
conflict. What I suggested was to do it a bit better in the
future. Is that too much to ask for?

> You're insane. Totally.

I think you owe me an apology :-(

Thanks,

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

On Tue, Mar 13, 2012 at 01:20:53PM +0100, Ingo Molnar wrote:
>
> * Russell King <[email protected]> wrote:
>
> > Why am _I_ responsible for which kernel version _Catalin_ used
> > for _his_ patches when _he_ committed them?
>
> If you then pull that tree from him and push it out to
> linux-next? Then *of course* you are responsible, it was your
> decision to pull it.
>
> I frequently reject pulls from subsystem maintainers on similar
> (and sometimes lesser) grounds - because such mistakes tend to
> compound with time.
>
> The thing is, if you do Git pulls from someone then you must be
> absolutely anal about it, because you cannot really fix things
> up after the fact. The people you pull from must be your
> extended arms, they must be doing an equal or better job than
> you. That gives a basis of trust.
>
> Once that is established, you can be permissive about mistakes.
>
> But arguing that you are not responsible for what you pull is
> absolutely grotesque and establishes a new low for this
> discussion really...
>
> Also, as I told you in the very first mail, I am *fine* with
> this having happened, so you having zapped the commits is
> indefensible IMO. Mistakes do happen and the patch is fine
> technically and sfr and Linus could have handled the trivial
> conflict. What I suggested was to do it a bit better in the
> future. Is that too much to ask for?
>
> > You're insane. Totally.
>
> I think you owe me an apology :-(

I owe you nothing. From where I stand, I did nothing wrong.

--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

* Russell King <[email protected]> wrote:

> On Tue, Mar 13, 2012 at 12:56:40PM +0100, Ingo Molnar wrote:
> > 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.
>
> I'm not going to ask someone to rebase their patches after
> they've been fully tested on a set of platforms. [...]

That's a new argument which might be a valid concern in general
*if you make that decision when you pull the tree* - but you
should admit that you werent even aware of the conflict and of
the root cause behind it, let alone be in the position to
consider whether a rebase is justified in that case ...

( Paradoxially, rebasing is exactly what *you* ended up forcing
others to do. I have not asked you or Catalin to rebase any
existing commit. I merely asked about future plans. )

So I think you are just making this up on the fly. Really, if I
push back on you in a 100% *permissive* fashion, and if my
complaint is justified, then the proper response is for you to
push back on your contributors - while we can keep all commits
in place.

Instead you first pushed back on *me*, then you claimed that you
are not responsible for what you pull, then you started zapping
patches and claiming that you will never pull them again,
blaming it all on me.

Again, a storm in a teacup IMO.

Thanks,

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

* Russell King <[email protected]> wrote:

> On Tue, Mar 13, 2012 at 01:20:53PM +0100, Ingo Molnar wrote:
> >
> > * Russell King <[email protected]> wrote:
> >
> > > Why am _I_ responsible for which kernel version _Catalin_ used
> > > for _his_ patches when _he_ committed them?
> >
> > If you then pull that tree from him and push it out to
> > linux-next? Then *of course* you are responsible, it was your
> > decision to pull it.
> >
> > I frequently reject pulls from subsystem maintainers on similar
> > (and sometimes lesser) grounds - because such mistakes tend to
> > compound with time.
> >
> > The thing is, if you do Git pulls from someone then you must be
> > absolutely anal about it, because you cannot really fix things
> > up after the fact. The people you pull from must be your
> > extended arms, they must be doing an equal or better job than
> > you. That gives a basis of trust.
> >
> > Once that is established, you can be permissive about mistakes.
> >
> > But arguing that you are not responsible for what you pull is
> > absolutely grotesque and establishes a new low for this
> > discussion really...
> >
> > Also, as I told you in the very first mail, I am *fine* with
> > this having happened, so you having zapped the commits is
> > indefensible IMO. Mistakes do happen and the patch is fine
> > technically and sfr and Linus could have handled the trivial
> > conflict. What I suggested was to do it a bit better in the
> > future. Is that too much to ask for?
> >
> > > You're insane. Totally.
> >
> > I think you owe me an apology :-(
>
> I owe you nothing. From where I stand, I did nothing wrong.

Well, even ignoring the arguments you hurled several ad hominems
at me while I wrote none.

Thanks,

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

On Tue, Mar 13, 2012 at 01:44:33PM +0100, Ingo Molnar wrote:
>
> * Russell King <[email protected]> wrote:
>
> > On Tue, Mar 13, 2012 at 12:56:40PM +0100, Ingo Molnar wrote:
> > > 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.
> >
> > I'm not going to ask someone to rebase their patches after
> > they've been fully tested on a set of platforms. [...]
>
> That's a new argument which might be a valid concern in general
> *if you make that decision when you pull the tree* - but you
> should admit that you werent even aware of the conflict and of
> the root cause behind it, let alone be in the position to
> consider whether a rebase is justified in that case ...

No Ingo. I was aware of the conflict, because when I merged it into
my test tree, I got that conflict and fixed it up myself before I
tested the frigging thing.

> So I think you are just making this up on the fly.

If you think that, we have nothing further to discuss. But I know
I'm right, because:

commit e3507976ee7ad0a58fa68ce919a7acfcfec28e3b
Merge: 4c17fe7 8cee1aa
Author: Russell King <[email protected]>
Date: Thu Mar 8 09:51:31 2012 +0000

Merge branch 'intr-ctxsw' of git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/linux

Conflicts:
kernel/sched/core.c

http://ftp.arm.linux.org.uk/git/?p=linux-next.git;a=commitdiff;h=e350797
(which is _not_ in a public branch, and is _only_ accessible via knowing
the commit id.)

Oh look, March 8th. Oh, that's last Thursday. Oh, maybe I did merge
it a while back after all, maybe I'm not making this crap up. Maybe
I did know about the conflict but didn't think anything of it because
it was soo trivial.

> Instead you first pushed back on *me*, then you claimed that you
> are not responsible for what you pull, then you started zapping

No I did not. What I said was that I'm not responsible for the points
at which people choose to base their patches, which is something entirely
different. Unlike you, I have _no_ _problem_ with pulling work based on
_any_ -rc, or indeed any commit whatsoever - provided it's been tested
and it merges relatively cleanly with the branch I'm pulling it into.

> patches and claiming that you will never pull them again,
> blaming it all on me.

I'm only blaming this thread on you, precisely because you're making a
mountain out of a mole hill. There's no problem here. Really. At all.
You're just blowing it out of all proportion making it into some huge big
issue. _That_ alone is the whole reason why I've dropped Catalins patches.
I don't want to be subjected to your rants over this. Instead, _you_ can
deal with this patch set and deal with the other conflicts which git can
resolve automatically.

--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

* Russell King <[email protected]> wrote:

> > Instead you first pushed back on *me*, then you claimed that
> > you are not responsible for what you pull, then you started
> > zapping
>
> No I did not. What I said was that I'm not responsible for
> the points at which people choose to base their patches, which
> is something entirely different. [...]

What are you talking about?

Firstly, in general *every single bit* of what you pull,
including the base, the patch titles, the commit logs, the
signoff chain, etc. is all part of the picture and you
absolutely should require your contributors and submaintainers
to do a fine job with all that.

No ifs and whens about that - it all becomes your responsibility
as well when you decide to pull from people.

Instead you are now teaching them the exact *opposite*: for
example you have just declared that you don't feel responsible
for the base kernel ...

Using a sane base is IMHO part of Git pull 101. Teaching
contributors or submaintainers to not use too old base kernels
(or too new ones, for example during the merge window) is an
important part of the picture.

A basic rule for bases is to either use the previous stable
kernel release, of if that's not possible then use the freshest
-rc available at the time of the commit - which by my quick look
should have been about -rc6, not -rc3.

Secondly, my other problem was that this all surfaced today, at
-rc8 time, shortly before the merge window, a very busy period
of time.

If this was committed a month ago, if you indeed saw the
conflict earlier proves *more* workflow breakage IMO: you pushed
it upstream despite being aware of it being the result of a
slightly suboptimal base, without asking whether the scheduler
folks are still fine with all that?

Thirdly, all this totally ignores the issue you still have not
answered: why did you leave PeterZ public lkml question about
this unanswered:

http://lkml.org/lkml/2012/2/16/232

PeterZ's request to put this into a separate branch was totally
reasonable IMHO - and could have avoided this long thread,
amongst other things. Instead you've mixed it with other bits.

Really, my quick impression is that you should learn to push
back downstream a bit, especially as I didn't even ask for a
rebase, a revert or anything other drastic.

Thanks,

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

Anyway - regardless of any differences and flames about workflow
details, both you and Catalin should still feel free to use both
the original commit (1cf00341547a) or the tip:sched/arch branch
I provided (01f23e1630d9).

[ At the end of the merge window I'll try to make sure that at
least one of them got upstream ;-) ]

Thanks,

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

Hi Ingo,

On Tue, Mar 13, 2012 at 03:47:16PM +0000, Ingo Molnar wrote:
> Anyway - regardless of any differences and flames about workflow
> details, both you and Catalin should still feel free to use both
> the original commit (1cf00341547a) or the tip:sched/arch branch
> I provided (01f23e1630d9).

About the scheduler hook patch, would it go into mainline via the
sched/urgent or the sched/arch branch? I would like to rebase the
ARM-specific patches on top of one of these branches and send you a pull
request (with Russell's ack).

Alternatively, I can wait until some 3.4-rc (and merge the ARM patches
via Russell).

Thanks.

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

* Catalin Marinas <[email protected]> wrote:

> Hi Ingo,
>
> On Tue, Mar 13, 2012 at 03:47:16PM +0000, Ingo Molnar wrote:
> > Anyway - regardless of any differences and flames about workflow
> > details, both you and Catalin should still feel free to use both
> > the original commit (1cf00341547a) or the tip:sched/arch branch
> > I provided (01f23e1630d9).
>
> About the scheduler hook patch, would it go into mainline via
> the sched/urgent or the sched/arch branch? I would like to
> rebase the ARM-specific patches on top of one of these
> branches and send you a pull request (with Russell's ack).

I've merged it into sched/urgent yesterday, which I'll send to
Linus - so you can base it on that.

Thanks,

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