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
[Wireshark-dev] Status label for issues
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