Re: Verifying issues

[David Kastrup]

Simon Albrecht <address@hidden> writes:

> 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?

     You should see a list of Issues that have been claimed fixed by a
     developer.  If the developer has done their job properly, the Issue
     should have a tag “Fixed_mm_MM_ss”, where mm is the major version,
     MM the minor version and ss the current release.  This will help
     you work out which you can verify - do not verify any Issues where
     the claimed fixed build is not yet released.

That clearly means you should not verify those.  BUT verification by
feeding into <http://philholmes.net/lilypond/git/> without actually
looking where the 2.19.38 release tag sits is, as you properly
recognized, not reliable.

I think this might have been the result of Graham trying to create a job
description that could be followed by the Bug Squad _without_ having an
actual Git checkout available.

If you can figure a "tag xx_xx_xx contains commit id xxxxxxxxxxxxx"
check that works using just web access, feel free to adjust the
instructions.

-- 
David Kastrup