08:18 <sergi> venemo: Last days and weeks we are assigning to Marge in waves. We can see those waves in https://ci-stats-grafana.freedesktop.org/d/n7guL8ySz/from-marge-to-merge?orgId=1&from=now-7d&to=now-1m. How much time, we need to wait to have something merged? (mean, std and more coming soon) We like to dive deep in statistics to see patterns and address improvements for specific cases. Also, know in which position one is in the Marge's queue. Besides

08:18 <sergi> that, the marge pipeline time is an important value to improve resources' utilization for all of us.

10:10 <Venemo> sergi: I was just trying to bring attention to a bug

10:57 <sergi> Venemo: I'm not catching what bug you mean. Is it because it was needed to assign it to Marge 6 times? I understand this is annoying, and a waste of resources each time we have to restart it again. We actively investigate what's the root cause when episodes like that one happen. We are currently following a clue. Thanks reporting.

10:57 <Venemo> no, I'm not talking about that

10:58 <Venemo> the bug is that on one occasion the MR was not picked up by marge bot until the author force pushed the MR again

10:59 <Venemo> assigning to marge bot several times is kind of normal for large MRs, so I'm not complaining about that this time

11:10 <karolherbst> sergi: one issue with marge is, that running pipelines aren't aborted once marge moved on to the next MR, and if it means runners aren't made available for newer pipelines, marge won't be able to merge the new one as well

11:10 <karolherbst> solving that will probably already help a lot

12:34 <sergi> Venemo: I'll check the execution, but I have not clear which of those attempts

12:38 <Venemo> sergi: the one which happened around the time when I wrote on this channel

12:39 <sergi> karolherbst: There is a long debate about what to do when Marge drops the MR because of the timeout. We didn't change the behavior because we didn't find consensus. The marge pipeline can finish later and provide information to the developer or CI people about what is happening. Then perhaps cancel what hasn't started yet, or cancel also what's running.

12:39 <sergi> It's true that it is running with Marge privileges, as well as it is using resources probably required for the next MR in the queue. But (I think) the current resources' issue is not produced by that.

12:40 <karolherbst> my take is mostly that debating won't get any results and trying is worth more then block based on theoretical problems/benefits

12:40 <sergi> Venomo: thanks. I'm going to check what was running here and there by that time

12:41 <karolherbst> I ran into issues in the past where a job started like after the pipeline timedout, because the runner was busy

12:41 <karolherbst> it's not like this isn't an issue in itself, though it might not matter much in the bigger picture

12:41 <karolherbst> I don't know, I just know that this is an issue, just not sure if relevant or not

12:42 <karolherbst> worst case it's getting rolled back, but at least we'll know

13:40 <MrCooper> "based on theoretical problems/benefits" is a double-edged sword, it works against your proposal as well :)

14:39 <bl4ckb0ne> I keep getting "Manual Step encountered with run-manual-jobs set to False" on a MR when trying to assign to marge https://gitlab.freedesktop.org/monado/monado/-/merge_requests/2402

14:39 <bl4ckb0ne> is this an issue or a setting missconfigured on the contrib side/

15:57 <pq> I don't think "follow"ing a user in gitlab sends email notifications of their posts, does it?

16:06 <pq> I cannot find any mention that "Follow" would actually do anything.

16:11 <karolherbst> MrCooper: it doesn't. I'm saying we shouldn't make decisions against trying something out, because of theoretical arguments. I don't know if it helps or not, but we will know when it's tried out

16:39 <tpalli> radv-raven-traces-restricted keeps failing in mesa ci: https://gitlab.freedesktop.org/mesa/mesa/-/jobs/70005444

16:42 <tpalli> a630 traces has some ongoing issues as well: https://gitlab.freedesktop.org/mesa/mesa/-/jobs/70005445

17:00 <zmike> I just commented on an issue, but I'm not sure why that restricted traces job is required while others are optional

17:00 <zmike> we should have a consistent policy on that

22:33 <DavidHeidelberg> zmike: see test-source-dep.yml and .restricted-rules

22:33 <DavidHeidelberg> it SHOULD be pretty consistent, if it works still as intended.. no idea

22:34 <DavidHeidelberg> ok, it looks pretty unrelated, "Error: error 403: b''"