lkml.org 
[lkml]   [2010]   [Dec]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: linux-next: manual merge of the sound tree with the s5p tree
On Tue, Dec 28, 2010 at 03:39:48PM +0000, Mark Brown wrote:
> On Tue, Dec 28, 2010 at 11:24:49AM +0900, Kukjin Kim wrote:
>
> > Takashi, as Russell's first option, could you please make some branch which
> > includes following to me?
>
> 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.

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

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.

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

--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:


\
 
 \ /
  Last update: 2010-12-28 17:27    [W:0.071 / U:0.324 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site