[Mesa-dev] [ANNOUNCE] mesa 20.0.5

[Mark Janes]

Michel Dänzer <michel at daenzer.net> writes:

> On 2020-04-23 6:19 p.m., Mark Janes wrote:
>> Michel Dänzer <michel at 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.