Date:	Thu, 30 Dec 2010 09:54:13 +0900
From:	Kukjin Kim <kgene.kim@...sung.com>
To:	'Mark Brown' <broonie@...nsource.wolfsonmicro.com>,
	'Russell King' <rmk@....linux.org.uk>
Cc:	'Takashi Iwai' <tiwai@...e.de>,
	'Stephen Rothwell' <sfr@...b.auug.org.au>,
	linux-next@...r.kernel.org, linux-kernel@...r.kernel.org,
	'Jassi Brar' <jassi.brar@...sung.com>
Subject: RE: linux-next: manual merge of the sound tree with the s5p tree

Happy New year everyone :-)

Firstly, thanks for Russell and Mark.

Hmm...
I thought it's very simple, but it is not. Because needs some peoples'
another work :-(

Anyway, so I decided that will drop/change some commits which occur conflict
between sound tree and build error in my tree. Already discussed about that
with Jassi and he agreed.

Then if possible, will send remained small stuff to Linus during -rc.

Thank you so much again ;-)

Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@...sung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.

Mark Brown wrote:
> On Tue, Dec 28, 2010 at 04:23:30PM +0000, Russell King wrote:
> > On Tue, Dec 28, 2010 at 03:39:48PM +0000, Mark Brown wrote:
> 
> > > Please keep myself and Liam in the CC on all ASoC discussion.
> 
> > You weren't included on Stephen's email.  Have you told Stephen which
> > files he needs to notify you about?  I suspect Stephen operates by
> > notifying the people who's trees clash, rather than selecting people
> > based on files.
> 
> I suspect so too; the file patterns in MAINTAINERS cover it otherwise
> (and originally the ASoC tree was actually getting merged first so the
> right thing would've happened anyway).
> 
> > > > Of course, I know you need rebase you tree for it...so sorry for
> bothering.
> 
> > > This isn't going to help as it will just introduce the same duplicate
> > > commits issue into the sound tree.  I'm still not clear what the
> > > affected commits actually are but given that Stephen's original report
> > > indicated that the ASoC changes are subsets of your changes would it
not
> > > make sense to just drop the relevant commits from your tree (which
seems
> > > to be rebased often, unlike the sound tree which doesn't rebase)?
> 
> > I don't think you read what I said (you probably didn't even see it.)
> 
> > What Kukjin has already done is looked in the ALSA tree, extracted the
> > commits he wants from it, committed those into his tree, and based a
> > pile of work on top of that.
> 
> Right, but looking at Stephen's original mail it seems like the bits
> that are conflicting here are two different commits in the ASoC and
> Samsung code where the ASoC version is a superset of the Samsung side
> set.  If that analysis is correct then the ASoC commits will do the
> right thing once they turn up in the Samsung tree so unless there's a
> pressing reason for the Samsung versions they could just be dropped for
> the time being.
> 
> > I said "don't do that" because it creates unnecessary duplications in
> > the git history.  I suggested that if Kukjin needs commits from the ALSA
> > tree, he asks the ALSA people for a commit in their tree to pull into
> > his tree to base his code on instead.
> 
> Yes, which due to the lack of rebasing is hard to arrange except by
> merging all of ASoC en masse (which someone already suggested).
> 
> > > Another option is to do a second round of merges after both sound and
> > > ALSA trees with whatever the dependant commits are.
> 
> > If Kukjin has code which requires commits from the ALSA tree, and he
> > doesn't have the ALSA tree, he can't build-test the code in his tree.
> > Are you really suggesting that people should keep un-build-tested code
> > in their trees, and push that un-tested code upstream when the dependent
> > trees have merged?  Are you really suggesting that swathes of commits
> > should not be bisectable?
> 
> No, I'm suggesting that a separate branch be maintained with the
> affected commits which gets rebased and tested against -next or whatever
> until everything they need hits the tree they need to be merged via.
> The bulk of things go in as normal, then the extra commits are added in
> a second merge later.  This is often required for practical testing when
> there's a lot of work going on over the tree, even if it can be split up
> neatly for merge.
> 
> This is annoying if it goes on for a long time but given that Linus is
> likely to release this week that shouldn't be the case, and it assumes
> the set of affected changes is small.  As I've no idea why the Samsung
> side of the changes is there I don't know if that is the case or not.

--
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