On 5/30/2011 9:54 PM, Benjamin Shropshire wrote: > On 05/29/2011 04:19 PM, Brad Roberts wrote: >> On 5/29/2011 4:07 PM, Robert Clipsham wrote: >>> On 29 May 2011 19:13, Walter >>> Bright<[email protected]<mailto:[email protected]>> wrote: >>> >>> For those doing compiler patches, I know it's a tough job, and thanks! >>> >>> But please consider running the dmd test suite (and try to build/run >>> phobos unittests) before issuing a pull >>> request. There are a lot of interdependencies in the compiler, and the >>> test suite is designed to flush them out. >>> The >>> cool thing is the test suite consists of cases that are already >>> minimized! The suite also is designed to not take >>> that long to run. >>> >>> I run it constantly when I do dev on the compiler, and I constantly >>> get dinged by it for something I overlooked. I >>> consider the D test suite to be a major asset for us. >>> >>> Please use it. If you've got problems using it, please post here and >>> we'll try to help. >>> >>> >>> An idea relayed from Vladimir Panteleev: It could be a good idea to >>> integrate pull requests with the automatic test >>> runner - github has APIs for pull requests, the test runner could pull out >>> the commits, test them, then post a comment >>> on the pull request. >>> >>> I see a few problems with this however: >>> - Added load for the test runner (although, they could be run with low >>> priority and only when there aren't commits to >>> master to test) >>> - Security - if you're testing all pull requests some sort of sandbox >>> would be needed so the patch isn't running rm >>> -rf >>> or something more malicious >>> - More commits can be added to pull requests later on, it would need >>> re-running in this case >>> - The test suite could be altered to make it look like the pull request >>> is fine - although I guess anything that gets >>> integrated will be looked over anyway, so this isn't much of an issue. >>> >>> -- >>> Robert >>> http://octarineparrot.com/ >> All of that could be dealt with, probably, but it still doesn't fix the >> underlying issue: developers should be running >> the tests on the code they ask to be pulled themselves, BEFORE the pull >> request is filed. Not doing so puts potentially >> buggy code in the face of others to soon. >> >> Automated testing could help with finding conflicts between pull requests or >> something ahead of it being merged. But >> using it as a crutch to not test yourself isn't something I want to >> encourage. > > Why would it need to get even as a far as a pull request? Couldn't the > auto-tester be set-up to test anything that can > be pulled? If nothing else, it would allow people to test on *all* platforms > before they file the request.
Yes, it could. But, if you'll allow me.. I'm not building or hosting it. :) And it still doesn't encourage the behavior I think should be encouraged.. the developer of the change should be testing the changes. I honestly don't get the apparent resistance to doing so that's being expressed here. _______________________________________________ dmd-internals mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/dmd-internals
