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}
>
>
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.
> ws-s
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 additional
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. os::windo
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 p
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&T put out;
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
+
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 t
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
https://gitlab.com/wireshark/wireshark/-/issues/7580
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.
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
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 we
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 to
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.
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 bug
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
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.
ws
17 matches
Mail list logo
