linux-kernel - Re: [alsa-devel] HG -> GIT migration

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]

Date:	Wed, 21 May 2008 18:51:39 +0200
From:	Takashi Iwai <tiwai@...e.de>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Rene Herman <rene.herman@...access.nl>,
	alsa-devel@...a-project.org,
	Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: [alsa-devel] HG -> GIT migration

At Wed, 21 May 2008 09:16:05 -0700 (PDT),
Linus Torvalds wrote:
> 
> 
> 
> On Wed, 21 May 2008, Takashi Iwai wrote:
> > 
> > But, this means that the fixes done outside the subsystem tree cannot
> > be in the subsystem tree itself until the next release.  It's a pretty
> > weird situation.
> 
> No it is NOT.
> 
> Why should you have stuff from outside the subsystem tree?

Well, what I meant is about the fixes to the subsystem (say, ALSA) by
people in the outside.  Not every ALSA-bugfix patch goes into the
upstream from ALSA tree.  You, Andrew and others pick individually
ALSA-fix patches.  They will be missing in the ALSA subsystem tree.

And, what if that you need a fix for the fix that isn't in ALSA
tree...?  IMO, either a rebase or a merge is better than
cherry-picks.

> And quite frankly, the only reason to *need* those fixes in the first 
> place is if you merge random test-kernels during the merge window. What 
> you should strive for is to merge at the stable point, not random kernels 
> to keep you "up-to-date", and suddenly you don't need to make more merges 
> just to get (possibly) new fixes.
> 
> See?
> 
> If it's the ALSA tree, then what is it doing pulling all the random other 
> stuff that I merge?
> 
> In other words - merging my random stuff, THAT is the "weird situation". 
> You should be doing ALSA development, not "random kernel" development.

Hmm, that makes me thinking of the development model.
We can leave ALSA tree without upstream fixes as is if user always
pull both ALSA and upstream trees.  This works for users that are
using the latest development kernel.

> > The method Linus suggested is suitable for random patches like tirival
> > tree, but apparently not for every case.
> 
> Umm. Bigger subsystems than ALSA are successfully using it and have no 
> problems, and don't think they need to merge backwards:
> 
> 	[torvalds@...dy linux]$ git rev-list v2.6.25.. drivers/net/ | wc -l
> 	739
> 	[torvalds@...dy linux]$ git rev-list v2.6.25.. sound/ | wc -l
> 	291
> 
> iow, the only reason you seem to think that you need to merge more is that 
> you merged too much, or from a too-unstable base, to begin with.
> 
> Aim for basing things on releases, or at least for merging just at stable 
> points (and only when you *need* to, and it will make your life much 
> easier. And the history will automatically be cleaner and less confusing.

Yes, I see the point.

But, my question is about the divergence between the development and
for-linus branches: how to apply patches that exist only in for-linus
tree back.


thanks,

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