lilypond-devel
[Top][All Lists]
Advanced

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

Re: issue verification


From: Michael Käppler
Subject: Re: issue verification
Date: Fri, 18 Sep 2020 10:12:02 +0200
User-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0

Am 18.09.2020 um 08:57 schrieb Jonas Hahnfeld:
Am Donnerstag, den 17.09.2020, 23:01 +0200 schrieb Michael Käppler:
 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?
See below.

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.
Yes, that is what CG mentions should be done, please refer there.
I found the following section ambiguous:

>>>>

"If the issue refers to a bug, try to reproduce the bug with the latest
officially released version (not one you’ve built yourself from source);
if the bug is no longer there, mark the issue “Status::Verified” (i.e.,
“the fix has been verified to work”).

Quite a few of these will be issues tracking patches. *You do not have
to prove these patches work - simply that they have been pushed into the
code base.* The developer should have put information similar to “Pushed
as as d8fce1e1ea2aca1a82e25e47805aef0f70f511b9” in the tracker. The long
list of letters and numbers is called the “committish”."

<<<<

Please let me give another try:

1. If an issue refers to a bug and is marked as Status::Fixed, test if
the bug is really gone in the latest release.
2. If an issue refers to another change (Enhancement, Documentation,
...) and has a MR assigned, verify if the corresponding MR
has gone into the release. (This should not be necessary with the
current process, IMHO).

Do you mean we should try to start a new community effort to do that?
I'm not implying anything. The question was that somebody who knows
about the procedure (not me) should go over the instructions given in
the documentation. Until that happens, it's pointless to discuss among
three people (you, Jean, me) who don't know about it.
Ok. My starting point was to help with the verifying process, which is
only possible, if I
understand what we want to do and how we want it to be done.
I'm not sure if waiting for more insightful people is promising, given
that up to now
nobody else replied.
Maybe the discussion gives some insight where the CG could be clearer
for people
like me who do not know about the procedure.

Thanks for your time,
Michael


reply via email to

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