* Richard Smith smithbone@gmail.com [061027 19:49]:
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.
opening this up for any number of build runs for any number of users will render a single machine pretty slow, too.
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.
the 2*1800MHz Opteron does it in 35 minutes, if its the only job running. And that's only if you don't rebuild the documentation. Imagine you and Yinghai and Ron working at the same time. This will render the compile time slower than what your laptop is capable of doing at the moment.
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.
This could be done with a pass-through repository as well. You check into a devel tree. the devel tree is running an abuild. If it succeeds, it goes to the stable tree, where hw tests are run. if it works there, it continues to a "working" tree.
the reason I am talking about trees all the time is that exactly the move stuff we've been doing recently requires a patch format that reflects those changes. A check in to a tree is such a diff. We could also do a branch for each compile run.
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.
one thing, which would also allow a really quick checking on your own machine (or therefore centrally on linuxbios.org as well) is to drop romcc. This will get build times per board from several minutes back to several seconds.
Which in fact would maybe even allow to compile the tree on checkin and reject the checkin if something breaks.
This could even be done intelligently. If you check something in to the flashrom utility, no board needs to be rebuilt. If you check something in to the k8 part, epias dont have to be rebuilt either. and we're at about 2 minutes per complete compile run.
Then at least you know its passed abuild before you commit.