On Wed, Jul 20, 2016 at 7:41 AM, William Stein <wst...@gmail.com> wrote: > On Tue, Jul 19, 2016 at 11:01 PM, Robert Bradshaw <rober...@gmail.com> wrote: >> 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: > > Despite the flakiness of Univ of Washington hardware, and lack of any > admin support at all right now,
The track record is still pretty good, better than my home server on a Comcast connection :). > I just want to make clear that you are > still very much allowed to use our resources, and I don't expect this > to change. But a strategy to not have to *rely* on it in any way is > critical. Thanks, and my thoughts exactly. > A weird curveball is that I am being "forced" by a grant to spend > about $10K on a new server (or servers) at UW in early September. My > current plan is to get a small number of very high quality machines > and install Kubernetes on them. Kubernetes makes it so people with > appropriate credentials can trivially point a kubernetes client at the > cluster and launch Docker container images. This could be very > useful for build testing while making the ephemeral nature of the > available resources clear. Though I'm busy with SageMath, Inc., > there are a number of other people working fulltime on it now, and I'm > not teaching anymore, so I think I'll personally have the time to at > least install and setup k8s on a few machines at UW in September. Cool. >> 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?) > > I'm sure a lot of people have precisely the same concern. I do with > sagemathcloud's source code, but haven't setup similar backups yet. > I'm curious what you do. I'll probably have a cron job that syncs all the repos and downloads the issues to my home server, which is backed up. I'd share this script and encourage others to do the same. _______________________________________________ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
