[Top][All Lists]

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

Re: Migrating to the gitlab issue tracker

From: John Snow
Subject: Re: Migrating to the gitlab issue tracker
Date: Thu, 29 Oct 2020 14:04:04 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.3.1

On 10/29/20 12:41 PM, Cornelia Huck wrote:
On Thu, 29 Oct 2020 12:01:27 -0400
John Snow <jsnow@redhat.com> wrote:

If you're in the CC list, it's because you are listed in MAINTAINERS.

<cleared the cc: list except for qemu-devel :)>

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.

The gitlab issue tracker is almost certainly is an improvement over
launchpad (and I do have a gitlab account); but not being able to
interact via email is at least annoying. I expect that not only
maintainers will want to interact with bug reports?

Nothing stopping reviewers or contributors from signing up and subscribing to labels or issues they care about... It will just be more opaque to the ebb and flow of the list.

There are still perhaps things we could do; a bot that generates weekly bug report summaries might be a solution.

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.

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.

You mean that I can update via email, provided it's an address
associated with my account?


Click the "bell" icon, choose "custom", and you can subscribe to issues project-wide if you'd like. (Reopen, New, Closed, Reassigned).

I started experimenting with using the gitlab issue tracker for my Python library project, I'll use it as an example here:


You can "subscribe" to labels to be notified about tracker activity in just an area of your concern. Here I'm using "Python" and "QMP" labels for areas of concern for this topic area.

When an issue gets tagged with one of your subscribed labels, you'll receive a notification (I get an email) informing you of the new issue.

(Unfortunately, it looks like issues that are triaged to contain your tag after their initial creation only show you the tag change event and not the bug text. It might be the case that subscribing to *all* new bugs, but then subscribing to labels of concern is the way to go.)

You can reply directly to that email, or any update emails, to update the tracker.

Also, you can view your notification settings by going to https://gitlab.com/-/profile/notifications

and you can check out your notification settings per-group, per-project, etc.

Lastly, you can go to the issue tracker for a project e.g. https://gitlab.com/jsnow/qemu/-/issues and at the bottom (If you have permission, I assume?) you can click "Email a new issue to this project." and receive a special email address for you to use to create new issues:

You can create a new issue inside this project by sending an email to the following email address:

The subject will be used as the title of the new issue, and the message will be the description. Quick actions and styling with Markdown are supported.

This is a private email address generated just for you. Anyone who gets ahold of it can create issues or merge requests as if they were you. You should reset it if that ever happens.

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]