[Top][All Lists]

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

Re: Verifying issues

From: David Kastrup
Subject: Re: Verifying issues
Date: Thu, 03 Mar 2016 00:45:46 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux)

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

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

David Kastrup

reply via email to

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