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
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
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&utf8=%E2%9C%93&state=opened&label_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
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] [ANNOUNCE] mesa 20.0.5
Hello. As we discussed this with @Danylo, milestones may help developers to be aware, that their patches were/will be nominated to the next release. They will get notification about this and (according to our expectations) will review these patches. It is ideal case, for sure, but this will prevent such cases as we got recently (when regression was found and fixed ASAP, but without any clue that this fix will not be a part of the release scope). The labels "bisected" and "regression" serve as a good indicator of bugs that should block release, assuming someone has by chance applied the labels correctly. As I have access to these labels, that's not a big deal to add not only them, but and mark these issues for the future milestone. A bit more complicated will be to decide, which issues should be added except `regressed`. Aslo, @Mark, in your last reply I saw that you asked about "parsing" merge-requests and comments/issues. If I understood the problem correctly, you may try my approach. I am using Thunderbird, and created 2 filters for pattern "Subject contains" (doesn't work directly in Gmail filters...) : 1. (# =>>> this one is parsing Issues and Comments 2. (! =>>> this one is parsing Merge requests only On the top of this, I applied filter in Gmail, which is filtering all gitlab activity. And the last thing, as idea - as we know, LunarG and steam/proton team have own Ci with lots of traces, and they run them on latest released mesa version. As a result, they are reporting us with "hot" issues in production - https://gitlab.freedesktop.org/mesa/mesa/-/issues/2823 It would be great to contact them and ask for setting up one more instance - which will test our "stable" branch. In this case we will get regressions faster and may avoid them in production. On 23.04.20 21:37, Mark Janes wrote: Michel Dänzer writes: On 2020-04-23 6:19 p.m., Mark Janes wrote: Michel Dänzer writes: On 2020-04-23 5:14 p.m., Mark Janes wrote: Does anyone have recommendations for how to use Gitlab to verify that there are no identified-but-unfixed bugs in a pending release? I'd say GitLab milestones could be used to address the issues you raised above: Create a milestone for each release, and only cut the release once all issues and MRs assigned to it have been dealt with. Milestones have been used to track progress toward recent releases. It is non-trivial to audit all open bugs to determine which ones must be assigned to a milestone. Bugs are opened long before milestones are created. Of course there are more complicated cases, but the particular case which spawned this thread should have been pretty straightforward to handle with a 20.0.5 milestone. I do not agree that release milestones are helpful for this category of bugs. The majority of stable point releases will have zero issues in a release milestone. Opening/closing empty milestones all the time is a lot of busy work. Milestones are helpful for *initial* releases of stable branches, not point releases. Even for initial releases important use cases for milestones are not supported by gitlab. As an example, we may be able to verify that a specific test is regressed with an A/B test of the previous release -- and perhaps identify the commit that regressed it. How can we find if an issue exists for this test? You cannot: - search for issues mentioning a test name (unless it is in the title) - search for issues mentioning a commit - subscribe to issue comments in a way that would let you search offline How can we audit new issues for items that have not been triaged since the last release? The only workflow that I can imagine is to sort all issues by "last updated" and read through every open issue changed in the past 3 months. Of course, the list changes as you read through it. I'm contrasting this with Bugzilla, where we could subscribe to bug comments and read through them on a daily basis. At release time, I could have confidence that I had seen all bugs that might affect end users. The labels "bisected" and "regression" serve as a good indicator of bugs that should block release, assuming someone has by chance applied the labels correctly. For point releases, adding a "stable" label may tell us when an issue blocks point releases as well. Any issue related to a commit that CC's stable would get this label. Personally I think this label will not solve the problems either, because it requires careful monitoring of issues to notice regressions which cc stable. The information needed to *automate verification* of stable releases exists, within gitlab and the git log. However, a sane and robust release process cannot be implemented on top of gitlab's pitiful search interface. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing
