On 4 August 2010 08:49, Tim Golden <mail at timgolden.me.uk> wrote: > I have watched the buildbot pages occasionally, especially when I see > Windows-related commits going in, but several times "red" buildbots > have turned out to be -- apparently -- environmental / local issues > unrelated to commits. Obviously I could/should have contacted the > buildbot owner to at least inform him or her that something was amiss. > But somehow at that point one's technical enthusiasm for fixing a > problem diminishes when it's not clear that there *is* a problem. > (Grumble, grumble, mutter, mutter... :) ) I agree that having a buildbot of your own to administer tends to encourage you to be more aware of issues - it certainly did for me. However, from my own experience, the Windows buildbot environment is fairly flaky, and I spend far too much time killing "stuck" python processes and VS JIT debugger processes, rather than actually usefully debugging real issues. (And I don't know of any way of finding out where the stuck processes came from or what they were doing at the time that they got stuck, so all I can do is kill them...) I don't have any Windows sysadmin experience, so I struggle to fix these types of problem, and doing so often takes up all the time that would otherwise go to areas where I *could* do some good, digging into genuine issues :-( I don't really have any answer to this problem right now. Is it possible to set up a local buildslave-like environment (so I can run the test suite on my development PC without needing to set up access and register that PC as a temporary buildslave, which wouldn't be practical for me)? If I can get an environment where I can run the tests as I need and debug them in place, I might be able to work on improving the reliability of things. Paul.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4