Re: Tracker 1686 - Process question - separate Tracker Issues or handlepatches as part of T1686?

[Colin Campbell]

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
> > > verified.
> 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
> > > patches.
> > >
> > > If not this, there should be clear instructions at the top of the
> > > issue on how to verify.  "Is 1686 verified?  Then verify this
> > > one."
> > 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.

Cheers,
Colin

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