On Fri, Feb 28, 2020 at 3:43 AM Michel Dänzer <michel@xxxxxxxxxxx> 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.) BR, -R _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
