Re: Migrating to the gitlab issue tracker

[Daniel P . Berrangé]

On Thu, Oct 29, 2020 at 12:01:27PM -0400, John Snow wrote:
> If you're in the CC list, it's because you are listed in MAINTAINERS.
> 
> Paolo's QEMU keynote this morning mentioned the possible use of the Gitlab
> issue tracker instead of using Launchpad.
> 
> I'm quite fond of the gitlab issue tracker, I think it works quite well and
> it has pretty good and uncomplicated API access to it in order to customize
> your workflow if you'd really like to.
> 
> In experimenting with my mirror on gitlab though, I was unable to find a way
> to configure it to send issue tracker notifications to the email list. A
> move to gitlab would likely mean, then:
> 
> 1. The cessation of (automatic) issue tracker mails to the list
> 2. The loss of the ability to update the issue tracker by replying to said
> emails
> 3. Anyone listed in MAINTAINERS would be expected to have a gitlab account
> in order to interact with the issue tracker.
> 
> However, once you have a gitlab account, you DO gain the ability to receive
> emails for issues; possibly only those tagged with labels that you cared
> about -- giving a nice filtering mechanism to receive only bugs you care
> about.

The other thing gained by having a gitlab account is that you can
create a fork of QEMU, and push subsystem trees to the fork. This will
run a load of CI jobs enabling subsystem maintainer to catch many build
problems before sending an email PULL to Peter. This will make it more
likely the PULL will get merged first time without problems, and reduce
the load on Peter letting him do more productive stuff than finding build
failures.

I think we should have an expectation that all PULLs have undergone
GitLab CI testing before being emailed to the list.

NB, GitLab CI doesn't cover every platform combo - there is also
Cirrus CI and Travis. Maintainer can optionally setup accounts on
those too, but I don't think we should seek to require that as it
starts to get a bit more conplex to keep everything sane. Just
focusing on GitLab CI for subsystem maintainers would be a big
enough win on its own I expect.

> Gitlab also does support individual accounts updating issues using a
> generated personalized email address, so if the email workflow is crucial to
> you, it is still available.
> 
> I'm for it, or at least for beginning a pilot program where we experiment
> with the idea for interested parties. I wanted to send up a trial balloon to
> see how we were feeling about this.

The other benefit with using GitLab issues instead of Launchpad is
auto-closing based on comments. A commit message can include a line:

  Closes https://gitlab.com/qemu-project/qemu/-/issues/NNN

When that git commit gets merged to git master in a PULL by Peter, the
GitLab issue will be automatically closed, and it will cross-link to
the commit.

This will eliminate the manual actions that our Launchpad Janitor(s) do
today to close old issues that have been fixed, improving the signal/noise
ratio.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|