During playing with notifications, I found out that actually gitlab
allows to subscribe to exact labels
https://about.gitlab.com/2016/04/13/feature-highlight-subscribe-to-label/
So, this may sort part of the issues related to "be up-to-date"
according to interesting things in the big project. So as soon as
somebody puts a label "RADV", for example, you will get a notification
about it.
And short "testing" of this feature from me:
1. Mark "Global" notifications level as "Disabled" (to be sure you won't
get spam, for example)
2. Subscribe to any label
3. Create an issue WITH label
You will get a notification about issue creation
4. Create an issue WITHOUT label and then - edit issue and add label
You will get a notification about adding a label to the issue.
So with this it might be quite flexible.
On 19.09.19 10:41, Denys wrote:
That's sad fact of gitlab, agree. The only thing came into mind - to
get a "template" for issue, which should include all important
information in the Summary
(example - Intel. Vulkan. GPU hand during playing dota ...)
There are many better ways to do this, for example, simply make a map
of all needed labels, to be put into the summary. And then somebody
with "edit" permissions will add correct labels according to the summary.
So current approach will sort the problem 1 and 2.
Issue 3 also can be workaround with it, because you may make filters
based on "key words" in summary.
On 19.09.19 00:41, Bas Nieuwenhuizen wrote:
Hi all,
One things I realized during the migration is that end users generally
cannot edit labels on an issue[1] and there is no component selection
anymore.
So we end up with a bunch of changes:
1) Bugs come in without labels
2) People are not consistently fixing up labels for issues
3) Labels are not sent in email updates, prompting some IRC talk of
adding the component in the titles already to make email filters work.
While having email filtering work completely would be awesome I think
my biggest issue here "ownership". When a bug came into the radv
bugzilla component I took some ownership of managing it. e.g. bugs
with a wrong component get moved, taking an initial stab at a fix etc.
My fear would be that we don't consistently triage new bugs and that a
number of them don't end up on anyone's radar. Contrary to MRs, where
I expected most of them to be made by long-time developers, bugs tend
to be filed by people who are not really affiliated with mesa and I
feel the effect is probably stronger.
Has anybody put any though in how to best manage things here? e.g.
some process, or do we want some form of automatic labeling, or is my
concern overblown?
- Bas
[1] https://docs.gitlab.com/ee/user/permissions.html
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
