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 09:16:05 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Takashi Iwai <tiwai@...e.de>
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



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?

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.

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

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

Powered by Openwall GNU/*/Linux Powered by OpenVZ