<div dir="ltr"><div>Very much agreed that the biggest sort of friction is dealing with MRs from forks. I suspect that the reason many of the things we want don't work is because they would be too dangerous to allow a random, possibly malicious, user to do. E.g. setting labels seems innocuous enough, but all kinds of workflows, including automated ones, could be based on them. A more likely problem in our case is that someone could open an MR with "workflow::Ready-to-Merge" because they guess that it means that from their perspective it's ready (when to us it means more than that). It would be easy for that to get merged before being reviewed. <br></div><div><br></div><div>So in asking about all this, maybe we should make sure that we understand the privilege levels GitLab offers, as maybe we can address the usual case that the outside person making an MR is a researcher or engineer that one of us knows (of) and so has some degree of trust in, so there would be no huge risk in giving them the ability to change labels etc.<br></div><div><br></div><div>(And my pet peeve is that my "todo list" is still swamped by "X set you as an approver for Y".)<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Am Fr., 21. Jan. 2022 um 06:53 Uhr schrieb Barry Smith <<a href="mailto:bsmith@petsc.dev">bsmith@petsc.dev</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><br><div><br><blockquote type="cite"><div>On Jan 20, 2022, at 10:40 PM, Junchao Zhang <<a href="mailto:junchao.zhang@gmail.com" target="_blank">junchao.zhang@gmail.com</a>> wrote:</div><br><div><div dir="ltr"><div>*  Email notification when one is mentioned or added as a reviewer</div></div></div></blockquote><div><br></div>   Hmm, I get emails on these? I don't get email saying I am code owner for a MR</div><div><br><blockquote type="cite"><div><div dir="ltr"><div>*  Color text in comment box</div><div>*  Click a failed job, run the job with the <b>updated</b> branch</div><div>*  Allow one to reorder commits (e.g., the fix up commits generated from applying comments) and mark commits that should be fixed up</div><div>*  Easily retarget a branch, e.g., from main to release (currently I have to checkout to local machine, do rebase, then push)   </div><div><br></div><div><div dir="ltr"><div dir="ltr">--Junchao Zhang</div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jan 20, 2022 at 7:05 PM Barry Smith <<a href="mailto:bsmith@petsc.dev" target="_blank">bsmith@petsc.dev</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
  I got asked to go over some of my Gitlab workflow uses next week with some Gitlab developers; they do this to understand how Gitlab is used, how it can be improved etc. <br>
<br>
  If anyone has ideas on topics I should hit, let me know. I will hit them on the brokenness of appropriate code-owners not being automatically added to reviewers. And support for people outside of the Petsc group to set more things when they make MRs. And being to easily add non-PETSc folks as reviewers.<br>
<br>
  Barry<br>
<br>
</blockquote></div>
</div></blockquote></div><br></div></blockquote></div>