On Sat, Feb 08, 2020 at 12:38:14AM +0100, Daniel Stenberg via rockbox-dev wrote: > As mentioned in the subject, the Haxx team (me, Björn, Linus and Kjell) will > stop hosting most Rockbox related services on January 1st 2021. It should > give everyone plenty of time to find new places and alternatives for > everything that needs to survive.
That's a remarkably generous timeframe, thank you! (On top of many, many years of generous hosting services, thank you again!) > https://github.com/Rockbox/rockbox/wiki/Transition (I started this conversation on IRC, but wanted to elaborate more here) The problem I see with some of those proposals is that it mixes both hosting migration and retooling, and the current level of user and developer interest doesn't seem to support a major retooling effort. It seems to me that the main problem with the existing infrastructure is a lack of general maintainance, and IMO it would take less overall work to actively maintain what we have than to completely retool. The fact that things still work as well as they do is a testament to how well they were put together, especially the build system. Migrating the existing infrastructure as-is to systems that current developers can maintain is IMO the best path forward. After the hosting crisis is mitigated, then we can turn our attention to making whatever incremental (or major!) changes we see fit, but on a more relaxed timeframe. I'm also not keen on retooling around proprietary services like github. I think being able to self-host is extremely important. So. If we're to migrate stuff off of the haxx infrastructure, we need to know more: * Is the existing *.rockbox.org stuff self-contained on a single dedicated server/VM, or are the services spread out onto multiple hosts? (If it's all self-contained, then migrating as-is will be a lot easier) (if it's not, then we'll need to know what the service dependencies are, eg php, database(s), and so forth) * What is the typical server resource load? (CPU, RAM, disk) * What is the typical bandwidth usage? (ideally on a per-service basis; I imagine serving the builds, followed by git & builder infrastructure, are the biggest users) I already self-host my entire digital presence [1], so depending on the answers to the above questions, I should be able to host all of the haxx-hosted rockbox services with only an incremental level of effort. I think DNS and @rockbox email/lists should probably move too, but those can probably be the last to go -- This way HAXX never has to be bothered about anything rockbox ever again. :) Anyway, thought I'd help keep the conversation going. The level of effort needed for various actions really depend on the details involved, and I think the more information we have, the better a plan we can come up with. [1] DNS, email & mailing lists, web (plus php and python), wikis, databases, git repos (gitolite + cgit), flyspray, xmpp, a rockbox builder, shell access, and more. This server is 12c Opteron, 32GB of ram, and about 5TB free RAID disk space, piggbacking on an uncapped fiber feed that routinely exceeds 500Mbps uplink bandwidth.) At home I have a lot more compute resources, with a private jenkins instance for my other F/OSS work, multiple VMs, and another rockbox builder... but with a very crappy 2Mbps uplink. I have a third site with a slightly crappier uplink that I was intending to set up with additional CI builders, but need to swap the server out first. - Solomon -- Solomon Peachy pizza at shaftnet dot org High Springs, FL ^^ (email/xmpp) ^^ Quidquid latine dictum sit, altum videtur.
signature.asc
Description: PGP signature
