Re: [Wireshark-dev] Status label for issues
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}
>
> into a comment and saving the comment).
Yes, I'm aware of it. This is something I've already mentioned in my first
mail. For this label only automation (bot)
makes sense. As long as there is no automation we will have a closed issue with
a false state.
For the Gitlab API there is no difference between manually closed issued and
issues marked as duplicate.
Both have the state closed. Marked as duplicate issues have a additional note
with text "marked this issue as a
duplicate of #iid".
___
Sent via:Wireshark-dev mailing list
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Status label for issues
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-status::in-progress => This bug is not yet resolved, but is assigned to
> the proper person who is working on the bug.
> ws-status::invalid => The problem described is not a bug or not our bug.
> ws-status::wontfix => The problem described is a bug which will never be
> fixed.
> ws-status::fixed => A fix for this bug is checked into master branch.
> 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}
into a comment and saving the comment).
___
Sent via:Wireshark-dev mailing list
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Status label for issues
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 tooling I will have a closer look at triage-ops the next days. Am 27.04.21 um 09:06 schrieb Roland Knall: > > 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 project with no > additional tooling to properly transition between e.g. unconfirmed => > confirmed => in-progress. > > That is my main concern. ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Status label for issues
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::windows, os::macos, os::linux and os::other
should be enough.
Currently we have os::unix with the description "AIX, HP-UX, Solaris, and other
Unices"
___
Sent via:Wireshark-dev mailing list
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Status label for issues
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 project with no additional tooling to properly transition between e.g. unconfirmed => confirmed => in-progress. That is my main concern. Am Di., 27. Apr. 2021 um 08:44 Uhr schrieb 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 > + version::outdated > + ws-status::unconfirmed > + ws-status::confirmed > + ws-status::waiting-for-response > + ws-status::in-progress > + ws-status::invalid > + ws-status::wontfix > + ws-status::fixed > + ws-status::duplicate > > I have no strong feelings about the os::* labels. We can reduce them to > os::mac, os::windows, os::linux, os::unix. > > > Am 26.04.21 um 23:13 schrieb 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 the list > > > > cheers > > Roladn > ___ > Sent via:Wireshark-dev mailing list > Archives:https://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev > mailto:wireshark-dev-requ...@wireshark.org > ?subject=unsubscribe ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Status label for issues
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;
2) is eligible to use the UNIX(R) trademark;
3) other?
If it's 1), then I *guess* Linux is the only UN*X that doesn't fit into that
category, although macOS, being a 4.4-Lite derivative, would fit into that
category as well.
If it's 2), then 1) the *BSDs don't count and 2) at least one Linux
distribution *does* count (EulerOS).
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.
___
Sent via:Wireshark-dev mailing list
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Status label for issues
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 + version::outdated + ws-status::unconfirmed + ws-status::confirmed + ws-status::waiting-for-response + ws-status::in-progress + ws-status::invalid + ws-status::wontfix + ws-status::fixed + ws-status::duplicate I have no strong feelings about the os::* labels. We can reduce them to os::mac, os::windows, os::linux, os::unix. Am 26.04.21 um 23:13 schrieb 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 the list > > cheers > Roladn ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Status label for issues
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 the list cheers Roladn Am Mo., 26. Apr. 2021 um 21:17 Uhr schrieb 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. > ___ > Sent via:Wireshark-dev mailing list > Archives:https://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev > mailto:wireshark-dev-requ...@wireshark.org > ?subject=unsubscribe ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Status label for issues
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 and close it. About old issues, I hope they won't be closed too "fast" as they are one of my playgrounds ( https://gitlab.com/wireshark/wireshark/-/issues/6683 for example ). I understand you are speaking about issues needing requester information, and hopefully it won't catch legitimate ones. E.A. Le lun. 26 avr. 2021 à 21:17, Uli Heilmeier a écrit : > > > > 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. > ___ > Sent via:Wireshark-dev mailing list > Archives:https://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev > mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Status label for issues
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. ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Status label 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 issue is opened for years with no > reaction, it is useless and should be closed. Yes, I fully agree. Great idea. ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Status label for issues
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 create a wiki page for that discussion first, and if we can figure that out create the labels. Also, I would limit the number of labels to as few as possible kind regards Roland Am Sa., 24. Apr. 2021 um 13:33 Uhr schrieb 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 too. > 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 issue is opened for years with no > reaction, it is useless and should be closed. > > Best regards, > > Jirka > ___ > Sent via:Wireshark-dev mailing list > Archives:https://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev > mailto:wireshark-dev-requ...@wireshark.org > ?subject=unsubscribe ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Status label for issues
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 too. 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 issue is opened for years with no reaction, it is useless and should be closed. Best regards, Jirka ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Status label for issues
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. > > > @Uli, LGTM. > > Cheers, > Pascal. > > > > > 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 [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-status::in-progress => This bug is not yet resolved, but is assigned > to the proper person who is working on the bug. > >> ws-status::invalid => The problem described is not a bug or not our bug. > >> ws-status::wontfix => The problem described is a bug which will never > be fixed. > >> ws-status::fixed => A fix for this bug is checked into master branch. > >> ws-status::duplicate => The problem is a duplicate of an existing issue. > >> > >> Scoped labels are mutually exclusive. > >> > >> Setting the label requires manual interaction. So yes, this label won't > reflect the real state when the issue is closed > >> automatically (for example when a MR referencing this issue is merged > or when the issue is marked as an duplicate). > >> > >> Furthermore a normal user is not allowed to set labels at the moment. > Having the label in the issue template won't add > >> the label when opening an issue. > >> > >> Maybe we need another bot (like triage-ops [2]) to set labels > automatically. > >> Does anyone have experience with triage-ops bot (or any other bot > managing issues) and Gitlab and can share some insides? > >> > >> Any objections? Comments are very welcome. > >> > >> Cheers > >> Uli > >> > >> [1]: > https://docs.gitlab.com/ee/user/project/labels.html#workflows-with-scoped-labels > >> [2]: https://gitlab.com/gitlab-org/quality/triage-ops > >> > ___ > >> Sent via:Wireshark-dev mailing list > >> Archives:https://www.wireshark.org/lists/wireshark-dev > >> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev > >> mailto:wireshark-dev-requ...@wireshark.org > ?subject=unsubscribe > > > > > > -- > > Graham Bloice > > -- Graham Bloice ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Status label for issues
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 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-status::confirmed => This bug is valid. >> ws-status::in-progress => This bug is not yet resolved, but is assigned to >> the proper person who is working on the bug. >> ws-status::invalid => The problem described is not a bug or not our bug. >> ws-status::wontfix => The problem described is a bug which will never be >> fixed. >> ws-status::fixed => A fix for this bug is checked into master branch. >> ws-status::duplicate => The problem is a duplicate of an existing issue. >> >> Scoped labels are mutually exclusive. >> >> Setting the label requires manual interaction. So yes, this label won't >> reflect the real state when the issue is closed >> automatically (for example when a MR referencing this issue is merged or >> when the issue is marked as an duplicate). >> >> Furthermore a normal user is not allowed to set labels at the moment. Having >> the label in the issue template won't add >> the label when opening an issue. >> >> Maybe we need another bot (like triage-ops [2]) to set labels automatically. >> Does anyone have experience with triage-ops bot (or any other bot managing >> issues) and Gitlab and can share some insides? >> >> Any objections? Comments are very welcome. >> >> Cheers >> Uli >> >> [1]: >> https://docs.gitlab.com/ee/user/project/labels.html#workflows-with-scoped-labels >> [2]: https://gitlab.com/gitlab-org/quality/triage-ops >> ___ >> Sent via: Wireshark-dev mailing list >> Archives: https://www.wireshark.org/lists/wireshark-dev >> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev >> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe > > > -- > Graham Bloice > ___ > Sent via: Wireshark-dev mailing list > Archives: https://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev > mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Status label for issues
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 [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-status::in-progress => This bug is not yet resolved, but is assigned to > the proper person who is working on the bug. > ws-status::invalid => The problem described is not a bug or not our bug. > ws-status::wontfix => The problem described is a bug which will never be > fixed. > ws-status::fixed => A fix for this bug is checked into master branch. > ws-status::duplicate => The problem is a duplicate of an existing issue. > > Scoped labels are mutually exclusive. > > Setting the label requires manual interaction. So yes, this label won't > reflect the real state when the issue is closed > automatically (for example when a MR referencing this issue is merged or > when the issue is marked as an duplicate). > > Furthermore a normal user is not allowed to set labels at the moment. > Having the label in the issue template won't add > the label when opening an issue. > > Maybe we need another bot (like triage-ops [2]) to set labels > automatically. > Does anyone have experience with triage-ops bot (or any other bot managing > issues) and Gitlab and can share some insides? > > Any objections? Comments are very welcome. > > Cheers > Uli > > [1]: > https://docs.gitlab.com/ee/user/project/labels.html#workflows-with-scoped-labels > [2]: https://gitlab.com/gitlab-org/quality/triage-ops > ___ > Sent via:Wireshark-dev mailing list > Archives:https://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev > mailto:wireshark-dev-requ...@wireshark.org > ?subject=unsubscribe -- Graham Bloice ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
