On Tue, 23 Jan 2007 23:16:47 -0500 (EST), Andrew Pinski <[EMAIL PROTECTED]> said:
> Let me bring up another point: > 0) bugs go unnoticed for a couple of releases and then become part of > the release criteria. Yeah, that's a good point. So maybe there's another feedback loop to consider: long release cycle => large-scale external testing only happens rarely (because lots of it only happens only after the branch has been cut) => lots of bugs are found all at once => long stage 3 => long release cycle I think it would be interesting to think of ways to spread out the discovery of bugs. >> 3: Throttle the size of patches: don't let people do gigantic >> merges, no matter the size of the branch. > This is wrong as the gigantic merges are needed in some cases to be > able change the infrastuture of GCC. A good example is recently > (and soon) are mem-ssa, GIMPLE_MODIFY_STMT, and dataflow. All > really could not be done by simple little patches. Tree-ssa was > another example. All I can say is that I have a pretty good amount of experience making large changes incrementally, and I'm not the only person who does. But I don't know nearly enough about the changes you mention to be able to say anything specific. (I don't read gcc-patches, just gcc.) >> * No patches are allowed if there are more than X release-blocking >> bugs outstanding. (For some small value of X; 0 is one >> possibility.) > I don't think this will work out because you are punishing all > developers while one developer gets his/her act together. Two responses: * For better or for worse, you're all in this together. * If you have fast bug-detection mechanisms (e.g. a build farm that runs all your tests on all your targets every night, or even multiple times a day), you can quickly revert offending patches. But, as you mentioned above, one of the problems is that bugs are being discovered some time after they are being introduced. Personally, the way I would deal with that is to spend some time doing root cause analysis of the bugs, and try to figure out ways in which they could have been detected faster. In other words, don't just fix the bug: go back to the patch that introduced the bug, think about how you could have made it easier for the submitter to have written test coverage that would have detected the bug, think about how you could have made it easier for the reviewer to have detected the bug. >> For 4, you should probably spend some time figuring out why bugs are >> being introduced into the code in the first place. > Some cases is because test coverage is not good enough in general, C++. > Other cases, you just did not think about a corner case. Even in other > cases, you exposed a latent bug in another part of the code which did > not think about a corner case. Personally, I find unit tests very helpful at reminding me to focus on corner cases, enabling me to test corner cases relatively easy, and helping other people not inadvertently break my corner cases. David Carlton [EMAIL PROTECTED]
