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