Re: GitLab postmortem

2018-12-23 Thread Philip Withnall 
On Wed, 2018-12-19 at 16:48 +, Philip Withnall wrote:
> On Wed, 2018-12-19 at 14:37 +, 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.

Filed https://gitlab.com/gitlab-org/gitlab-ce/issues/55679.

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

Filed https://gitlab.com/gitlab-org/gitlab-ce/issues/55680.

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

Philip


signature.asc
Description: This is a digitally signed message part
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: [GitLab] What 11.6 brings to us

2018-12-23 Thread Nicolas Dufresne 
Le dim. 23 déc. 2018 07 h 36, Carlos Soriano  a écrit :

> 11.6 is here, there are a few nice things for us.
>
> *Run CI/CD for merge requests
> *
> CI are not only for branches, but also for MR. Variables, etc. can be put
> to adjust the CI to do X or Y things on MR or regular branches. This will
> be very handy if we need to go back to only do fast CI for the GNOME group.
>
> *Suggested Changes in MRs
> *
> Provide suggested changes in MRs and apply them at merge. This was raised
> in the postmortem email by a few people, so try it out and let me know how
> it works for you. AFAIK the implementation is similar to the one in GitHub.
>
> *Similar issues suggestions when filing a new issue
> *
> Duplicate issues handling was one of the top priorities for us, so GitLab
> has requested our feedback for this new feature. So please try it out and
> let me/them know how does it work for you.
>
> Cheers!
>

Let's hope we can change their mind on keeping code review comment batching
a paid feature. It makes gitlab looks bad by spamming patch submitters on
long reviews.


___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

[GitLab] What 11.6 brings to us

2018-12-23 Thread Carlos Soriano 
11.6 is here, there are a few nice things for us.

*Run CI/CD for merge requests
*
CI are not only for branches, but also for MR. Variables, etc. can be put
to adjust the CI to do X or Y things on MR or regular branches. This will
be very handy if we need to go back to only do fast CI for the GNOME group.

*Suggested Changes in MRs
*
Provide suggested changes in MRs and apply them at merge. This was raised
in the postmortem email by a few people, so try it out and let me know how
it works for you. AFAIK the implementation is similar to the one in GitHub.

*Similar issues suggestions when filing a new issue
*
Duplicate issues handling was one of the top priorities for us, so GitLab
has requested our feedback for this new feature. So please try it out and
let me/them know how does it work for you.

Cheers!
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list