Re: [Wireshark-dev] Status label for issues

2021-04-27 Thread Uli Heilmeier
Am 27.04.21 um 09:28 schrieb Guy Harris: >> ws-status::duplicate => The problem is a duplicate of an existing issue. > > The last of those is, well, a duplicate of the "(duplicated)" in the status > box at the top (if the close is done right, by entering > > /duplicate #{bug number} >

Re: [Wireshark-dev] Status label for issues

2021-04-27 Thread Guy Harris
On Apr 23, 2021, at 5:29 AM, Uli Heilmeier wrote: > Therefore I would like to create these scoped labels [1]: > > ws-status::unconfirmed => This bug has recently been added to the issue > tracker. Nobody has confirmed that this bug is > valid. > ws-status::confirmed => This bug is valid. >

Re: [Wireshark-dev] Status label for issues

2021-04-27 Thread Uli Heilmeier
I see your point. We had this status field at Bugzilla and it worked sufficiently well (at least for dissector bugs). At the moment it is very hard to see if someone has already had a look at an issue, if she/he was able to reproduce it, if a sample capture is missing etc. Regarding

Re: [Wireshark-dev] Status label for issues

2021-04-27 Thread Uli Heilmeier
Am 27.04.21 um 09:06 schrieb Guy Harris: > Perhaps the labels should be > > os:windows > os:macos > os:linux > os:other-unix > > ("unix" meaning "Un*X", and "other" meaning "neither macOS nor Linux"). > "os:other" might be enough. Yes, you're totally right.

Re: [Wireshark-dev] Status label for issues

2021-04-27 Thread Roland Knall
It wasn't clear to me, that your list was the original list + new entries. I have especially an issue with the new ws-status labels and their transitions. Judging from a company, where we have about 50 developers whose daily bread it is to transition properly in Jira, I cannot see an open-source

Re: [Wireshark-dev] Status label for issues

2021-04-27 Thread Guy Harris
On Apr 26, 2021, at 11:43 PM, Uli Heilmeier wrote: > I have no strong feelings about the os::* labels. We can reduce them to > os::mac, os::windows, os::linux, os::unix. So does "unix" mean: 1) has some possibly very-remote code base connection to some UNIX that AT put out;

Re: [Wireshark-dev] Status label for issues

2021-04-27 Thread Uli Heilmeier
Diff between current and proposal list: - incident - question - cli::tshark + ui::tshark - ui::gtk - version::0.x - version::1.0 - version::1.10 - version::1.12 - version::1.2 - version::1.4 - version::1.6 - version::1.8 - version::2.0 - version::2.2 - version::2.4 - version::2.6 - version::3.0 +

Re: [Wireshark-dev] Status label for issues

2021-04-26 Thread Roland Knall
The list seems to be duplicated with the lists from above. Anyhow, it seems we just have too many labels already, and I am still not convinced that they can be used properly and consistently at this point I would clean up the proposal list first, then from there figure out which items we need on

Re: [Wireshark-dev] Status label for issues

2021-04-26 Thread Eugène Adell
Hello, "Furthermore a normal user is not allowed to set labels at the moment." That's true. How to request a "close issue" in the proper way ? Unluckily commenting is not always enough to get attention. For example, please anyone have a look at

Re: [Wireshark-dev] Status label for issues

2021-04-26 Thread Uli Heilmeier
Am 26.04.21 um 11:49 schrieb Roland Knall: > > I suggest we create a wiki page for that discussion first, and if we can > figure that out create the labels.  > I've created https://gitlab.com/wireshark/wireshark/-/wikis/Discussion-Issues-Labels to discuss labels for issues.

Re: [Wireshark-dev] Status label for issues

2021-04-26 Thread Uli Heilmeier
Am 24.04.21 um 13:31 schrieb Jirka Novak: > I propose one more kind of label/labels. It is more about interaction > with reporter of the issue - "waiting for response". There are many > issues opened for years where last message is request for sample or more > information. I think that if such

Re: [Wireshark-dev] Status label for issues

2021-04-26 Thread Roland Knall
I somewhat feel a little bit more sceptical of increasing the numbers of labels. They would require discipline before being enforceable. Also, we would need some form of documentation to allow a lookup what each label is supposed to be and what eventual escalation procedures would be. I suggest

Re: [Wireshark-dev] Status label for issues

2021-04-24 Thread Jirka Novak
Hi Uli, > For issues (especially bugs) I really miss the status field which was > available with Bugzilla. > > Therefore I would like to create these scoped labels [1]: > ... > > Any objections? Comments are very welcome. I agree with you. I'm missing this information about created issues

Re: [Wireshark-dev] Status label for issues

2021-04-23 Thread Graham Bloice
On Fri, 23 Apr 2021 at 15:43, Pascal Quantin wrote: > Hi Graham, > > 23 avr. 2021 16:39:16 Graham Bloice : > > > How will issues that aren't bugs be handled, e.g. enhancement requests? > > We already have an enhancement label. > Ah, I thought this was some different label, sorry for the noise.

Re: [Wireshark-dev] Status label for issues

2021-04-23 Thread Pascal Quantin
Hi Graham, 23 avr. 2021 16:39:16 Graham Bloice : > How will issues that aren't bugs be handled, e.g. enhancement requests? We already have an enhancement label. @Uli, LGTM. Cheers, Pascal. > > On Fri, 23 Apr 2021 at 13:30, Uli Heilmeier wrote: >> Hi everyone, >> >> For issues (especially

Re: [Wireshark-dev] Status label for issues

2021-04-23 Thread Graham Bloice
How will issues that aren't bugs be handled, e.g. enhancement requests? On Fri, 23 Apr 2021 at 13:30, Uli Heilmeier wrote: > Hi everyone, > > For issues (especially bugs) I really miss the status field which was > available with Bugzilla. > > Therefore I would like to create these scoped labels

[Wireshark-dev] Status label for issues

2021-04-23 Thread Uli Heilmeier
Hi everyone, For issues (especially bugs) I really miss the status field which was available with Bugzilla. Therefore I would like to create these scoped labels [1]: ws-status::unconfirmed => This bug has recently been added to the issue tracker. Nobody has confirmed that this bug is valid.