On Wed, 21 May 2008, david@lang.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