On 03.03.2016 10:19, Phil Holmes wrote:
----- Original Message ----- From: "Simon Albrecht"
<simon.albre...@mail.de>
To: "ly-devel" <lilypond-devel@gnu.org>
Sent: Wednesday, March 02, 2016 10:52 PM
Subject: Verifying issues
Hello,
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 <https://sourceforge.net/p/testlilyissues/issues/4754/> –
claimed to be ‘Fixed_2_19_38’ – and fed it into
<http://philholmes.net/lilypond/git/>, 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
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
