GNOME.org
 

Re: GitLab postmortem

On Sun, 2018-12-23 at 17:21 +0000, Philip Withnall wrote:
On Wed, 2018-12-19 at 16:48 +0000, Philip Withnall wrote:
On Wed, 2018-12-19 at 14:37 +0000, Philip Withnall wrote:
On Tue, 2018-12-11 at 14:22 +0100, Carlos Soriano wrote:
Hey,

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:

To follow up on these, I’ve now filed bugs for some of them. See below:

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).

Paid-for feature. ☹

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.

I can’t currently find the MR I saw this with, but will file an issue with GitLab if I see it again. I really should have filed it when I first saw the problem, sorry.

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.

Apparently we just got this with 11.6. Looking forward to trying it out!

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.

There already seems to be an upstream issue about it: https://gitlab.com/gitlab-org/gitlab-ce/issues/55680.

That was a copy/paste error. I actually meant this link for #7: https://gitlab.com/gitlab-org/gitlab-ce/issues/49323

Sorry,
Philip

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]