> Which less extreme approach would for sure have prevented this?
Clearly, if what I said leads inexorably to such extreme measures,
then what I said is full of crock.
And Andrew made a good point, that matches up well with your mention
of your "puny 1.8 GHz CPU." There is some efficiency to be gained
from doing crosstool builds against 100 changes at once, rather than
100 developers each doing them for their one change.
Personally, I recommend a half-way effort. Do crosstool builds
against a few arch's when doing more risky stuff; sometimes batch
up crosstool builds for several fixes at once (which may mean that
I actually send in the fix before the crosstool build succeeds);
send in some fixes for what you see broken if it looks "easy enough"
to you; post a description of some of the other breakages you don't
have time or expertise to track down; sometimes just say to heck with
it, and don't crosstool test, or ignore some of the breakage if it
doesn't look like your problem.
But I'm still relatively junior around here. Those with more battle
scars than I are worth paying more attention to than I am.
My basic rule of thumb, that I suspect scales rather well, is to
try to clean up more crap of others than I drop on them. If we all
kept a slightly positive balance in our crap cleanup versus dropping
statement, then life would be good.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <[email protected]> 1.925.600.0401
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]