[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: issue verification

From: Michael Käppler
Subject: Re: issue verification
Date: Thu, 17 Sep 2020 13:27:06 +0200
User-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0

Am 17.09.2020 um 09:47 schrieb Jonas Hahnfeld:

Hi all,

unless I'm missing something, there has been no activity on this since
the community effort in May [1][2] and issues since version 2.21.2
don't yet have Status::Verified labels. As I'm currently updating CG to
mention our use of milestones (not sure why I forgot about this
previously), the verification procedure should probably also get
I haven't been active in this area (and don't plan to be), so it would
be great if somebody could look over the current description (assuming
the procedure should be continued).

To give a head start, here's again the list of all Status::Fixed:[]=Status%3A%3AFixed

Furthermore you can directly get to the issues associated with a
milestone, for example for 2.21.2:


Hi Jonas,
I just took a quick glance on it and have many questions... :)
Let me summarize them with an example:


1. Federico wrote in the thread you mentioned [1]:
"In the last comment you should find a commit id (if it's missing you'll
have to search it)."

I think this refers to the time before Gitlab, when issues had
a message like

Trim unused toplevel targets.
author    Han-Wen Nienhuys <>
    Sun, 22 Mar 2020 00:16:36 +0100 (00:16 +0100)
committer    Han-Wen Nienhuys <>
    Tue, 31 Mar 2020 21:18:36 +0100 (22:18 +0200)
commit    0755e2f3dbb99ac256fb447d6ed14d3fe87b8ab5

at the end of the thread, right?

2. So I thought I had to look at the corresponding MRs to find
the commits I shall verify.
For #5999, there are two MRs listed as 'Related', which are:
Add PDF bookmark support & multi-level TOC outline ability

Avoid scm_append_x for property values

I'm not sure how !145 is related to #5999. Maybe #5999 did show up
after !145, and !147 did fix it.

Anyway, am I right that I have to extract all commit ids from both MRs
and check if they got into 2.21.2? Or do I have some faulty thinking here?
This would be very complicated and time-consuming, especially when MRs
consist of several commits.

3. What I do not get: A milestone is simply a named period of time, to which
you can assign MRs and issues, right? So after each release, you (or
someone else)
start a new milestone with the next version number. If an issue has been
closed, you
set the issue's milestone to the current milestone.
An issue is closed automatically when the corresponding MR has "Closes
#..." in the description.
So if an issue is closed and the milestone of the next release is added,
what is there left
to verify? Can't we be sure that the commits of the corresponding,
closed MR have gone in?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]