Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: Re: [Wireshark-dev] Managing Gitlab Issues

From: Uli Heilmeier <zeugs@xxxxxxxxxxxx>
Date: Fri, 4 Sep 2020 20:29:04 +0200


Am 04.09.2020 um 14:59 schrieb Dario Lombardo <lomato@xxxxxxxxx>:

On Fri, Sep 4, 2020 at 1:12 PM Uli Heilmeier <zeugs@xxxxxxxxxxxx> wrote:
Hi list,

I’ve tried to update the instructions to report an issue (fka bug) in the wiki [1].

There are some things we need to sort out. (Maybe this has already been done on the core list.)

* Do we want to have labels to mark the status of an issue? With Bugzilla we had Confirmed, Incomplete, In Progress etc. I would like to have labels for status additionally to the existing labels.

Personally I don't like this. Labels are best to mark the issues as belonging to a component, a version and so on. I don't see the need to stick with gerrit's model, unless we really like it. Again, personally I liked gerrit's labels, but I won't miss it, and I think that model can be left behind.
 

I'm sorry I was unclear. I’m talking about the Status field of Bugzilla. Not Gerrit labels. With Bugzilla a new bug had (normally) the status ‚Unconfirmed‘ at the beginning. When someone was able to reproduce the issue the bug had the status ‚Confirmed‘. If something was missing (a capture file for example) the status was ‚Incomplete‘. When someone was working on a fix the status was ‚In Progress‘.
This is currently missing with Gitlab Issues. There is only ‚Open‘ and ‚Closed‘.

Therefore I suggest we use labels to mark the status of an issue.


* Who should be able to edit issues (e.g. adding labels)? According to Gitlab documentation [2] the Reporter role can do it. However the Reporter role also allows to see issues which are marked as confidentially.

I'm not sure I got your point. Just a few people (not including the whole core-dev group) have internal access to the project. Just Gerald and a few have. Other code-devs are in a group allowed to merge, but they're not project members. How would you leverage the confidentiality feature?

With Bugzilla I (as a normal contributor) was able to set the status of a bug (not limited to my own created ones). Also I was able to correct the classification etc. At the moment I’m not able to do this with Gitlab issues. When we can have a new group to edit/label issues I’m totally fine. 

 

* It would make sense to have templates for issues [3]. Has anyone already prepared this? Otherwise I will create one and submit a MR?

This would help for sure. Please submit a MR for that.

Will do so.