Re: GitLab postmortem

On Wed, 2018-12-19 at 14:37 +0000, Philip Withnall wrote:
On Tue, 2018-12-11 at 14:22 +0100, Carlos Soriano wrote:

It has been a few months since we moved to GitLab. Apart of spurious issues, specific annoyances and frustrations, seems it has been generally good. I would like to gather some general feeling about it. Things that really made a constant impact to you and your work, both bad or good. Feel free to provide feedback about the transition or the administration of GitLab instance too. Free form.

It’s all been pretty excellent. I can’t fault the transition or the effort that people have put into it.

A few larger annoyances about GitLab, having now worked with it for a while:

1. Being able to draft review comments and submit them all at once would reduce e-mail overload on people, and make it easier to draft coherent code reviews. I quite like how GitHub does this (although I dislike most other things about GitHub).

2. Hiding the diff of a large file when it’s the only file changed in an MR is not helpful. I should file a bug about this.

3. I’d like to see continued movement towards disallowing direct pushes to git, and requiring all commits to go through MRs (and CI). I think the remaining barrier to this is the translation workflow/Damned Lies. It would be good to get Damned Lies to create MRs with submitted translation changes, so that it doesn’t need direct push access to git, and so that translators don’t have to faff with MRs themselves.

4. Starting to type while the tag popover is loading will still execute global hotkeys, which normally refreshes the page or does something unexpected. I should file a bug about this too.

5. Changing branches when creating an MR loses your title/description/tags, and since the branch drop-down is quite far down the form, I often forget to do that first before filling out the title/description/tags. This makes backports a bit more annoying. I should file a bug about this too.

6. GitHub recently acquired a way to suggest minor one-line changes to MRs, and allow the MR author to press a button to accept them. This would be really good for minor typo fixes and cleanups. It would be less intrusive than having to write a nitpick comment for each one and making the MR author really bored or frustrated with the review.

7. The ability for a maintainer to push fixups to an old MR, or rerun failed CI pipelines on it, so that we don’t have to clone MRs to resurrect ones where the original author has wandered off; and people don’t have to remember to tick the “allow others to push to my branch” tickbox when creating an MR to allow the CI pipelines to be retried.


Attachment: signature.asc
Description: This is a digitally signed message part

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]