> On 21 Jan 2022, at 01:05, Barry Smith <bsm...@petsc.dev> wrote: > > 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. > > 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.
At least in my experience reviewing large (by diffstat measures) in the browser (I use Safari) is nigh-on unusable since the web interface grinds to a halt, and has various other bugs. Of course one should aim for small code changes that are easy to review, but often a small code change will produce large changes in the test output files (which have to appear in the MR, or else one merges broken code). Some examples, if I go to one of Jacob's recent cleanup MRs: https://gitlab.com/petsc/petsc/-/merge_requests/4700/diffs Dragging the scroll bar is very laggy (I guess there's some background thread trying to load things from somewhere?). Semi-randomly, if I click to add a comment on a change, the page jumps back to the start and I lose my place. This seems slightly better in Brave (Chromium). I don't know enough about how the web interface/database integration works, but grinding to a halt on a 6000 line diff is unfortunate. Lawrence
