[Python-Dev] My thinking about the development process
Terry Reedy
tjreedy at udel.edu
Sun Dec 7 00:18:47 CET 2014
On 12/6/2014 10:26 AM, Nick Coghlan wrote:
> On 7 December 2014 at 01:07, Donald Stufft <donald at stufft.io> wrote:
>> A likely solution is to use a pre-merge test runner for the systems that we
>> can isolate which will give a decent indication if the tests are going to
>> pass across the entire supported matrix or not and then continue to use the
>> current post-merge test runner to handle testing the esoteric systems that
>> we can’t work into the pre-merge testing.
>
> Yep, that's exactly the approach I had in mind for this problem.
Most patches are tested on just one (major) system before being
committed. The buildbots confirm that there is no oddball failure
elsewhere, and there is usually is not. Testing user submissions on one
system should usually be enough.
Committers should generally have an idea when wider testing is needed,
and indeed it should be nice to be able to get wider testing on occasion
*before* making a commit, without begging on the tracker.
What would be *REALLY* helpful for Idle development (and tkinter,
turtle, and turtle demo testing) would be if there were a
test.support.screenshot function that would take a screenshot and email
to the tracker or developer. There would also need to be at least one
(stable) *nix test machine that actually runs tkinter code, and the
ability to test on OSX with its different graphics options. Properly
testing Idle tkinter code that affects what users see is a real bottleneck.
--
Terry Jan Reedy
More information about the Python-Dev
mailing list