Re: issue verification

[Michael Käppler]

Am 17.09.2020 um 21:32 schrieb Jonas Hahnfeld:
> Am Donnerstag, den 17.09.2020, 20:58 +0200 schrieb Jean Abou Samra:
> > What I do not yet understand is when milestones should be assigned
> > to issues and MRs. So far Jonas has done this from time to time. That was
> > after each release, right?
> Yes, mostly so. I'm just continuing what CG previously said about the
> Fixed_x.y.z labels: Closed issues should be labeled Status::Fixed and
> assigned a label, now a milestone, so they can be found. Additionally,
> I assign all merge requests without a milestone after Phil does a
> release and I need to create a new milestone anyway. That has the
> benefit that the milestone bundles all information about the changes
> that went into a release, in a single place.´
I still do not understand why this verification could be necessary in the
current process:

1. Phil did a release, let's say 2.21.7. you open a new milestone for
the next release,
2.21.8. You assign all merge requests that do not have a milestone (that
is, all
that were merged between 2.21.6 and 2.21.7) to milestone 2.21.7.
2. Someone tackles an open issue with a merge request. He writes
'Closes #1234' in the description. After the MR has been accepted and
merged, issue #1234 will be automatically closed.
(But Status::Fixed must be set manually, right?)
3. Phil does 2.21.8, and you or someone else does assign the milestone
'2.21.8'
to closed and fixed issues.

The cycle starts from the beginning.

From my point of view, if an issue is
1. closed
2. marked as "Status::Fixed"
3. assigned to milestone x.y.z

one can be sure that it is fixed in release x.y.z
What should we verify?

Another point is what Jean mentioned, 'verifying' in the sense of
checking, whether a particular issue is really fixed in the release
that corresponds to the issue's milestone.

Do you mean we should try to start a new community effort to do that?

Michael