On 15/06/2022 01:16, Zebediah Figura wrote:
On 6/14/22 15:29, Gabriel Ivăncescu wrote:
Hi,
On 14/06/2022 13:55, Alexandre Julliard wrote:
- Some other things I like:
- Updating status doesn't need to go through me, people can assign
reviewers, supersede patches, etc. directly. That reduces my workload and improves the bus factor. Once we have figured out how to make testbot results reliable, we could also have maintainers merge commits directly.
I created my first MR since the switch seems inevitable. I completely fail at assigning a reviewer. I even tried the web UI and I can't find any setting.
I also tried the /assign_reviewer "quick action" on a comment and it said:
`Could not apply assign_reviewer command.`
Is this feature not working currently?
FWIW, there's a "lab" command line tool that lets you do
lab mr edit --assign <username>
and also
lab mr edit --review <username>
and I'm sure the "glab" has something with identical syntax.
Not sure what the difference between those are, though?
Thanks. These tools make it a lot more bearable.
Also I think "assign" is for someone who's working on the code (for example when a reviewer actually got to it, or when you're refactoring code based on reviews and taking a while). But can't say for sure.
There's one other (pretty big, for me) problem I can't seem to find how to replicate with MRs compared to sending patches: how do I add notes for each commit that shouldn't actually be committed? For patches I used to add below the --- line, and these are super useful when you just want to tell the information to the reviewer, which wouldn't make much sense to have in the codebase itself.
These seem to get lost when I push. I have to admit `git notes` seems pretty convoluted to me and I've no idea how it gets "stored" especially for merge requests. Patches were much easier to comprehend.
I mean, I guess I can add it to the MR description but that's not pointing out to a specific commit/patch... sigh.