Re: [Mesa-dev] [ANNOUNCE] mesa 20.0.5
On 2020-04-24 6:14 p.m., Denys wrote: > > 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 FWIW, e-mails from GitLab have a bunch of X-GitLab-* headers which can be useful for filtering. E.g. issues have X-GitLab-Issue-ID: and MRs have X-GitLab-MergeRequest-ID: -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer ___ 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
Re: [Mesa-dev] [ANNOUNCE] mesa 20.0.5
Michel Dänzer writes: > On 2020-04-23 8:37 p.m., Mark Janes wrote: >> - search for issues mentioning a test name (unless it is in the title) > > https://gitlab.freedesktop.org/mesa/mesa/-/issues?scope=all&utf8=%E2%9C%93&state=opened&search=test > > lists issues without "test" in the title, so this doesn't seem quite as > bad as you're making it. The search finds text in the title and body of the issue. Comments are not searchable. Most of the content of an issue is in the comments. >> - search for issues mentioning a commit > > https://gitlab.freedesktop.org/mesa/mesa/-/issues?scope=all&utf8=%E2%9C%93&state=opened&search=76dbcb1f5e48e10467b15a0e19232eccc3a57ae3 > > seems to work? In this example, the commit blob is matched because it is in the body text. Commits mentioned in comments are not matched. Searching for commits will not match a short sha. Surprisingly, even when a commit *closes* an issue, you cannot find the issue from the commit: https://gitlab.freedesktop.org/mesa/mesa/-/issues/2822 https://gitlab.freedesktop.org/mesa/mesa/-/issues?scope=all&utf8=%E2%9C%93&state=closed&search=665250e8300e2b0f3eae27628a9a6f2666e650dd >> - subscribe to issue comments in a way that would let you search >>offline > > On https://gitlab.freedesktop.org/mesa/mesa (or its parent page, for the > whole Mesa group of projects) click the drop-down next to the > notification bell, select "Custom" and check the "New note" box, then > you get an e-mail for every comment on every issue & MR. The goal is to monitor bug investigations for our component and identify problems that affect releases. This mechanism will generate a lot of mail, 95% of which is review comments on merge requests. Filtering out MR comments, the majority of remaining issue comments will still be for other components. A second email address is required to receive these messages, because all other gitlab notifications (eg, for my own issues/MRs) would be lost in the deluge. A second account could filter out merge request notifications, solving part of the problem. Perhaps some creative scripting can be combined with your suggestion to subscribe to all notes, tagging threads that have a message indicating labels were added. I need to subscribe to "all events for issues with labels: ANV i965 i915 iris". This use case has not been implemented: label subscription only tells you when a label is added/removed. It's a lot of work to cobble together a workflow that should be supported by Gitlab. ___ 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2020-04-23 6:56 p.m., Dylan Baker wrote: > Quoting Michel Dänzer (2020-04-23 09:24:45) >> 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. > > Indeed, I like the milestone approach and I've gone ahead and > created the milestone. And I set it as the milestone for Danylo's issue & MR. One gotcha is that both of these will show up as completed/closed/merged on the milestone once the MR is merged to master. At least in some cases it might be better to make a separate MR for the stable staging branch and set the milestone on that as well, to make sure they stay on the radar until the fix is on the stable branch. - -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer -BEGIN PGP SIGNATURE- iF0EARECAB0WIQSwn681vpFFIZgJURRaga+OatuyAAUCXqKhIwAKCRBaga+Oatuy AJaSAKCsKxCMp+EXfnlTjFd9uwwBDga0FwCgstcb+B5OwOfGTheQArey5W8kH3s= =OLqq -END PGP SIGNATURE- ___ 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
On 2020-04-23 8:37 p.m., Mark Janes wrote: > > 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. If a few clicks & keystrokes is really "a lot of busy work", only creating a milestone when actually needed is fine. The important part is that the stable manager actually checks the milestone before cutting the release. > 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) https://gitlab.freedesktop.org/mesa/mesa/-/issues?scope=all&utf8=%E2%9C%93&state=opened&search=test lists issues without "test" in the title, so this doesn't seem quite as bad as you're making it. > - search for issues mentioning a commit https://gitlab.freedesktop.org/mesa/mesa/-/issues?scope=all&utf8=%E2%9C%93&state=opened&search=76dbcb1f5e48e10467b15a0e19232eccc3a57ae3 seems to work? > - subscribe to issue comments in a way that would let you search >offline On https://gitlab.freedesktop.org/mesa/mesa (or its parent page, for the whole Mesa group of projects) click the drop-down next to the notification bell, select "Custom" and check the "New note" box, then you get an e-mail for every comment on every issue & MR. (One gotcha is that an e-mail is only sent for the original comment, not for any edits. Therefore, it's better to only edit comments for minor fixups) -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
