dri-devel.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: "Timur Kristóf" <timur.kristof@gmail.com>
To: Nicolas Dufresne <nicolas@ndufresne.ca>,
	Discussion of the development of and with GStreamer
	<gstreamer-devel@lists.freedesktop.org>,
	Daniel Stone <daniel@fooishbar.org>,
	Erik Faye-Lund <erik.faye-lund@collabora.com>
Cc: amd-gfx list <amd-gfx@lists.freedesktop.org>,
	Daniel Vetter <daniel.vetter@ffwll.ch>,
	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>,
	Mesa Dev <mesa-dev@lists.freedesktop.org>
Subject: Re: [Mesa-dev] [Intel-gfx] gitlab.fd.o financial situation and impact on services
Date: Sat, 29 Feb 2020 21:28:33 +0100	[thread overview]
Message-ID: <d9dca12759fd6a549dc4cd71b5f210a4dced01cd.camel@gmail.com> (raw)
In-Reply-To: <d0ef47e45c83b342494e6781b808b4831a008836.camel@ndufresne.ca>

On Sat, 2020-02-29 at 14:46 -0500, Nicolas Dufresne wrote:
> > 
> > 1. I think we should completely disable running the CI on MRs which
> > are
> > marked WIP. Speaking from personal experience, I usually make a lot
> > of
> > changes to my MRs before they are merged, so it is a waste of CI
> > resources.
> 
> In the mean time, you can help by taking the habit to use:
> 
>   git push -o ci.skip

Thanks for the advice, I wasn't aware such an option exists. Does this
also work on the mesa gitlab or is this a GStreamer only thing?

How hard would it be to make this the default?

> That's a much more difficult goal then it looks like. Let each
> projects
> manage their CI graph and content, as each case is unique. Running
> more
> tests, or building more code isn't the main issue as the CPU time is
> mostly sponsored. The data transfers between the cloud of gitlab and
> the runners (which are external), along to sending OS image to Lava
> labs is what is likely the most expensive.
> 
> As it was already mention in the thread, what we are missing now, and
> being worked on, is per group/project statistics that give us the
> hotspot so we can better target the optimization work.

Yes, would be nice to know what the hotspot is, indeed.

As far as I understand, the problem is not CI itself, but the bandwidth
needed by the build artifacts, right? Would it be possible to not host
the build artifacts on the gitlab, but rather only the place where the
build actually happened? Or at least, only transfer the build artifacts
on-demand?

I'm not exactly familiar with how the system works, so sorry if this is
a silly question.

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2020-03-02  8:18 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
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 [this message]
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=d9dca12759fd6a549dc4cd71b5f210a4dced01cd.camel@gmail.com \
    --to=timur.kristof@gmail.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=board@foundation.x.org \
    --cc=daniel.vetter@ffwll.ch \
    --cc=daniel@fooishbar.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=erik.faye-lund@collabora.com \
    --cc=gstreamer-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=members@x.org \
    --cc=mesa-dev@lists.freedesktop.org \
    --cc=nicolas@ndufresne.ca \
    --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).