linux-kernel - Re: linux-next: manual merge of the tip tree with the arm tree

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 13 May 2011 09:37:38 +0100
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Stephen Rothwell <sfr@...b.auug.org.au>,
	Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>,
	Peter Zijlstra <peterz@...radead.org>,
	linux-next@...r.kernel.org, linux-kernel@...r.kernel.org,
	John Stultz <john.stultz@...aro.org>,
	Jacob Pan <jacob.jun.pan@...el.com>,
	Glauber Costa <glommer@...hat.com>,
	Dimitri Sivanich <sivanich@....com>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Jeremy Fitzhardinge <jeremy@...source.com>,
	Chris McDermott <lcm@...ibm.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
Subject: Re: linux-next: manual merge of the tip tree with the arm tree

On Fri, May 13, 2011 at 10:06:34AM +0200, Ingo Molnar wrote:
> 
> * Stephen Rothwell <sfr@...b.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@....linux.org.uk>
>  AuthorDate: Sun May 8 18:55:19 2011 +0100
>  Commit:     Russell King <rmk+kernel@....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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/