daniels changed the topic of #freedesktop to: https://www.freedesktop.org infrastructure and online services || for questions about freedesktop.org projects, please see each project's contact || for discussions about specifications, please use https://gitlab.freedesktop.org/xdg or xdg@lists.freedesktop.org
mripard has quit [Remote host closed the connection]
mripard has joined #freedesktop
lsd|2 has joined #freedesktop
zzag_ has quit []
zzag has joined #freedesktop
unrznbl[m] has joined #freedesktop
thaytan has quit [Ping timeout: 480 seconds]
thaytan has joined #freedesktop
<pq>
I did a review in Gitlab, recording 38 comments before writing the final summary comment and clicking "submit review". It seemed to stall for a long time, and after 10 minutes, 36 new unresolved threads were created, meaning 2 are missing, the final comment is missing, and I see some comments on already open threads still pending. The MR page still says I have 38 pending comments.
<pq>
Any suggestions how to get the rest of the comment out without creating 36 duplicates?
<pq>
hmm, if I navigate to a commit in the MR, I can see duplicates: one sent and one pending.
<pq>
maybe I need to manually delete the duplicate pending ones
<jani>
is there a way to prevent folks with gitlab developer access to push random new branches in the repo?
<jani>
all my google searches end up in documentation about protected branches, but that's irrelevant
<emersion>
you can create a rule '*' with push forbidden
<jani>
Add branch rule. To create a branch rule, you first need to create a protected branch. After a protected branch is created, it will show up in the list as a branch rule.
<jani>
^ that's what it says when I try to add a rule
bmodem has quit [Ping timeout: 480 seconds]
Ford_Prefect has quit [autokilled: Possible spambot. Mail support@oftc.net if you think this is in error. (2023-11-07 15:25:44)]
<MrCooper>
pq: FWIW, the review feature also breaks threading of notification e-mails
<pq>
sure
<pq>
I find I often need to go back to my earlier comments and correct them when progressing with a review.
<MrCooper>
it would be a nice feature without the flaws
<pq>
I also think about how does the constributor know when I'm done reviewing, if I need to trickle comments over days, or like here, over weeks.
<pq>
*contributor
<MrCooper>
is it really worth holding back comments for weeks though?
<MrCooper>
could add a comment saying you're done with a review pass
<pq>
It's not.
<pq>
But it is common for a review of a big MR to take days. Not weeks.
<MrCooper>
even so, others could see some comments days earlier
<pq>
Right, and if they then address those and push changes, we're out of sync. I'm still going through the old revision, or I need to start from scratch, and my comments may have gone in a direction I don't want after all, so lots of effort wasted on both sides.