[Cython] Cython infrastructure

[Robert Bradshaw]

Since the inception of the Cython project, William Stein's generously
allowed us to share Sage's hardware to host Cython's infrastructure,
which has been a great help. However, I think the time has come to
re-evaluate our options, which have actually improved a lot over the
last couple of years.

Note that this is not simply an issue of finding hardware, or raw VMs,
as we want to cut down on the personal maintenance costs as well (both
ongoing and emergency, neither of which are suited to a small number
of volunteers).

Several years ago we moved the main repositories over to github, and
the wiki was moved a while ago as well (to solve the spam problem).
However, the web site, trac (for bugs), and jenkins (for continuous
testing) are still on UW hardware. I propose we address them as
follows:

cython.org
Currently cython.org consists of a single landing page, a pile of
release tarballs, and all the documentation (which is 100% generated
from the repository). I propose we rely on github pages for the
(small) site, pypi for tarball archiving, and
http://cython.readthedocs.io (I recently got admin permission for) for
the documentation.

trac.cython.org
This is probably the most controversial, but I think it makes sense to
migrate to github issues. While clearly not as powerful, featureful,
or customizable as trac, it seems it would fulfill our modest needs. I
am happy to do the migration if no one objects.

jenkins
This is the hardest to replace. We have travis.ci which integrates
well with github (e.g. automatically checking pull requests) but is
much more limited (e.g. it doesn't have artifact caching, there's no
way we'd have enough CPU to build and test the latest pre-releases of
CPython, let alone all of Sage). This has been where UW's hardware has
been something we simply couldn't get anywhere else.

There are really three parts to this: (1) the configuration (2) the
hosting of the jeknins server and (3) the build slaves themselves. (3)
is ephemeral, and ideally could come and go with little friction as
people and institutions are willing to donate raw horsepower (e.g.
UW). I'm not sure about (2)--that requires a single machine at least
(but less beefy than those for (3)). Ideally (1) could be under
revision control (e.g. in a git repository) allowing us to set up (2)
and (3) easily.

Anyone have any input/experience on this? Or can travis-ci be adopted
to be a sufficient replacement?


All of this puts a lot in the hands of one company (github). I highly
doubt they're going away, but because of the distributed nature of Git
even if they disappeared nothing permanent would be lost. I would also
set up a script to periodically backup github issues which is the one
non-repo-backed service we use. (Is it worth also trying to archive
github pr discussion? Maybe set up a and subscribe mailing list just
for that?)

- Robert