From: Russell King - ARM Linux <linux@arm•linux.org.uk>
To: Ingo Molnar <mingo@elte•hu>
Cc: Stephen Rothwell <sfr@canb•auug.org.au>,
Thomas Gleixner <tglx@linutronix•de>,
"H. Peter Anvin" <hpa@zytor•com>,
Peter Zijlstra <peterz@infradead•org>,
linux-next@vger•kernel.org, linux-kernel@vger•kernel.org,
John Stultz <john.stultz@linaro•org>,
Jacob Pan <jacob.jun.pan@intel•com>,
Glauber Costa <glommer@redhat•com>,
Dimitri Sivanich <sivanich@sgi•com>,
Rusty Russell <rusty@rustcorp•com.au>,
Jeremy Fitzhardinge <jeremy@xensource•com>,
Chris McDermott <lcm@us•ibm.com>,
Konrad Rzeszutek Wilk <konrad.wilk@oracle•com>
Subject: Re: linux-next: manual merge of the tip tree with the arm tree
Date: Fri, 13 May 2011 09:37:38 +0100 [thread overview]
Message-ID: <20110513083738.GA19733@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <20110513080634.GA13647@elte.hu>
On Fri, May 13, 2011 at 10:06:34AM +0200, Ingo Molnar wrote:
>
> * Stephen Rothwell <sfr@canb•auug.org.au> wrote:
>
> > Hi all,
> >
> > Today's linux-next merge of the tip tree got a conflict in
> > arch/x86/kernel/i8253.c between commit 3490f584b9ba ("clocksource: convert
> > x86 to generic i8253 clocksource") from the arm tree and commit b01cc1b0eae0
> > ("x86: Convert remaining x86 clocksources to clocksource_register_hz/khz")
> > from the tip tree.
> >
> > The former seems to supercede the latter, so I used the former.
>
> Russell, how the heck did this commit:
>
> commit 3490f584b9ba5a0b6f63832fbc9c5ec72506697b
> Author: Russell King <rmk+kernel@arm•linux.org.uk>
> AuthorDate: Sun May 8 18:55:19 2011 +0100
> Commit: Russell King <rmk+kernel@arm•linux.org.uk>
> CommitDate: Tue May 10 08:20:54 2011 +0100
>
> clocksource: convert x86 to generic i8253 clocksource
>
> which has such a clearly x86 diffstat:
>
> arch/x86/Kconfig | 1 +
> arch/x86/include/asm/i8253.h | 2 +
> arch/x86/kernel/i8253.c | 79 +-----------------------------------------
> 3 files changed, 4 insertions(+), 78 deletions(-)
>
> end up in the ARM tree without an ack from an x86 maintainer??
The "no response" means two things: either that people are busy, or people
don't care about the patch. There is a patch from David Martin modifying
linux/elf.h adding one line to it which has not had any response. Should
we assume the silence means that people are busy? If we did that, nothing
would ever happen.
> I see the commit has an ack from John but that feedback is not visible in the
> lkml thread of this patch nor did John really realize the conflict nor the
I have no idea why John's ack is not visible, especially as it was sent
to lkml _and_ explicitly copied to you.
> build breakage. The patch was still in the to-be-reviewed queue of our patches.
>
> Nor was it tested properly. The patch looks sane but your workflow sucks.
> Please revert it and use a proper Git workflow to change arch/x86/ details ...
I don't think so. I created a patch. I posted it to relevant people.
I got an ack. So I put it into linux-next for further testing rather
than having it sitting around here getting zero testing.
That's the _proper_ thing to do. linux-next found some problems, so
let's sort them out - great, that's what linux-next is there for. Let's
sort them out instead of assigning blame.
And hey, it found a problem, and the problem has now been fixed. Which
is great, and that should be visible to linux-next soon.
As for merge conflicts, they happen. They get sorted. It's no big deal.
Again, that's what linux-next is there to find and allow people to
_discuss_ how to resolve them. It's not about avoiding all conflicts
no matter what or blaming people when conflicts happen.
Lastly, I have absolutely no problem about pulling the x86 bits out of
this series if they cause a conflict or don't get an ack. I operate a
flexible approach to my git tree for stuff like this which allows stuff
to be dropped or updated as necessary.
next prev parent reply other threads:[~2011-05-13 8:38 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-13 3:14 linux-next: manual merge of the tip tree with the arm tree Stephen Rothwell
2011-05-13 8:06 ` Ingo Molnar
2011-05-13 8:37 ` Russell King - ARM Linux [this message]
2011-05-13 8:47 ` Thomas Gleixner
2011-05-13 9:26 ` Ingo Molnar
2011-05-13 10:04 ` Thomas Gleixner
2011-05-13 17:25 ` Russell King - ARM Linux
2011-05-16 7:21 ` Ingo Molnar
2011-05-13 21:36 ` Russell King - ARM Linux
2011-05-16 7:31 ` Ingo Molnar
2011-05-16 7:42 ` Russell King - ARM Linux
2011-05-16 9:17 ` Ingo Molnar
2011-05-16 9:19 ` Russell King - ARM Linux
2011-05-16 9:40 ` Ingo Molnar
2011-05-16 10:07 ` Russell King - ARM Linux
2011-05-16 11:06 ` Ingo Molnar
2011-05-16 11:37 ` Russell King - ARM Linux
2011-05-16 18:47 ` John Stultz
2011-05-17 11:56 ` Ingo Molnar
2011-05-17 18:28 ` Russell King - ARM Linux
-- strict thread matches above, loose matches on Subject: below --
2013-06-20 5:05 Stephen Rothwell
2020-05-29 5:29 Stephen Rothwell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110513083738.GA19733@n2100.arm.linux.org.uk \
--to=linux@arm$(echo .)linux.org.uk \
--cc=glommer@redhat$(echo .)com \
--cc=hpa@zytor$(echo .)com \
--cc=jacob.jun.pan@intel$(echo .)com \
--cc=jeremy@xensource$(echo .)com \
--cc=john.stultz@linaro$(echo .)org \
--cc=konrad.wilk@oracle$(echo .)com \
--cc=lcm@us$(echo .)ibm.com \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=linux-next@vger$(echo .)kernel.org \
--cc=mingo@elte$(echo .)hu \
--cc=peterz@infradead$(echo .)org \
--cc=rusty@rustcorp$(echo .)com.au \
--cc=sfr@canb$(echo .)auug.org.au \
--cc=sivanich@sgi$(echo .)com \
--cc=tglx@linutronix$(echo .)de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox