linux-kernel - Re: linux-next: manual merge of the msm 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]

Message-ID: <20101019183448.GA11088@flint.arm.linux.org.uk>
Date:	Tue, 19 Oct 2010 19:34:48 +0100
From:	Russell King <rmk@....linux.org.uk>
To:	Daniel Walker <dwalker@...o99.com>
Cc:	Arnd Bergmann <arnd@...db.de>, Joe Perches <joe@...ches.com>,
	Nicolas Pitre <nico@...xnic.net>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	linux-next@...r.kernel.org, lkml <linux-kernel@...r.kernel.org>,
	Jeremy Kerr <jeremy.kerr@...onical.com>,
	Jeff Ohlstein <johlstei@...eaurora.org>
Subject: Re: linux-next: manual merge of the msm tree with the arm tree

On Tue, Oct 19, 2010 at 10:03:26AM -0700, Daniel Walker wrote:
> On Tue, 2010-10-19 at 15:18 +0200, Arnd Bergmann wrote:
> > On Tuesday 19 October 2010, Joe Perches wrote:
> > > This could have been done:
> > > 
> > > $ git show 08a610d9ef5394525b0328da0162d7b58c982cc4 | ./scripts/get_maintainer.pl --nogit | wc -l
> > > 35
> > > 
> > > Even then, using 35 CCs is generally silly.
> > > 
> > > It might make some sense for a cover letter and a
> > > patch series where the series made tree-wide changes
> > > in multiple directories.
> > 
> > Probably not even then: When a single mail header gets too long, you usually land
> > in some spam filter and get hate mail from the list owners. The lkml limit is 1024
> > characters (this may come from an official RFC, don't know), which is usually less
> > than 35 recipients.
> 
> Patches just shouldn't be this large.

Patches get large.  Sometimes they can't be sensibly broken up.  We
have to accept them as is sometimes.  This is one of those occasions.
See the example Nicolas gave you - it's no different.

As for you saying that I'm the one getting excited about this - I'm not.
I'm getting pissed off by how much discussion effort this trivial matter
is taking and how much time it's wasting, which really isn't necessary.
There's far better things to be done (such as testing) rather than taking
hours to sort out what is basically a trivial merge issue.

Now, you've said in your pull request:

| Here is your pull request Russell. This has the patch which was part of
| the conflict in MSM, "msm: allow uart to be conditionally disabled"..
| 
| It's on top of v2.6.36-rc5, and it has one patch that is already in your
| tree. It's "GIC: Dont disable INT in ack callback" .
| 
| This pull request is exactly what I would send to Linus is the merge
| window was open.

As I'm merging it into a tree which does _not_ have the changes from
Jeremy and Nicolas, what's this "the patch which was part of the
conflict" and what's it going to do without Nicolas' changes?

The point of dropping Jeremy and Nicolas' changes are to return to a
state where things were before the troublesome change, so that the
existing code works.  Then Nicolas was going to take what is in my
tree, and update the patches to take account of what's there.

If you're going to pre-empt that by fixing the stuff yourself, this
whole exercise has been pointless, because it means that the code in
your tree currently won't build without these other changes.

So at the moment I don't know whether or not I should pull your tree.

-- 
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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/