From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.4 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,MIME_HTML_MOSTLY,SPF_HELO_NONE,SPF_PASS, T_KAM_HTML_FONT_INVALID autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id F1E6CC3F2C6 for ; Sat, 29 Feb 2020 10:14:19 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id C193F2468E for ; Sat, 29 Feb 2020 10:14:19 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=gitlab.com header.i=@gitlab.com header.b="TSgMNeIw" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C193F2468E Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=gitlab.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 342C66E1F9; Sat, 29 Feb 2020 10:14:16 +0000 (UTC) Received: from mail-oi1-x234.google.com (mail-oi1-x234.google.com [IPv6:2607:f8b0:4864:20::234]) by gabe.freedesktop.org (Postfix) with ESMTPS id C6DB26F4E1 for ; Fri, 28 Feb 2020 21:37:15 +0000 (UTC) Received: by mail-oi1-x234.google.com with SMTP id c16so4320532oic.3 for ; Fri, 28 Feb 2020 13:37:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gitlab.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ETwltv9lCMudAqcyf+3N0EPaW+3StmnTyvgL3ufvkow=; b=TSgMNeIwG4MHeSR8SKGyQxwSm5Rfj23G1uwoxqWgZ19Q9CLz/+9mgGf7iwmwXJ7KcI 4op/npOXsW842TA6XmfjwMie+1a77ufJpTZeFIk3Q6xQRbvqWk8Nxn63yp5qthBrmAqd FHMBHWs1CH2NHrAoDe4fwb8iaPUtGCj4qT9+A= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ETwltv9lCMudAqcyf+3N0EPaW+3StmnTyvgL3ufvkow=; b=DcGK03sgQHlNLGbR3KXYeEBV/Ad2OeVyPF7pAbYdtDIeUwYyhU8HfXUVEaZk9ADTlQ 9j8F+2HocHdVOSyKt/05OUZp4PhDQV0ao/BKSoLoRWr0XqMxlv7QcjWEcRssklwUZ79R 02PiiE7KaiQ8XRrMDsIUPhSGrett5S3uiTHnWTFXto/sni5myFj5WgZ9wSfmTxNc9IJk 6mzfPyIpazaM+zfbw8Sm/b6rVfei3MlmbbhcG78ugnoenImTn1uPKGVtC14rOw1QVYSO h9g2CbxKYd3Fv28Bjw7wzNNf82UD2PZVhxwxE70xmj4O7FnoRrMmFC9hb8e8P3d8tm6o oQfA== X-Gm-Message-State: APjAAAVWfQ7ZptXhl3LykF4EULzWVoGXXokrps3WoLp2TWKddVXdkLMh fgmRJmqMEJgE04cTcILIyb9GAgKskhz1QWO88sDeeQ== X-Google-Smtp-Source: APXvYqyXjm8bF1XKcGKjHJp/TtqPUKPXJn1FBHhKQ/amHrrIbqPOgV14tEvnuXJsDdDeZ19g8z3T7Nl/1EnRX5rGpnA= X-Received: by 2002:aca:d4c1:: with SMTP id l184mr4659408oig.172.1582925834753; Fri, 28 Feb 2020 13:37:14 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Nuritzi Sanchez Date: Fri, 28 Feb 2020 13:37:03 -0800 Message-ID: Subject: Re: [Mesa-dev] [Intel-gfx] gitlab.fd.o financial situation and impact on services To: Daniel Vetter X-Mailman-Approved-At: Sat, 29 Feb 2020 10:13:17 +0000 X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: intel-gfx , "X.Org development" , dri-devel , wayland , "X.Org Foundation Board" , Xorg Members List , amd-gfx list , Mesa Dev , gstreamer-devel@lists.freedesktop.org Content-Type: multipart/mixed; boundary="===============0213765554==" Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" --===============0213765554== Content-Type: multipart/alternative; boundary="000000000000163a7e059fa9a4c8" --000000000000163a7e059fa9a4c8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi All, I know there's been a lot of discussion already, but I wanted to respond to Daniel's original post. I joined GitLab earlier this month as their new Open Source Program Manager [1] and wanted to introduce myself here since I=E2=80=99ll be involved from= the GitLab side as we work together to problem-solve the financial situation here. My role at GitLab is to help make it easier for Open Source organizations to migrate (by helping to smooth out some of the current pain points), and to help advocate internally for changes to the product and our workflows to make GitLab better for Open Source orgs. We want to make sure that our Open Source community feels supported beyond just migration. As such, I=E2=80=99ll be running the GitLab Open Source Program [2]. My background is that I=E2=80=99m the former President and Chairperson of t= he GNOME Foundation, which is one of the earliest Free Software projects to migrate to GitLab. GNOME initially faced some limitations with the CI runner costs too, but thanks to generous support from donors, has no longer experienced those issues in recent times. I know there's already a working relationship between our communities, but it could be good to examine what GNOME and KDE have done and see if there's anything we can apply here. We've reached out to Daniel Stone, our main contact for the freedesktop.org migration, and he has gotten us in touch with Daniel V. and the X.Org Foundation Board to learn more about what's already been done and what we can do next. Please bear with me as I continue to get ramped up in my new job, but I=E2= =80=99d like to offer as much support as possible with this issue. We=E2=80=99ll be exploring ways for GitLab to help make sure there isn=E2=80=99t a gap in co= verage during the time that freedesktop looks for sponsors. I know that on GitLab=E2=80=99s side, supporting our Open Source user community is a prior= ity. Best, Nuritzi [1] https://about.gitlab.com/company/team/#nuritzi [2] https://about.gitlab.com/handbook/marketing/community-relations/opensource-= program/ On Fri, Feb 28, 2020 at 1:22 PM Daniel Vetter wrote: > On Fri, Feb 28, 2020 at 9:31 PM Dave Airlie wrote: > > > > On Sat, 29 Feb 2020 at 05:34, Eric Anholt wrote: > > > > > > On Fri, Feb 28, 2020 at 12:48 AM Dave Airlie > wrote: > > > > > > > > On Fri, 28 Feb 2020 at 18:18, Daniel Stone > wrote: > > > > > > > > > > On Fri, 28 Feb 2020 at 03:38, Dave Airlie > wrote: > > > > > > 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 fro= m > 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. > > > > > > > > > > The last I looked, Google GCP / Amazon AWS / Azure were all prett= y > > > > > comparable in terms of what you get and what you pay for them. > > > > > Obviously providers like Packet and Digital Ocean who offer > bare-metal > > > > > services are cheaper, but then you need to find someone who is > going > > > > > to properly administer the various machines, install decent > > > > > monitoring, make sure that more storage is provisioned when we ne= ed > > > > > more storage (which is basically all the time), make sure that th= e > > > > > hardware is maintained in decent shape (pretty sure one of the fd= .o > > > > > machines has had a drive in imminent-failure state for the last f= ew > > > > > months), etc. > > > > > > > > > > Given the size of our service, that's a much better plan (IMO) th= an > > > > > relying on someone who a) isn't an admin by trade, b) has a milli= on > > > > > other things to do, and c) hasn't wanted to do it for the past > several > > > > > years. But as long as that's the resources we have, then we're > paying > > > > > the cloud tradeoff, where we pay more money in exchange for fewer > > > > > problems. > > > > > > > > Admin for gitlab and CI is a full time role anyways. The system is > > > > definitely not self sustaining without time being put in by you and > > > > anholt still. If we have $75k to burn on credits, and it was divert= ed > > > > to just pay an admin to admin the real hw + gitlab/CI would that no= t > > > > be a better use of the money? I didn't know if we can afford $75k f= or > > > > an admin, but suddenly we can afford it for gitlab credits? > > > > > > As I think about the time that I've spent at google in less than a > > > year on trying to keep the lights on for CI and optimize our > > > infrastructure in the current cloud environment, that's more than the > > > entire yearly budget you're talking about here. Saying "let's just > > > pay for people to do more work instead of paying for full-service > > > cloud" is not a cost optimization. > > > > > > > > > > > Yes, we could federate everything back out so everyone runs their > own > > > > > builds and executes those. Tinderbox did something really similar > to > > > > > that IIRC; not sure if Buildbot does as well. Probably rules out > > > > > pre-merge testing, mind. > > > > > > > > Why? does gitlab not support the model? having builds done in > parallel > > > > on runners closer to the test runners seems like it should be a > thing. > > > > I guess artifact transfer would cost less then as a result. > > > > > > Let's do some napkin math. The biggest artifacts cost we have in Mes= a > > > is probably meson-arm64/meson-arm (60MB zipped from meson-arm64, > > > downloaded by 4 freedreno and 6ish lava, about 100 pipelines/day, > > > makes ~1.8TB/month ($180 or so). We could build a local storage next > > > to the lava dispatcher so that the artifacts didn't have to contain > > > the rootfs that came from the container (~2/3 of the insides of the > > > zip file), but that's another service to build and maintain. Buildin= g > > > the drivers once locally and storing it would save downloading the > > > other ~1/3 of the inside of the zip file, but that requires a big > > > enough system to do builds in time. > > > > > > I'm planning on doing a local filestore for google's lava lab, since = I > > > need to be able to move our xml files off of the lava DUTs to get the > > > xml results we've become accustomed to, but this would not bubble up > > > to being a priority for my time if I wasn't doing it anyway. If it > > > takes me a single day to set all this up (I estimate a couple of > > > weeks), that costs my employer a lot more than sponsoring the costs o= f > > > the inefficiencies of the system that has accumulated. > > > > I'm not trying to knock the engineering works the CI contributors have > > done at all, but I've never seen a real discussion about costs until > > now. Engineers aren't accountants. > > > > The thing we seem to be missing here is fiscal responsibility. I know > > this email is us being fiscally responsible, but it's kinda after the > > fact. > > > > I cannot commit my employer to spending a large amount of money (> 0 > > actually) without a long and lengthy process with checks and bounds. > > Can you? > > > > The X.org board has budgets and procedures as well. I as a developer > > of Mesa should not be able to commit the X.org foundation to spending > > large amounts of money without checks and bounds. > > > > The CI infrastructure lacks any checks and bounds. There is no link > > between editing .gitlab-ci/* and cashflow. There is no link to me > > adding support for a new feature to llvmpipe that blows out test times > > (granted it won't affect CI budget but just an example). > > We're working to get the logging in place to know which projects > exactly burn down the money so that we can take specific actions. If > needed. So pretty soon you wont be able to just burn down endless > amounts of cash with a few gitlab-ci commits. Or at least not for long > until we catch you and you either fix things up or CI is gone for your > project. > > > The fact that clouds run on credit means that it's not possible to say > > budget 30K and say when that runs out it runs out, you end up getting > > bills for ever increasing amounts that you have to cover, with nobody > > "responsible" for ever reducing those bills. Higher Faster Further > > baby comes to mind. > > We're working on this, since it's the boards responsibility to be on > top of stuff. It's simply that we didn't expect a massive growth of > this scale and this quickly, so we're a bit behind on the controlling > aspect. > > Also I guess it wasnt clear, but the board decision yesterday was the > stop loss order where we cut the cord (for CI at least). So yeah the > short term budget is firmly in place now. > > > Has X.org actually allocated the remaining cash in it's bank account > > to this task previously? Was there plans for this money that can't be > > executed now because we have to pay the cloud fees? If we continue to > > May and the X.org bank account hits 0, can XDC happen? > > There's numbers elsewhere in this thread, but if you'd read the > original announcement it states that the stop loss would still > guarantee that we can pay for everything for at least one year. We're > not going to get even close to 0 in the bank account. > > So yeah XDC happens, and it'll also still happen next year. Also fd.o > servers will keep running. The only thing we might need to switch off > is the CI support. > > > Budgeting and cloud is hard, the feedback loops are messy. In the old > > system the feedback loop was simple, we don't have admin time or money > > for servers we don't get the features, cloud allows us to get the > > features and enjoy them and at some point in the future the bill gets > > paid by someone else. Credit cards lifestyles all the way. > > Uh ... where exactly do you get the credit card approach from? SPI is > legally not allowed to extend us a credit (we're not a legal org > anymore), so if we hit 0 it's out real quick. No credit for us. If SPI > isnt on top of that it's their loss (but they're getting pretty good > at tracking stuff with the contractor they now have and all that). > > Which is not going to happen btw, if you've read the announcement mail > and all that. > > Cheers, Daniel > > > Like maybe we can grow up here and find sponsors to cover all of this, > > but it still feels a bit backwards from a fiscal pov. > > > > Again I'm not knocking the work people have done at all, CI is very > > valuable to the projects involved, but that doesn't absolve us from > > costs. > > > > Dave. > > > > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch > _______________________________________________ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-devel > --=20 Nuritzi SanchezSenior Open Source Program Manager | GitLab *Create, Collaborate, and Deploy together* Free Trial | Upgrade Now | Contact Support | Community --000000000000163a7e059fa9a4c8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi All,= =C2=A0


I know there's been a lot of discussion already, but I wa= nted to respond to Daniel's original post.


I joined GitLab earlier this month as their new Open= Source Program Manager [1] and wanted to introduce myself here since I=E2= =80=99ll be involved from the GitLab side as we work together to problem-so= lve the financial situation here. My role at GitLab is to help make it easi= er for Open Source organizations to migrate (by helping to smooth out some = of the current pain points), and to help advocate internally for changes to= the product and our workflows to make GitLab better for Open Source orgs. = We want to make sure that our Open Source community feels supported beyond = just migration. As such, I=E2=80=99ll be running the GitLab Open Source Pro= gram [2].


My background is = that I=E2=80=99m the former President and Chairperson of the GNOME Foundati= on, which is one of the earliest Free Software projects to migrate to GitLa= b. GNOME initially faced some limitations with the CI runner costs too, but= thanks to generous support from donors, has no longer experienced those is= sues in recent times. I know there's already a working relationship bet= ween our communities, but it could be good to examine what GNOME and KDE ha= ve done and see if there's anything we can apply here. We've reache= d out to Daniel Stone, our main contact for the freedesktop.org migration, and he has gotten us in touch with D= aniel V. and the X.Org Foundation Board to learn more about what's alre= ady been done and what we can do next.


Please bear with me as I continue to get ramped up in my new = job, but I=E2=80=99d like to offer as much support as possible with this is= sue. We=E2=80=99ll be exploring ways for GitLab to help make sure there isn= =E2=80=99t a gap in coverage during the time that freedesktop looks for spo= nsors. I know that on GitLab=E2=80=99s side, supporting our Open Source use= r community is a priority.


= Best,=C2=A0

Nuritzi

<= br>

[1] https://about.gitlab.com/company/t= eam/#nuritzi

[2] https://about.gitlab.com/handbook/marketing/comm= unity-relations/opensource-program/


On Fri, Feb 28, 2020 at 1:22 PM Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
On Fri, Feb 28, 20= 20 at 9:31 PM Dave Airlie <airlied@gmail.com> wrote:
>
> On Sat, 29 Feb 2020 at 05:34, Eric Anholt <eric@anholt.net> wrote:
> >
> > On Fri, Feb 28, 2020 at 12:48 AM Dave Airlie <airlied@gmail.com> wrote:
> > >
> > > On Fri, 28 Feb 2020 at 18:18, Daniel Stone <daniel@fooishbar.org> w= rote:
> > > >
> > > > On Fri, 28 Feb 2020 at 03:38, Dave Airlie <airlied@gmail.com> w= rote:
> > > > > 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 straig= ht 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 w= e aren't getting any
> > > > > sort of discounts here. Having google sponsor the = credits costs google
> > > > > substantially less than having any other company g= ive us money to do
> > > > > it.
> > > >
> > > > The last I looked, Google GCP / Amazon AWS / Azure were= all pretty
> > > > comparable in terms of what you get and what you pay fo= r them.
> > > > Obviously providers like Packet and Digital Ocean who o= ffer bare-metal
> > > > services are cheaper, but then you need to find someone= who is going
> > > > to properly administer the various machines, install de= cent
> > > > monitoring, make sure that more storage is provisioned = when we need
> > > > more storage (which is basically all the time), make su= re that the
> > > > hardware is maintained in decent shape (pretty sure one= of the fd.o
> > > > machines has had a drive in imminent-failure state for = the last few
> > > > months), etc.
> > > >
> > > > Given the size of our service, that's a much better= plan (IMO) than
> > > > relying on someone who a) isn't an admin by trade, = b) has a million
> > > > other things to do, and c) hasn't wanted to do it f= or the past several
> > > > years. But as long as that's the resources we have,= then we're paying
> > > > the cloud tradeoff, where we pay more money in exchange= for fewer
> > > > problems.
> > >
> > > Admin for gitlab and CI is a full time role anyways. The sys= tem is
> > > definitely not self sustaining without time being put in by = you and
> > > anholt still. If we have $75k to burn on credits, and it was= diverted
> > > to just pay an admin to admin the real hw + gitlab/CI would = that not
> > > be a better use of the money? I didn't know if we can af= ford $75k for
> > > an admin, but suddenly we can afford it for gitlab credits?<= br> > >
> > As I think about the time that I've spent at google in less t= han a
> > year on trying to keep the lights on for CI and optimize our
> > infrastructure in the current cloud environment, that's more = than the
> > entire yearly budget you're talking about here.=C2=A0 Saying = "let's just
> > pay for people to do more work instead of paying for full-service=
> > cloud" is not a cost optimization.
> >
> >
> > > > Yes, we could federate everything back out so everyone = runs their own
> > > > builds and executes those. Tinderbox did something real= ly similar to
> > > > that IIRC; not sure if Buildbot does as well. Probably = rules out
> > > > pre-merge testing, mind.
> > >
> > > Why? does gitlab not support the model? having builds done i= n parallel
> > > on runners closer to the test runners seems like it should b= e a thing.
> > > I guess artifact transfer would cost less then as a result.<= br> > >
> > Let's do some napkin math.=C2=A0 The biggest artifacts cost w= e have in Mesa
> > is probably meson-arm64/meson-arm (60MB zipped from meson-arm64,<= br> > > downloaded by 4 freedreno and 6ish lava, about 100 pipelines/day,=
> > makes ~1.8TB/month ($180 or so).=C2=A0 We could build a local sto= rage next
> > to the lava dispatcher so that the artifacts didn't have to c= ontain
> > the rootfs that came from the container (~2/3 of the insides of t= he
> > zip file), but that's another service to build and maintain.= =C2=A0 Building
> > the drivers once locally and storing it would save downloading th= e
> > other ~1/3 of the inside of the zip file, but that requires a big=
> > enough system to do builds in time.
> >
> > I'm planning on doing a local filestore for google's lava= lab, since I
> > need to be able to move our xml files off of the lava DUTs to get= the
> > xml results we've become accustomed to, but this would not bu= bble up
> > to being a priority for my time if I wasn't doing it anyway.= =C2=A0 If it
> > takes me a single day to set all this up (I estimate a couple of<= br> > > weeks), that costs my employer a lot more than sponsoring the cos= ts of
> > the inefficiencies of the system that has accumulated.
>
> I'm not trying to knock the engineering works the CI contributors = have
> done at all, but I've never seen a real discussion about costs unt= il
> now. Engineers aren't accountants.
>
> The thing we seem to be missing here is fiscal responsibility. I know<= br> > this email is us being fiscally responsible, but it's kinda after = the
> fact.
>
> I cannot commit my employer to spending a large amount of money (> = 0
> actually) without a long and lengthy process with checks and bounds. > Can you?
>
> The X.org board has budgets and procedures as well. I as a developer > of Mesa should not be able to commit the X.org foundation to spending<= br> > large amounts of money without checks and bounds.
>
> The CI infrastructure lacks any checks and bounds. There is no link > between editing .gitlab-ci/* and cashflow. There is no link to me
> adding support for a new feature to llvmpipe that blows out test times=
> (granted it won't affect CI budget but just an example).

We're working to get the logging in place to know which projects
exactly burn down the money so that we can take specific actions. If
needed. So pretty soon you wont be able to just burn down endless
amounts of cash with a few gitlab-ci commits. Or at least not for long
until we catch you and you either fix things up or CI is gone for your
project.

> The fact that clouds run on credit means that it's not possible to= say
> budget 30K and say when that runs out it runs out, you end up getting<= br> > bills for ever increasing amounts that you have to cover, with nobody<= br> > "responsible" for ever reducing those bills. Higher Faster F= urther
> baby comes to mind.

We're working on this, since it's the boards responsibility to be o= n
top of stuff. It's simply that we didn't expect a massive growth of=
this scale and this quickly, so we're a bit behind on the controlling aspect.

Also I guess it wasnt clear, but the board decision yesterday was the
stop loss order where we cut the cord (for CI at least). So yeah the
short term budget is firmly in place now.

> Has X.org actually allocated the remaining cash in it's bank accou= nt
> to this task previously? Was there plans for this money that can't= be
> executed now because we have to pay the cloud fees? If we continue to<= br> > May and the X.org bank account hits 0, can XDC happen?

There's numbers elsewhere in this thread, but if you'd read the
original announcement it states that the stop loss would still
guarantee that we can pay for everything for at least one year. We're not going to get even close to 0 in the bank account.

So yeah XDC happens, and it'll also still happen next year. Also fd.o servers will keep running. The only thing we might need to switch off
is the CI support.

> Budgeting and cloud is hard, the feedback loops are messy. In the old<= br> > system the feedback loop was simple, we don't have admin time or m= oney
> for servers we don't get the features, cloud allows us to get the<= br> > features and enjoy them and at some point in the future the bill gets<= br> > paid by someone else. Credit cards lifestyles all the way.

Uh ... where exactly do you get the credit card approach from? SPI is
legally not allowed to extend us a credit (we're not a legal org
anymore), so if we hit 0 it's out real quick. No credit for us. If SPI<= br> isnt on top of that it's their loss (but they're getting pretty goo= d
at tracking stuff with the contractor they now have and all that).

Which is not going to happen btw, if you've read the announcement mail<= br> and all that.

Cheers, Daniel

> Like maybe we can grow up here and find sponsors to cover all of this,=
> but it still feels a bit backwards from a fiscal pov.
>
> Again I'm not knocking the work people have done at all, CI is ver= y
> valuable to the projects involved, but that doesn't absolve us fro= m
> costs.
>
> Dave.



--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
wayland-devel mailing list
wa= yland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/li= stinfo/wayland-devel


--
Nuritzi SanchezSenior O= pen Source Program Manager | GitLab

Create, Collaborate, and Deploy together
Free Trial=C2=A0|=C2=A0Upgrade Now= =C2=A0|=C2=A0Contact Support=C2=A0|=C2=A0Community
<= /div>
--000000000000163a7e059fa9a4c8-- --===============0213765554== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel --===============0213765554==--