My mind turns to cattle prods.
I don't think much can be done about it, really.
See, what I do is to merge probably hundreds of patches into the -mm-only
part of the tree and then, after a few days, get down and compile-test it
all, then fix it, then runtime test it all, then fix that. Because it is
vastly more efficient to do all this work against hundreds of patches than
it is to do it against one patch at a time, no?
And guess what? All the other maintainers do the same thing: someone sends
you a patch, it looks good, so you commit it. After you've committed a
decent batch of patches, get in there and test it all.
Problem is, I often will get in there and do all that testing before the
subsystem-tree owner has done his testing.
The only way in which my problem can get fixed is if all the subsystem tree
maintainers were to do a full set of compile-testing and runtime testing
before committing each change (impossibly expensive) or if they were to run
two trees: a raw/untested one, and a separate cooked/tested tree. I then
pull the cooked/tested one. The latter approach has quite a lot of
overhead for everyone as well.
But really, it's not worth sweating over the build errors: they're almost
always trivial to fix, and they are of course immediately apparent.
So don't worry about the build errors - they're a trivial nuisance. It's
the runtime errors which are much, much more serious and are much more
expensive to fix and which affect our users much more seriously.
(otoh, quite a number of the build errors are really really silly ones,
where someone couldn't be assed cooking up a decent grep regexp or
didn't even compile-test the change with _any_ config. I could name
names, but it would look like `grep @ MAINTAINERS' ;))
-
