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

[Graham Percival]

On Sun, Nov 06, 2011 at 06:03:55PM -0700, Colin Campbell wrote:
> On 11-11-06 05:30 PM, Graham Percival wrote:
> >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.

ah, I see.  I've tried to use the terminology:
  - google code issue number
  - rietveld number
but it's kind-of a vague problematic thing.  If somebody can
suggest better terminology, I'm all for it.

I certainly think we should avoid the term "google issue tracker"
to refer to rietveld, since that invites confusion with
code.google.com/p/lilypond/issues/

It's tricky.  :(

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

I'm agree that those patches should be considered to be invisible,
and no bug squad members should even think about dealing with
those.  We're in agreement here.

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

well, automating that task will probably take an hour, but it's
not urgent.  Unless you do it personally, I doubt it'll be done in
2011... so it's still on the list of duties.  But ideally it
shouldn't, and there's hope / a plan that it'll be removed in the
future.

- Graham