[Twisted-Python] Regression in Gtk2 support testing
Hello all, Since #4558 was merged, introducing "gi reactor" based on the new Python bindings for gobject, all testing of the Gtk2 reactor has been disabled, on all platforms. This is a two-part problem. The first part is the more damaging part, but fortunately also the more easily fixed part. #4558 made it impossible to import `twisted.internet.gtk2reactor` if `sys.modules` contains a "gi" key. This seems to overlook the fact that even a *failed* import of the `gi` module adds such a key to that dictionary. Since the test suite tries to test `gireactor`, there will always be such a key, so `gtk2reactor` can never be imported by the test suite. The result is that gtk2reactor is no longer tested by buildbot on any platform. The second part will show up once the first problem is fixed. Once the check correctly ignores `sys.modules["gi"] == None`, it will still be impossible to test both gireactor and gtk2reactor in our current buildbot configuration. One or the other will win, and the loser will be quietly skipped (apparently too quietly for most people to notice). Some new strategy is required so that we can test both of these reactors on all our supported platforms. I hope someone will resolve the first issue quickly, perhaps this weekend, so that we don't drift too far away from a working gtk2reactor. If it isn't fixed soon, I suggest reverting the merge until the problem can be fixed in the #4558 branch. Jean-Paul
On 02/18/2012 10:59 AM, exarkun@twistedmatrix.com wrote:
The reactors buildslave is a reasonable strategy: have multiple runs with different reactors as the main trial reactor. Especially since, even in the absence of this problem, we'd want to continue to have full runs under the different reactors because the reactor mixin tests don't cover everything yet.
On 03:14 am, itamar@itamarst.org wrote:
... with the caveat that *eventually* the mixin tests should cover everything, and then we will want to stop running trial with different -r arguments. And perhaps the further caveat that we won't test both of these reactors on Windows, because we've already overloaded our Windows slave capacity and we can't really add more trial steps with different -r arguments. Jean-Paul
On 02/20/2012 10:10 AM, exarkun@twistedmatrix.com wrote:
While this is true up to a point, developers would still need to rely on Buildbot runs because if you're on Linux you can't test IOCP or kqueue locally even if ReactorMixin style tests had full coverage. So requiring one extra "trial -r" in a buildslave won't make a difference to developers; they will not be able to rely on local runs for full test coverage no matter what.
On 03:46 pm, itamar@itamarst.org wrote:
Nor can you test them locally with "trial -r". So... non sequitor?
Right. It makes a difference to the BuildBot deployment, which may melt into slag under the weight of increased testing requirements. Or, more seriously, it actually does make a difference to developers, because it extends the length of the "test on BuildBot" phase of the development process from 40 minutes to 80 minutes, or makes it impossible to complete sometimes because the extra load has knocked slaves offline, etc. I feel we might be talking past each other, but I can't quite put my finger on how or why. I hope this email expresses my concerns more clearly. Jean-Paul
On 02/18/2012 10:59 AM, exarkun@twistedmatrix.com wrote:
The reactors buildslave is a reasonable strategy: have multiple runs with different reactors as the main trial reactor. Especially since, even in the absence of this problem, we'd want to continue to have full runs under the different reactors because the reactor mixin tests don't cover everything yet.
On 03:14 am, itamar@itamarst.org wrote:
... with the caveat that *eventually* the mixin tests should cover everything, and then we will want to stop running trial with different -r arguments. And perhaps the further caveat that we won't test both of these reactors on Windows, because we've already overloaded our Windows slave capacity and we can't really add more trial steps with different -r arguments. Jean-Paul
On 02/20/2012 10:10 AM, exarkun@twistedmatrix.com wrote:
While this is true up to a point, developers would still need to rely on Buildbot runs because if you're on Linux you can't test IOCP or kqueue locally even if ReactorMixin style tests had full coverage. So requiring one extra "trial -r" in a buildslave won't make a difference to developers; they will not be able to rely on local runs for full test coverage no matter what.
On 03:46 pm, itamar@itamarst.org wrote:
Nor can you test them locally with "trial -r". So... non sequitor?
Right. It makes a difference to the BuildBot deployment, which may melt into slag under the weight of increased testing requirements. Or, more seriously, it actually does make a difference to developers, because it extends the length of the "test on BuildBot" phase of the development process from 40 minutes to 80 minutes, or makes it impossible to complete sometimes because the extra load has knocked slaves offline, etc. I feel we might be talking past each other, but I can't quite put my finger on how or why. I hope this email expresses my concerns more clearly. Jean-Paul
participants (2)
-
exarkun＠twistedmatrix.com -
Itamar Turner-Trauring