On Wed, 21 May 2008, Linus Torvalds wrote:
[ The corrollary to this all is that when downstream does a merge, think about what the merge message can say. How would you descibe the merge?
Can you give a good description of what you merged, and why? That's one thing that merging with releases can give you: you can say "merge with release 'xyz'", and people actually understand the *meaning* of it. Your merge message makes sense - and that implies that the merge itself likely made sense.
If you cannot explain what and why you merged, you probably shouldn't be merging - that's a good rule of thumb right there! Maybe that rule in itself should already be seen as sufficient ]
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.
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)
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.
David Lang