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
On Tue, 18 Sep 2007 08:23:38 -0400
"Miles Lane" <[email protected]> wrote:
> Hello Andrew and all,
>
> What can be done to reduce the huge number of build fixes required to
> release an MM tree?
My mind turns to cattle prods.
> 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.
>
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' ;))
On Tue, 18 Sep 2007 08:23:38 EDT, Miles Lane said:
> and once in while causes trouble? And 3) Who is causing the most
> cumulative trouble?
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....