On Nov 9, 2015, at 11:46 AM, Jeff Law <l...@redhat.com> wrote: On 11/09/2015 12:38 PM, Bernd Schmidt wrote: >> We might want to think about making a policy decision to try waiving >> some of the testing requirements for target macro -> hook conversions. >> Maybe try only a "build to cc1" requirement and see whether that causes >> too much breakage. > A config-list.mk build is a build to cc1*, f951, gnat1, so we're not > requiring deep tests on the affected targets. Not sure how much we're > getting by forcing a bootstrap & regression test of that kind of change. > > I'm certainly open to this kind of relaxed testing to help this stuff move > forward an complete before we're all retired :-)
Testing is a cornerstone of gcc quality. I like it. It is useful. That said, I don’t think we should always be fanatical about it. How and when we accept less that a standard bootstrap and regression test run I’ve sure would be a big topic, but rather than make a ton of rules, I’d rather let small handful of reviewers decide when and how to accept less, and let them do what they want. We can give them negative feedback if it impacts too many people, too often and they can adjust. The other way, would be to have an integration branch that is tested and merged post testing on a regular basis and let people contribute less than well tested things on it, the idea being that it still won’t hit trunk until after a bootstrap and tests suite run, but that we can bundle 2-100 patches into one test suite run. This strikes me as more scalable, easier for developers and removes the requirement of test suite + bootstrap before checkin while retaining the useful quality of everything merged to trunk is tested. Hardest part about this would be ChangeLogs, merge resolution and svn blame. git handles this gracefully. svn as I recall, a little less so. [ quick check ] Ah, seems svn blame -g TARGET ca n handle this graceful (in theory).
