[Mesa-dev] [ANNOUNCE] mesa 20.0.5

[Denys]

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 <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.
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev