[Intel-gfx] [Mesa-dev] gitlab.fd.o financial situation and impact on services
robdclark at gmail.com
Fri Feb 28 17:00:29 UTC 2020
On Fri, Feb 28, 2020 at 3:43 AM Michel Dänzer <michel at 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.
(Not sure how much that would help reduce bandwidth costs, but I guess
it should help a bit.)
More information about the gstreamer-devel