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