Catchy subject eh? Unless, of course, you've seen Forgetting Sarah
Marshall, in which case, it's probably a tad disturbing.
Nevertheless, I do have a surprise for everyone. I spent a lot of
time early last year trying to keep the buildbots green, especially
the x64 Windows ones. This was quite enjoyable, at least initially.
By the time I got back to London after PyCon last year, the buildbot
honeymoon was wearing off. As there's usually only one person that
has access to a given buildbot, and that person is rarely you, it
can be a right pain in the ass trying to debug problems you can't
reproduce on platforms you don't have access to (especially if all
you've got is an error message that doesn't make sense).
I was convinced there must be a better way.
Around mid-April, the buildbot on my FreeBSD 6.x box I had recently
set up kept failing on on setitimer tests. I received an email from
a chap named Guilherme Polo who had seen the buildbot test failures
and wanted to assist. I was swamped with client work at the time; I
wasn't able to run any of the test scripts he sent me, but, hey, he
seemed like a nice chap, so I thought what the hell, and just gave
him an account on the box and checked out a copy of trunk in his
Now, mind you, this was before Guilherme was a committer; I didn't
know the guy from a bar of soap. For all I knew, he could have been
using the shell account to launch a massive DDoS or phishing scam.
However, no more than five minutes after I created his account, he'd
diagnosed the problem, replicated the behaviour in a C program, and,
with a bit of googling, figured out what was wrong and proposed a
And that's when it hit me. Buildbots are fine when everything is
running smoothly, but nothing compares to actually having access to
a system when you're trying to debug something.
So, I thought to myself, why not buy a couple of clunky old boxes
off eBay and donate them to the PSF, such that all developers had
access to them? I dropped a note to Guido and Neal, they put me
in touch with Titus, who had just accepted a position at Michigan
State, and, well...
Ten months, seven trips to MSU, six blown fuses and about $60,000
later, I'm proud to introduce you all to Snakebite: The Open Network!
A network of around 37-ish servers of all different shapes and sizes,
spread over three sites, specifically geared towards the needs of
open source projects like Python.
Every CPython, Jython, IronPython and PyPy committer will have access
to every development server on the network. I've also extended the
offer to prominent Python projects like Django and Twisted.
Eventually, I'll invite other open source projects to participate
(Apache, Subversion, MySQL, Postgres, etc), but the network is my
gift to All Things Python, first and foremost, so Python projects
will always get preferential treatment.
Support for the initiative so far has been nothing short of sublime.
Microsoft jumped on board and provided unlimited MSDN licenses in
less time than it took me to write them an e-mail asking for stuff.
I sent HP an e-mail asking if they could spare a Tru64 license, and
maybe 2GB of RAM for an extremely crappy Itanium box I bought off
eBay. They saw my Tru64 license request and raised with media and
licenses to the latest version of HP-UX.
Unfortunately, it was too much trouble for them to try and source
2GB of RAM for the Itanium I bought. So, instead, they shipped two
massive quad Itanium 2 RX-5670s, chock full of 73GB 15k disks and
no less than 78GB of RAM between the two servers; 32GB in one and
46GB in the other. Well then.
(I'd hate to think what would have turned up had I asked them for
two quad Itanium monsters.)
Sun, Google and Canonical have also expressed a lot of interest in
the project -- I stopped asking for hardware a while back though as
we've literally run out of space to host it all.
The website is live, but the content is a bit sparse at the moment,
excluding the poorly worded front page and the reasonably accurate
It'll probably be a few weeks before you can start logging in and
doing stuff. The HPCC/CSE server room at MSU is about to have walls
knocked in and ramps built in order to accommodate a giant PDU that
has been sitting outside it for about six months; the Snakebite rack
is going to get shuffled around a bit so I figure there's not much
point going live before that's taken care of.
Other than that, I'm just happy to get this off my chest, ten months
is a freakin' long time to try and keep something like this a secret
Thanks to everyone who has contributed so far. Titus, Bill, Adam,
Kelly, George: Snakebite wouldn't be anything more than a twinkle
in my eye if it weren't for the support MSU has thrown behind the
project, thank you for all your efforts to date. Hank, Garrett and
Sam: having the support of Microsoft from very early on has been a
huge boost and the MSDN licenses have already been invaluable. Bob,
well, what can I say, there was a period there where every e-mail
thread between us seemed to result in something being shipped from
HP to MSU; thanks to you and HP's open source labs.
And last but not least, thanks to Guido and all the Python committers
for their tireless efforts to date. Although the sheer elegance of
the language is what initially attracted me to Python, it was the
developer community that made me want to stick around.
Snakebite is my gift to you!
Is anyone else frustrated by Luke Kenneth Casson Leighton's rants in
python-dev? It seems he is living on another planet to me. Or am I
seeing it all wrong?
--Guido van Rossum (home page: http://www.python.org/~guido/)
the requirement to build the documentation using a sphinx version from the trunk
was merged to at least the 2.6 branch. This is clearly not a bug fix. Is it
really necessary to rely on a trunk/unreleased version? Would it be possible to
revert this change?
Background: The Debian distribution requires distribution of files which can be
edited in the preferred format, which excludes generated documentation. I can
pre-build the 2.6 documentation, and then include it in the so called "contrib"
section of the archive, but I would like to see it available in the "main"
section. Including a copy of the sphinx trunk in the python package uploaded to
the distribution would be a hack around this (it is unlikely that the sphinx
trunk version will be available in Debian).
For python-2.5, Debian was not able to put the docs in the "main" section,
because a build tool with (in the eyes of Debian) "non-free" license was used to
build the docs. It is nice that this is fixed now, but for now one reason is
exchanged by another one why we cannot move the docs to Debian's "main" section
of the archive.
I've extended the pre-commit hook to also check documentation files (*.rst)
for trailing whitespace and tabs.
If you find a bug that doesn't let you commit legitimate content, please
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.