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: <20101228164047.GA2417@opensource.wolfsonmicro.com>
Date:	Tue, 28 Dec 2010 16:40:47 +0000
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Russell King <rmk@....linux.org.uk>
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 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/