Gitlab experiment wrapup

Gabriel Ivăncescu gabrielopcode at gmail.com
Thu Jun 16 11:04:07 CDT 2022


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.



More information about the wine-devel mailing list