Re: [alsa-devel] HG -> GIT migration
From: Linus Torvalds
Date: Wed May 21 2008 - 14:40:10 EST
On Wed, 21 May 2008, david@xxxxxxx 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.
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
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
> 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.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/