Simon Albrecht <simon.albre...@mail.de> 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
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
