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 11:39:41 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	david@...g.hm
cc:	Takashi Iwai <tiwai@...e.de>,
	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, david@...g.hm wrote:
> 
> one thing that you have missed in your explination in this thread (although
> you have made the point in other threads) is that subsystem maintainers have
> the fear that there are other changes that will interfere with their stuff and
> want to catch it early.

Yes. 

However, that's not just a "my tree" issue. In fact, quite often other 
trees are more interesting from that angle: for driver subsystems like 
sound, the changes in Greg's driver core git tree may actually be oftne 
more relevant and give more of a heads-up than looking at my tree.

> per your instructions in prior threads, what they should do is to have a
> seperate branch on their system that they use as a throw-away branch to pull
> from your tree, and from their tree to spot problems. As they find problems
> they can then address them (cherry pick, or whatever)

Yes. Doing throw-away merges is a great way to test not just whether there 
might be actual merge conflicts, but also to just test that things work 
together.

And even if you want to concentrate your *development* on just 
ALSA-specific stuff, you may well want to also test all the changes that 
have gone upstream from other projects (and often do that _together_ with 
the changes you have developed yourself). And again, for this kind of 
testing, doing a throw-away merge to see how it all works together is 
fine.

> so it's not that the ALSA people should only look at your tree at the merge
> points, it's that they shouldn't pollute their tree that they are going to
> publish to you with this checking.

Yes. In general, it's a great idea to have "test trees" that aren't really 
for development, but for testing. That's obviously what 'linux-next' does, 
but it's something any tester can do (and it doesn't even have to imply 
any developer skills, although it would generally require at least some 
comfort with git).

That said, at least as far as I'm concerned, when I pull from some 
subsystem tree, the thing I really want to know is that the state of that 
tree is stable on its own. IOW, if the merge itself introduces some subtle 
bug, that is not only fairly unusual, but it's also something that should 
not be seen as a bug from the tree I pulled - it's just bad luck. 

So a submaintainer should care *most* about the fact that his/her tree is 
stable on its own. Problems that happen when multiple development trees 
are merged should be the secondary concern. I'd rather have people test 
their _own_ code really well, than spending lots of time trying to test 
every possible combination with other peoples trees.

			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/