Michel Dänzer <mic...@daenzer.net> writes: > On 2020-04-23 6:19 p.m., Mark Janes wrote: >> Michel Dänzer <mic...@daenzer.net> 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