Hello Andrew and all,
What can be done to reduce the huge number of build fixes required to

release an MM tree?
Perhaps it would be helpful if you identified specific individuals who

send you patches that break the build.  If necessary, we could keep a

running total.  The main thought is that maybe we need to identify who

regularly sends troublesome patches.  There are three metrics that

might be good to know:  1) Who sends patches that are regularly

broken, but sends patches rarely?  2) Who sends patches all the time,

and once in while causes trouble?  And 3) Who is causing the most

cumulative trouble?
Is there any possibility that we ought to refuse patches from people

who break the build too often?
Another area that might be helpful might be how the patches break

things.  Are there major groupings of errors that developers could be

educated about?
I am sorry you are having to work so hard to do your job, Andrew.
                Miles

-

Umm... Andrew's Vaio and my Latitude? :)
Seriously though - one big chunk of the problem is almost certainly that Andrew

and I run with .config's and hardware that differ drastically from what the

various maintainers test against, and the rest is that Andrew pulls git trees

that may or may not be ready for prime time.  Not sure if there's any practical

way to "fix" that without adding so much administrivia overhead to render the

whole -mm tree useless as a a preview/early-warning system....

On Tue, 18 Sep 2007 08:23:38 -0400
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' ;))
-