dri-devel.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel.vetter@ffwll.ch>
To: Dave Airlie <airlied@gmail.com>
Cc: amd-gfx list <amd-gfx@lists.freedesktop.org>,
	intel-gfx <intel-gfx@lists.freedesktop.org>,
	"X.Org development" <xorg-devel@lists.x.org>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	wayland <wayland-devel@lists.freedesktop.org>,
	"X.Org Foundation Board" <board@foundation.x.org>,
	Xorg Members List <members@x.org>,
	gstreamer-devel@lists.freedesktop.org,
	Mesa Dev <mesa-dev@lists.freedesktop.org>
Subject: Re: [Intel-gfx] gitlab.fd.o financial situation and impact on services
Date: Fri, 28 Feb 2020 08:44:48 +0100	[thread overview]
Message-ID: <CAKMK7uHJy0v0Bdi10hcKUOwWrez_3rFT_kEOUxfPje-ruYO8AQ@mail.gmail.com> (raw)
In-Reply-To: <CAPM=9txcGPvFdSzMtYZXyqLKnWyacSMuHdoXdV63M53fLFVFpw@mail.gmail.com>

On Fri, Feb 28, 2020 at 4:38 AM Dave Airlie <airlied@gmail.com> wrote:
>
> On Fri, 28 Feb 2020 at 07:27, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> >
> > Hi all,
> >
> > You might have read the short take in the X.org board meeting minutes
> > already, here's the long version.
> >
> > The good news: gitlab.fd.o has become very popular with our
> > communities, and is used extensively. This especially includes all the
> > CI integration. Modern development process and tooling, yay!
> >
> > The bad news: The cost in growth has also been tremendous, and it's
> > breaking our bank account. With reasonable estimates for continued
> > growth we're expecting hosting expenses totalling 75k USD this year,
> > and 90k USD next year. With the current sponsors we've set up we can't
> > sustain that. We estimate that hosting expenses for gitlab.fd.o
> > without any of the CI features enabled would total 30k USD, which is
> > within X.org's ability to support through various sponsorships, mostly
> > through XDC.
> >
> > Note that X.org does no longer sponsor any CI runners themselves,
> > we've stopped that. The huge additional expenses are all just in
> > storing and serving build artifacts and images to outside CI runners
> > sponsored by various companies. A related topic is that with the
> > growth in fd.o it's becoming infeasible to maintain it all on
> > volunteer admin time. X.org is therefore also looking for admin
> > sponsorship, at least medium term.
> >
> > Assuming that we want cash flow reserves for one year of gitlab.fd.o
> > (without CI support) and a trimmed XDC and assuming no sponsor payment
> > meanwhile, we'd have to cut CI services somewhere between May and June
> > this year. The board is of course working on acquiring sponsors, but
> > filling a shortfall of this magnitude is neither easy nor quick work,
> > and we therefore decided to give an early warning as soon as possible.
> > Any help in finding sponsors for fd.o is very much appreciated.
>
> a) Ouch.
>
> b) we probably need to take a large step back here.
>
> Look at this from a sponsor POV, why would I give X.org/fd.o
> sponsorship money that they are just giving straight to google to pay
> for hosting credits? Google are profiting in some minor way from these
> hosting credits being bought by us, and I assume we aren't getting any
> sort of discounts here. Having google sponsor the credits costs google
> substantially less than having any other company give us money to do
> it.
>
> If our current CI architecture is going to burn this amount of money a
> year and we hadn't worked this out in advance of deploying it then I
> suggest the system should be taken offline until we work out what a
> sustainable system would look like within the budget we have, whether
> that be never transferring containers and build artifacts from the
> google network, just having local runner/build combos etc.

Google has sponsored 30k in hosting credits last year, these simply
ran out _much_ faster than anyone planned for. So this is by far not a
free thing for them. Plus there's also other companies sponsoring CI
runners and what not else in equally substantial amounts, plus the
biggest thing, sponsored admin time (more or less officially). So
there's a _lot_ of room for companies like Red Hat to sponsor without
throwing any money in google's revenue stream.

