On Wed, 21 May 2008, Linus Torvalds wrote:

quoted text
> [ 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
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/