From: Russell King <rmk@arm.linux.org.uk>
To: Takashi Iwai <tiwai@suse.de>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>,
linux-next@vger.kernel.org, Ben Dooks <ben@simtec.co.uk>,
Mark Brown <broonie@opensource.wolfsonmicro.com>,
Alexander Schulz <alex@shark-linux.de>
Subject: Re: linux-next: manual merge of the sound tree with the arm tree
Date: Wed, 11 Mar 2009 10:40:49 +0000 [thread overview]
Message-ID: <20090311104049.GA14668@flint.arm.linux.org.uk> (raw)
In-Reply-To: <s5hzlfsgywo.wl%tiwai@suse.de>
On Wed, Mar 11, 2009 at 11:02:47AM +0100, Takashi Iwai wrote:
> At Wed, 11 Mar 2009 09:41:27 +0000, Russell King wrote:
> > Why do I want to pull stuff that I consider broken into my tree? Please
> > get rid of the use of __typesafe_io in the shark io.h header in your tree
> > or drop these patches entirely and ask the submitter to fix (whatever's
> > easier for you.)
>
> It's not too big issue to revert the changes, but it'd be better to
> fix the spot as Mark suggested. The continuous GIT tree history makes
> the life of others easier a lot.
Continuous git tree history is something that can be achieved if you're
either at the top of the submission tree, or if you're extremely good
at reviewing patches and throwing out anything which might be the
slightest bit controversial until such things have been agreed.
The issue here is that an inappropriate tree has accepted unreviewed
and questionable ARM specific changes as part of a different set of
patches. That's partly the fault of the submitter for mixing up the
patch set with irrelevant changes for the tree to which he's submitting
his changes.
There used to be a mantra with the kernel community: one patch to make
one logical change. That's very much the issue here - it sounds like
there was one patch making several changes, some of which were relevent
to the ALSA tree and others which weren't.
But, at the end of the day, these things have to be fixed one way or
other, whether that be by removing the offending commits, by reverting
the patches, or patching the specific bad changes back to how they
originally were. I really don't mind which option is taken, just so
long as the final outcome is the right one.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
next prev parent reply other threads:[~2009-03-11 10:41 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-10 3:45 linux-next: manual merge of the sound tree with the arm tree Stephen Rothwell
2009-03-10 20:04 ` Mark Brown
2009-03-11 0:41 ` Stephen Rothwell
2009-03-11 6:58 ` Takashi Iwai
2009-03-11 8:52 ` Russell King
2009-03-11 9:18 ` Takashi Iwai
2009-03-11 9:41 ` Russell King
2009-03-11 10:02 ` Takashi Iwai
2009-03-11 10:40 ` Russell King [this message]
2009-03-11 11:24 ` Mark Brown
2009-03-11 13:28 ` Takashi Iwai
2009-03-11 22:32 ` Mark Brown
2009-03-12 2:48 ` Stephen Rothwell
2009-03-11 9:49 ` Mark Brown
-- strict thread matches above, loose matches on Subject: below --
2010-07-19 1:00 Stephen Rothwell
2010-07-20 9:03 ` Mark Brown
2010-07-20 20:54 ` Ryan Mallon
2010-07-22 1:28 Stephen Rothwell
2010-07-22 6:18 ` Takashi Iwai
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=20090311104049.GA14668@flint.arm.linux.org.uk \
--to=rmk@arm.linux.org.uk \
--cc=alex@shark-linux.de \
--cc=ben@simtec.co.uk \
--cc=broonie@opensource.wolfsonmicro.com \
--cc=linux-next@vger.kernel.org \
--cc=sfr@canb.auug.org.au \
--cc=tiwai@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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;
as well as URLs for NNTP newsgroup(s).