Re: [Intel-gfx] [Mesa-dev] gitlab.fd.o financial situation and impact on services

From: Jason Ekstrand <jason@jlekstrand.net>
To: Rob Clark <robdclark@gmail.com>
Cc: "Erik Faye-Lund" <erik.faye-lund@collabora.com>,
	"Daniel Vetter" <daniel.vetter@ffwll.ch>,
	"Michel Dänzer" <michel@daenzer.net>,
	"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>,
	"amd-gfx list" <amd-gfx@lists.freedesktop.org>,
	"Mesa Dev" <mesa-dev@lists.freedesktop.org>,
	intel-gfx <intel-gfx@lists.freedesktop.org>,
	"Discussion of the development of and with GStreamer"
	<gstreamer-devel@lists.freedesktop.org>
Subject: Re: [Intel-gfx] [Mesa-dev] gitlab.fd.o financial situation and impact on services
Date: Sat, 29 Feb 2020 09:58:40 -0600	[thread overview]
Message-ID: <CAOFGe965f-EQKtrXOxGmTuZh97et6++wOhpaPqEfDp7Ysdk-5w@mail.gmail.com> (raw)
In-Reply-To: <CAF6AEGspENM8iRxnfzOSvWp2Y-CfAcxV+=Do4t0Ojp5Qo3O3YA@mail.gmail.com>

On Fri, Feb 28, 2020 at 11:00 AM Rob Clark <robdclark@gmail.com> wrote:
>
> On Fri, Feb 28, 2020 at 3:43 AM Michel Dänzer <michel@daenzer.net> wrote:
> >
> > On 2020-02-28 10:28 a.m., Erik Faye-Lund wrote:
> > >
> > > We could also do stuff like reducing the amount of tests we run on each
> > > commit, and punt some testing to a per-weekend test-run or someting
> > > like that. We don't *need* to know about every problem up front, just
> > > the stuff that's about to be released, really. The other stuff is just
> > > nice to have. If it's too expensive, I would say drop it.
> >
> > I don't agree that pre-merge testing is just nice to have. A problem
> > which is only caught after it lands in mainline has a much bigger impact
> > than one which is already caught earlier.
> >
>
> one thought.. since with mesa+margebot we effectively get at least
> two(ish) CI runs per MR, ie. one when it is initially pushed, and one
> when margebot rebases and tries to merge, could we leverage this to
> have trimmed down pre-margebot CI which tries to just target affected
> drivers, with margebot doing a full CI run (when it is potentially
> batching together multiple MRs)?
>
> Seems like a way to reduce our CI runs with a good safety net to
> prevent things from slipping through the cracks.

Here are a couple more hopefully constructive but possibly bogus ideas:

 1. Suggest people put their CI farms behind a squid transparent
caching proxy.  There seem to be many HowTo's on the internet for
doing this and it shouldn't be terribly hard.  Maybe GitLab uses too
much HTTPS and that messes things up?  If not, this would cut
downloads to one-per-farm rather than one-per-machine

 2. Add -Dstrip=true to the meson config.  We want asserts but do we
really need those debug symbols?  Quick testing on my machine, it
seems to reduce the size of build artifacts by about 60%

Feel free to tell the peanut gallery (me) why I'm wrong. :-)

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