[Top][All Lists]

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

Re: Verifying issues

From: Simon Albrecht
Subject: Re: Verifying issues
Date: Thu, 3 Mar 2016 11:16:26 +0100

On 03.03.2016 10:19, Phil Holmes wrote:
----- Original Message ----- From: "Simon Albrecht" <address@hidden>
To: "ly-devel" <address@hidden>
Sent: Wednesday, March 02, 2016 10:52 PM
Subject: Verifying issues


I noticed that there have been many ‘Issues to verify’ around, so I started to catch up with these. Now the question is: Shouldn’t we only mark issues as verified, when the change is already included in an official release? For curiosity, following the CG instruction I took the committish from <> – claimed to be ‘Fixed_2_19_38’ – and fed it into <>, and it worked. So according to the instruction, I should mark the issue verified, although the change is not contained in the most recent release, 2.19.37.
What do you think?

Best, Simon

If you read _all_ the text in the CG concerning issues to verify, it says:

"do not verify any Issues where the claimed fixed build is not yet released"

so you should not even look in git for an issue marked "Fixed_2_19_38" since it is not in a released build.

I know. That was only for test purposes, because I was unsure how your web tool actually worked.

The Git check is solely to check that patches claimed to be in a release build actually are.

But does it? IIUC it only checks whether the commit is present in the code base _at all_, regardless whether it’s been included in a release. So I’d still have to trust the developer/committer who set the ‘Fixed_mm_MM_ss’ label – not exactly the point of Verifying, is it?

Yours, Simon

reply via email to

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