Re: [Mesa-dev] gitlab issue migration, labels & triage
On Tuesday, 2019-10-01 13:30:39 +0300, Denys wrote: > Thanks a lot, works fine. > > Also I would suggest to apply a template for issue creation as we finally > moved most of sub-projects and users started new issues creation at gitlab. Agreed, I started looking into this. I'll post a WIP MR for the discussion, and include your suggestion below. > > Below you may find an a work-in-progress template (parts of it were taken > from DXVK and Mesa web site), which might help us (and users) create > detailed and as full as possible issues from scratch. > > We have an idea to add "Tips" section under the template, which will have > all useful information about additional tools (such an apitrace). This > section should be expandable, so it will not be visible after issue > creation. It is not finished yet, need to adopt instructions and make them > clear for all (if everybody likes this idea, I will finish it) > > So what do you think about this? > > -- > > Please describe your issue as accurately as possible. > Before submitting: > - Check if a new version of Mesa is available which might have fixed the > problem. > - Check if your bug is already reported in the database. > - Fill requested information below > Would be helpful to provide links to specific games/applications lead to the > issue. If possible, provide an apitrace of the application/game (see Tips > section) > > > ### System information > - GPU: > - Kernel version: > - OS: > - Mesa version: > - DXVK/D9VK version (if applicable): > - Wine version (if applicable): > > > ### Apitrace file(s) (if exist) > - Put a link here > > ### Log files (any possible) > - dmesg > - backtrace > - gpu hang details > > ### Screenshots: > > > ### Tips > > - OpenGL: > apitrace trace > For steam games, you have to: > 1. Open game preferences > 2. Open "Set launch options" > 3. Enter => apitrace trace %command% > * After exiting/crashing *.trace will be stored near the application's > binary > > - DX11/DX9: > Ideally would be great to get an apitrace from the Windows OS. > > * If you don't have possibility to make a trace under windows, you still can > do this on linux: > > TO BE CONTINUED > > --- ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] gitlab issue migration, labels & triage
Thanks a lot, works fine. Also I would suggest to apply a template for issue creation as we finally moved most of sub-projects and users started new issues creation at gitlab. Below you may find an a work-in-progress template (parts of it were taken from DXVK and Mesa web site), which might help us (and users) create detailed and as full as possible issues from scratch. We have an idea to add "Tips" section under the template, which will have all useful information about additional tools (such an apitrace). This section should be expandable, so it will not be visible after issue creation. It is not finished yet, need to adopt instructions and make them clear for all (if everybody likes this idea, I will finish it) So what do you think about this? -- Please describe your issue as accurately as possible. Before submitting: - Check if a new version of Mesa is available which might have fixed the problem. - Check if your bug is already reported in the database. - Fill requested information below Would be helpful to provide links to specific games/applications lead to the issue. If possible, provide an apitrace of the application/game (see Tips section) ### System information - GPU: - Kernel version: - OS: - Mesa version: - DXVK/D9VK version (if applicable): - Wine version (if applicable): ### Apitrace file(s) (if exist) - Put a link here ### Log files (any possible) - dmesg - backtrace - gpu hang details ### Screenshots: ### Tips - OpenGL: apitrace trace For steam games, you have to: 1. Open game preferences 2. Open "Set launch options" 3. Enter => apitrace trace %command% * After exiting/crashing *.trace will be stored near the application's binary - DX11/DX9: Ideally would be great to get an apitrace from the Windows OS. * If you don't have possibility to make a trace under windows, you still can do this on linux: TO BE CONTINUED --- On 23.09.19 18:42, Adam Jackson wrote: On Mon, 2019-09-23 at 11:50 +0300, Denys wrote: Hello Adam. I would ask to get a permissions to edit/triage the issues, as we did before in bugzilla. We have a small team working on mesa project (right now intel part mostly), so it would be great to have possibility to sort user issues according to their components. paul.che10...@gmail.com den.kos...@gmail.com I've added these accounts at Reporter level, you should be able to edit issues now. Let me know if anything still isn't working. - ajax ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] gitlab issue migration, labels & triage
On Mon, 2019-09-23 at 11:50 +0300, Denys wrote: > Hello Adam. > I would ask to get a permissions to edit/triage the issues, as we did before > in bugzilla. We have a small team working on mesa project (right now intel > part mostly), so it would be great to have possibility to sort user issues > according to their components. > paul.che10...@gmail.com > den.kos...@gmail.com I've added these accounts at Reporter level, you should be able to edit issues now. Let me know if anything still isn't working. - ajax ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] gitlab issue migration, labels & triage
Hello Adam. I would ask to get a permissions to edit/triage the issues, as we did before in bugzilla. We have a small team working on mesa project (right now intel part mostly), so it would be great to have possibility to sort user issues according to their components. paul.che10...@gmail.com den.kos...@gmail.com Denys. On 19.09.19 19:55, Adam Jackson wrote: On Wed, 2019-09-18 at 23:41 +0200, Bas Nieuwenhuizen wrote: 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? Well, there's the list of issues with no label: https://gitlab.freedesktop.org/mesa/mesa/issues?scope=all=%E2%9C%93=opened_name[]=None We can almost certainly keep that list empty if we're diligent about it. And if there's volunteers sufficiently interested in triage but not necessarily development we can add them with Reporter access. I'm a _little_ surprised issue reporters don't automatically get that... but on the other hand, as Mark Janes pointed out, we're likely to be using labels for quite a lot now, so the ability to delete labels probably should be restricted to Developer and up. - ajax ___ 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
Re: [Mesa-dev] gitlab issue migration, labels & triage
On Wed, 2019-09-18 at 23:41 +0200, Bas Nieuwenhuizen wrote: > 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? Well, there's the list of issues with no label: https://gitlab.freedesktop.org/mesa/mesa/issues?scope=all=%E2%9C%93=opened_name[]=None We can almost certainly keep that list empty if we're diligent about it. And if there's volunteers sufficiently interested in triage but not necessarily development we can add them with Reporter access. I'm a _little_ surprised issue reporters don't automatically get that... but on the other hand, as Mark Janes pointed out, we're likely to be using labels for quite a lot now, so the ability to delete labels probably should be restricted to Developer and up. - ajax ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] gitlab issue migration, labels & triage
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
Re: [Mesa-dev] gitlab issue migration, labels & triage
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
[Mesa-dev] gitlab issue migration, labels & triage
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
