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''"