[Top][All Lists]

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

Re: Tracker 1686 - Process question - separate Tracker Issues or handlep

From: Colin Campbell
Subject: Re: Tracker 1686 - Process question - separate Tracker Issues or handlepatches as part of T1686?
Date: Sun, 06 Nov 2011 18:03:55 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1

On 11-11-06 05:30 PM, Graham Percival wrote:
On Sun, Nov 06, 2011 at 12:58:53PM -0700, Colin Campbell wrote:
On 11-11-06 10:41 AM, Phil Holmes wrote:
I've recently started an aversion to multiple issues.  The problem
is that it's a Bug Squad role to mark them as verified and we're
now over-run with issues just tracking patches.  As usual, I'm
sure Graham won't agree with me, but I think Squadders should
actually check that the patch works if we mark the issue as
Wait, what?  You're over-run with issues, so you want to do more
work per issue?  it only takes 30 seconds to check if a patch is
in git, so the amount of issue numbers isn't really a big deal
compared to whether or not you have to manually look at stuff.

oh hey, there's another easily-automated task.  We could
automatically check that the git commit is in master, then mark it
verified without any human looking at it.

Lots of issues - lots of checking.  My personal
preference would be to keep the single issue, with multiple

If not this, there should be clear instructions at the top of the
issue on how to verify.  "Is 1686 verified?  Then verify this
Recognising this may be part of a GOP issue, I agree loudly with
Phil on the inclusion as a standard part of an issue, the details of
how it is verified.  I, too, try to make sure a patch actually does
what it says, not just that it has been pushed to master, and for
some issues, the verification can be well beyond my notions of what
to look for.
Right.  Which is why I think we shouldn't even *try* to check if
patches actually work or not.  If there's a bug report, then sure,
check if the bug is fixed.  But if it's just a patch without an
attached bug report, then just mark it verified and get on with
other stuff.

Maybe I'm not using terms as commonly understood here: to me, a bug report has an issue number e.g., T1686, generated by the Google Issue Tracker. A patch *usually* has an issue number assigned by the Rietveld codereview tool, but not necessarily, as patches can be published as attachments to postings on devel. In order to mark a patch "verified", it *must* be associated with a Tracker issue, where the status is managed. Patches without Tracker issues are essentially invisible to the rank-and-file Bug Squad as well as to the rank-and-file patch-nanny. Tracker issues may or may not have patches, but their status is easily reviewed. Patches may or may not be linked to Tracker issues, but they can only be seen when they are linked, unless one does repeated searches on Rietveld by (known) developer.

With that in mind, though, your point about automating the check to see if a patch has been pushed, as the sole criterion for considering it verified, certainly has my vote, as it removes the verify task from the Bug Squad list of duties.


I've learned that you shouldn't go through life with a catcher's mitt on both 
You need to be able to throw something back.
-Maya Angelou, poet (1928- )

reply via email to

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