linux-kernel - Re: linux-next: manual merge of the sound tree with the s5p tree

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20101228162330.GA31226@flint.arm.linux.org.uk>
Date:	Tue, 28 Dec 2010 16:23:30 +0000
From:	Russell King <rmk@....linux.org.uk>
To:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
Cc:	Kukjin Kim <kgene.kim@...sung.com>, '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

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