list? That could be the first step for getting it approved. That way you know its abuild clean before you review it.
Are you suggesting a development and a stable tree?
No.
Is this better than running abuild locally? (besides potential tool chain issues)
Because on my laptop (which I do a lot of work on) it takes over an hour to run abuild. I suspect a lot of people don't run abuild localy since it takes so long to run.
But you have abuild on a fast machine that I can send my patch to and in 5 minutes or so I get an aswer then (the developer) seems more apt to try and check it before you check in breakage. Also the reviewer could send the patch at the start of the review process and by the time he is done reviewing have an answer if its abuild clean or not.
You reviewed this patch and yet it still broke lots of the tree. So It seems the author did not run abuild prior to sending the patch.
I propose something similar to what buildrom does. Pull a copy, apply patchs, and build but just send the results back to the sender then discard the tree.
This also let you send up a cross-compile enviroment for testing the non-x86 boards.
Part of the patch submission requirement would then be to have it abuild tested. If the script succeeds then it could issue a Abuild-clean: <date> or something like that which the submitter would include in the patch.
Then at least you know its passed abuild before you commit.