As many of you already know, we've been looking for sponsors for providing hosting for some of our ancillary services (mailing lists, wiki, forums, et al). I put out a CFP to hosting providers a few months back, and with ample help from Ryan we've received a couple good offers.
I'm currently in discussion with the Software Freedom Conservancy to get the legal/administrative bits sorted out, so not everything is 100% nailed down just yet. However that's proceeded to a point that I'm starting to turn attention to the more technical end of things.
To refresh your memory, here's the background statement from the CFP:
""" We currently have various services hosted at a number of different locations with widely varying administrative capacities. We would like to centralize the administration of these services, such as consolidating them onto one platform. We also want room and flexibility to easily install additional services as we grow.
Services high on our priority list to migrate soon include mailing lists, Mattermost, and wiki. Bug tracking, web forum and gitlab are potential secondary priorities. Our Django-based main website may also be worth consolidating at some point in the future. """
Mailing list migration will be the first focus, possibly also with some DNS services. This would finally get us off SourceForge, allowing us to close that down. After that, I'm pretty open to what comes next; we can play it by ear depending on opportunities and manpower availability. If you have something you wish to put time into setting up and/or administrating, contact me to sort out details.
While in the CFP I had preferred physical hosting, the virtual hosting provided by the cloud service providers offering sponsorship to us does have some advantage in terms of flexibility - being able to spin up VMs on a per-service basis, or temporary ones for development and testing.
One common industry best practice I'd like us to adopt is to switch to use of automated scripts for setting up the systems and services. I.e., using cloud-config to bootstrap the raw VMs, and then something like Ansible or Puppet to do automatic configuration management. We can then consolidate the service setup scripts in a git repository. More on this later.
I've added a new "Inkscape Infrastructure" subgroup for holding this configuration management repository. This will be a sysadmin-oriented repository - i.e. more focused on the setup/administrative end, not so much on the data or code. I'll work up some policy/procedure for membership management of this group, for now I'll handle it manually.
I'm also going to move our 'credentials' repository into this Inkscape Infrastructure subgroup. Last board meeting we discussed migrating the credentials git repo, so that it's not hosted as a branch of the inkscape codebase (which causes it to take a long time to checkout). So this will implement that change.
Bryce