Or it doesn't happen, and then yeah the decision has already been made
to shutter the CI services. So this is also a question of whether we
(as a community and all the companies benefitting from the work done)
really want this, or maybe not quite.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2020-02-28  7:45 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-27 21:27 gitlab.fd.o financial situation and impact on services Daniel Vetter
2020-02-27 23:45 ` Matt Turner
2020-02-28  7:59   ` Daniel Stone
2020-02-28 10:09     ` Jan Engelhardt
2020-02-28 11:11       ` Daniel Stone
2020-02-28 21:20     ` Matt Turner
2020-02-28  0:21 ` Luc Verhaegen
2020-02-28  0:33 ` Carsten Haitzler
2020-02-28  1:00 ` [Mesa-dev] " Tom Stellard
2020-02-28  1:08   ` Tom Stellard
2020-02-28  3:37 ` [Intel-gfx] " Dave Airlie
2020-02-28  7:44   ` Daniel Vetter [this message]
2020-02-28  8:17   ` Daniel Stone
2020-02-28  8:48     ` Dave Airlie
2020-02-28  9:26       ` Daniel Stone
2020-02-28 19:34       ` [Mesa-dev] " Eric Anholt
2020-02-28 20:30         ` Dave Airlie
2020-02-28 21:22           ` Daniel Vetter
2020-02-28 21:37             ` Nuritzi Sanchez
2020-04-04 13:55         ` Andreas Bergmeier
2020-04-05 14:07           ` Nicolas Dufresne
2020-02-28  9:28   ` Erik Faye-Lund
2020-02-28  9:40     ` Lionel Landwerlin
2020-02-28 10:06       ` Erik Faye-Lund
2020-02-28 10:43         ` Daniel Stone
2020-02-28 11:02           ` Erik Faye-Lund
2020-02-28 11:46             ` Michel Dänzer
2020-02-28 13:08               ` Lionel Landwerlin
2020-02-29 18:14           ` Timur Kristóf
2020-02-29 19:46             ` Nicolas Dufresne
2020-02-29 20:28               ` Timur Kristóf
2020-02-29 21:54                 ` Jason Ekstrand
2020-02-29 22:20                   ` Nicolas Dufresne
2020-03-01  5:46                     ` Marek Olšák
2020-04-03 14:12                       ` Michel Dänzer
2020-04-04 15:11                         ` Rob Clark
2020-04-04 17:47                           ` Nicolas Dufresne
2020-04-04 18:16                             ` Rob Clark
2020-04-04 18:41                               ` Rob Clark
2020-04-04 18:47                                 ` Rob Clark
2020-04-04 23:39                               ` Peter Hutterer
2020-04-04 23:32                           ` Peter Hutterer
2020-04-06 15:42                           ` Adam Jackson
2020-04-06 16:34                             ` Rob Clark
2020-04-06 17:04                               ` Michel Dänzer
2020-04-06 18:00                                 ` Rob Clark
2020-03-01 14:14               ` [Mesa-dev] [Intel-gfx] " Michel Dänzer
2020-03-01 14:27                 ` Nicolas Dufresne
2020-03-01 19:51                   ` Jacob Lifshay
2020-03-01 20:18                     ` [Intel-gfx] [Mesa-dev] " Jason Ekstrand
2020-03-01 20:30                       ` Bridgman, John
2020-03-01 20:49                       ` Nicolas Dufresne
2020-03-02  4:53                         ` Jason Ekstrand
2020-02-28  9:47     ` [Mesa-dev] [Intel-gfx] " Daniel Vetter
2020-02-28 10:10       ` Erik Faye-Lund
2020-02-28 10:27       ` Lucas Stach
2020-02-28 11:43     ` Michel Dänzer
2020-02-28 17:00       ` [Intel-gfx] [Mesa-dev] " Rob Clark
2020-02-29 15:58         ` Jason Ekstrand
2020-02-28 18:03   ` [Intel-gfx] " Kristian Høgsberg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAKMK7uHJy0v0Bdi10hcKUOwWrez_3rFT_kEOUxfPje-ruYO8AQ@mail.gmail.com \
    --to=daniel.vetter@ffwll.ch \
    --cc=airlied@gmail.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=board@foundation.x.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=gstreamer-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=members@x.org \
    --cc=mesa-dev@lists.freedesktop.org \
    --cc=wayland-devel@lists.freedesktop.org \
    --cc=xorg-devel@lists.x.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).