On Thu, Sep 17, 2020 at 09:32:57AM +0100, Alex Bennée wrote: > > Paolo Bonzini <bonz...@gnu.org> writes: > > > On 17/09/20 01:39, Bradley M. Kuhn wrote: > >> One thing to note is that my understanding is that most of what you're > >> getting access to through this program is proprietary software features > >> that > >> GitLab offers as add-ons. > > > > Basically all we need is the increased access to the CI environment (not > > just 400 minutes), and none of the add-on features. Self-hosting would > > of course help but we'd have to pay for the hardware resources to run > > the CI, and have someone that can keep the hardware running. > > It seems for the time being that public CI is still unlimited. The idea > of making our position as an FLOSS project "official" was to preempt any > changes to that might come down the track. > > The question of using proprietary features hadn't come up beyond a > hand-waving of "ohh there is a long list". We are however thinking about > consolidating some of our more disparate infrastructure onto gitlab so > it's mostly in one place - for example the bug tracker currently hosted > on launchpad. Personally I'd think it's unlikely we want to move things > like the mailing lists which are currently on nongnu (via Savannah). > > Ultimately as developers having to manage infrastructure is a bit of a > time-sink and currently it's hard for volunteer admins to be as > responsive as cloud-scale hosting companies who's income from non-free > software hosting pays for all our server time.
All the evidence we have is that developers generally do not do a good job at maintaining infrastructure in their spare time. This is largely unavoidable since a developer is always going to treat sysadmin tasks as a part time thing to spend as little time as possible on, prioritizing their coding work. So we end up either with unreliable services that continuously break (look how many times has Patchew died from ENOSPC this year), or the service happens to work reliably but is unmaintained becoming increasingly out of date and thus vulnerable, or the service simply ends up lagging behind state of the art offered by alternatives. > If there was a free > software only instance of GitLab which offered the same level of service > I would personally be interested but I don't know how much of the > projects income could be diverted to supporting that versus the travel > bursaries and other such things we usually spend our money on. Clearly the ideal situation would be 100% free software infrastructure we can use at zero cost, while still being state of the art in terms of services available to support our workflow. This doesn't exist, so we have to figure out the most effective tradeoff to make that supports QEMU's needs in an effective manner. GitLab's open core model means we're at least partially using open source infra, even if some features are closed. The basic GitLab CI features are actually open source AFAIK, so we're not relying on the closed source infra part of GitLab in that area. IOW, joining the open source program there is simply about getting an increased grant of free hardware resources to use. This is certainly preferrable to us making more use of Travis or Cirrus CI, or GitHub Actions, all of which are 100% closed CI systems AFAIK. Some projects have deployed their own GitLab instances (GNOME, FreeDesktop), but that is not without significant challenges in terms of deploying and maintaining the software as well as providing sufficient hardware to go along. eg See the surprising effect this self-hosting had on FreeDesktop costs: https://lists.freedesktop.org/archives/wayland-devel/2020-February/041232.html It has been a long tedious road merely to bring up a small number of CI runners on hardware sponsored by Red Hat, let alone get enough hardware to replace everything that we and our contributors currentl get for free via various public services. There's ultimately a big gap that exists in terms of a publically host Git Forge that offers state of the art features, based on 100% open source infra. I'm not seeing anyone being able to solve that in the forseeable future, and it doesn't seem like a sane use of QEMU's limited contributor time to divert resources away from development into infrastructure. We need to make a pragmatic tradeoff, certainly favouring open source where possible, but if we need to use other services too that's acceptable. Our switch to increasingly use GitLab for CI is certainly an improvement over our historical use of Travis, Shippable and Cirrus, and better for our contributors than our reliance on a handful of machines that only the QEMU Git maintainer can access, or the patchew system that breaks multiple times a year. > In this regard FLOSS projects are both leaches on paid for services as > well as being useful public facing PR for a SaaS platforms abilities. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
