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-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
