On 10/26/05, Lu, Yinghai yinghai.lu@amd.com wrote:
I don't think two trees are needed, that will create more work.
I see that I sent my reply only to Stefan rather than the list. Oops. Gotta quit cranking out e-mails right before lunch *grin*
I mean every committer must not break the current code at least it can compile through before the commit can be made. Just need he to spend 5 more minutes to double check it.
Well the trick here is how to do this effectively across the board. Can any one developer be effective at dealing with all the chips supported and platforms supported? And how far can you run this before you swamp a developer? Its LB's goals to try and expand the number of chipsets we support right?
Consider that in the power-pc or ARM cross-compile setup the compiler may not even be installed on the developers system. Making it really hard to verify if you broke things.
And even if the code compiles that's still only the first step. Those are the _easy_ fixes. Its when you tickle a subtle hardware bug that things will get icky.
Things like autobuilders and code reviews are big helps but ultimately somebody has got to try and compile and run the code on the hardware and do some tests. The best person for that job is a developer working on that platform. And for that to happen the patches have to be available prior to commit. In absence of a different tree then perhaps there is an RFC period for patches? A lot like the kernel does. Post the patch(s) let people mess with it and then apply them when the developers for that platform are cool with the results.
-- Richard A. Smith