[11:18:28] 10GitLab: Implement a bot which subscribes/mentions multiple reviewers for merge requests - https://phabricator.wikimedia.org/T365350 (10TheresNoTime) 03NEW [12:29:24] 10GitLab: Implement a bot which subscribes/mentions multiple reviewers for merge requests - https://phabricator.wikimedia.org/T365350#9812319 (10Peachey88) Have we raised this limitation #gitlab-upstream to see if its something they potentially want to work on and improve? [13:01:59] 10GitLab: Implement a bot which subscribes/mentions multiple reviewers for merge requests - https://phabricator.wikimedia.org/T365350#9812402 (10Aklapper) Likely - googling for `gitlab "multiple reviewers"` lists https://gitlab.com/gitlab-org/gitlab-foss/-/issues/32943 as the second result for me :) [13:02:04] 10GitLab (Upstream pit of despair 🕳️): Implement a bot which subscribes/mentions multiple reviewers for merge requests - https://phabricator.wikimedia.org/T365350#9812403 (10Aklapper) [16:14:28] 10GitLab (Account Approval), 06Release-Engineering-Team: Requesting GitLab account activation for Ionenlaser - https://phabricator.wikimedia.org/T365333#9813014 (10bd808) 05Open→03Resolved a:03glaab https://gitlab.wikimedia.org/ionenlaser Looks like https://wikitech.wikimedia.org/wiki/Tool:Gitlab-ac... [16:22:46] 10GitLab (Upstream pit of despair 🕳️): Implement a bot which subscribes/mentions multiple reviewers for merge requests - https://phabricator.wikimedia.org/T365350#9813062 (10brennen) > Have we raised this limitation GitLab (Upstream pit of despair 🕳️) to see if its something they potentially want to work on and... [16:56:53] brennen: heh. I didn't notice that you had said mostly the same thing at T365350. I had the edit form open for a while as I double checked the old Diffusion syntax for adding reviewers with a commit message. [16:56:54] T365350: Implement a bot which subscribes/mentions multiple reviewers for merge requests - https://phabricator.wikimedia.org/T365350 [16:57:27] bd808_: glad to have my take confirmed there, anyhow. :) [16:58:40] the other option not mentioned on this task is just tweaking the code that toggles the feature off in the community edition, which i believe dduvall discovered at one point is a one-line change, since they were too lazy to actually yank it out of the CE code. [16:58:51] it wouldn't be a license violation or anything. [16:59:24] it would, however, be a pain in the ass to actually do, and they might always decide to yank it in future, so i think a workaround is probably more sustainable. [16:59:39] hmmm... they just put the feature flag in CE codebase? wacky [17:00:15] brennen: here's another question: if folks literally use `Reviewers: @bd08, @brennen` in the MR description then isn't that the ping? [17:00:32] that... is a good point. [17:00:35] * bd808 can't type his own username apparently [17:01:38] i forget, do generic comments on the MR need resolved? [17:01:52] (or can they be made to?) [17:02:58] "[] All threads must be resolved" is the label in -/settings/merge_requests [17:03:31] which I think does mean all and not just formal reviews [17:03:41] * brennen spends a remarkable amount of time trying to get the menu to not flicker out of existence for long enough to click on the settings [17:04:01] yeah... that UX is really bad in my browser [17:04:13] i guess that would at least be an option for people to enable, and might kind of make the extra comment ping make sense [17:06:41] i also wonder what we could do to make finding the stuff you haven't reviewed easy. is there a way to append to a user's todo list, for example? (or maybe unresolved conversations go on that list?) [17:07:59] huh, sidebar: i just noticed you can change the template for squashed commits [17:08:00] https://gitlab.wikimedia.org/help/user/project/merge_requests/commit_templates [17:08:52] bd808: yerp https://gitlab.com/gitlab-org/gitlab/-/blob/f50e99701f84ac45ed9daac4a258aebf63b64dd5/app/models/project.rb?page=4#L3278 [17:08:54] i think maybe we should edit that for everything to add %{all_commits}, because it's infuriating to have one or more well-written commit messages that just get obliterated because gitlab thinks that really it should just be the title of the MR or whatever. [17:10:52] brennen: that sounds like a good idea to me. [17:12:53] I have #feelings about squash and merge commits generally being undesirable. I do not like the idea of a new commit being invented as part of approving a merge. But for folks who want to use that workflow, it does seems better to pre-populate the message with as much data as possible.