[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120524090957.GE5361@opensource.wolfsonmicro.com>
Date: Thu, 24 May 2012 10:09:58 +0100
From: Mark Brown <broonie@...nsource.wolfsonmicro.com>
To: David Rientjes <rientjes@...gle.com>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
Randy Dunlap <rdunlap@...otime.net>,
Stephen Rothwell <sfr@...b.auug.org.au>,
linux-next@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [patch -linus] regmap: REMAP_IRQ should select IRQ_DOMAIN itself
On Wed, May 23, 2012 at 09:53:21PM -0700, David Rientjes wrote:
> Well pardon me for actually having a cluster of machines at Google
> dedicated to upstream build/boot/regression testing that verified my patch
> was correct and didn't result in any kind of "fragility", or what you have
> convinced yourself is "fragility."
It working right now isn't the only thing I'm concerned about, though
like I said further up the thread it's possible this is all just me
having too long a memory.
> When you propose your own version, drop all cc's (and this isn't the first
> time you've done that), and then send the git pull request less than 30
Sorry about that, I hadn't realised you were particularly attached to
the issue. I do generally drop people doing global stuff with no
particular obvious interest in the specific topic on new patches since I
know I sometimes get a bit fed up of being CCed on random things I was
tangentially involved in at some point.
> minutes later, I don't really have the chance to review it. Lesson
> learned, I simply won't bother to fix your code in the future.
I guess since I've offended you so much already there's not much harm in
saying: it's always much better to send changes in a form that can be
directly applied with tools like git am. Appending a patch to the
bottom of a mail requires something like hand editing the commit after
it's been applied to extract the changelog. Not sure it actually made a
difference in this specific case but it can be the difference when
you're not sure about the approach taken, especially for small patches
where it's quick and simple to write and test the replacement.
--
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/
Powered by blists - more mailing lists