[wp-hackers] Finding bugs to fix on Trac

[Lloyd Budd]

On 2/22/07, Jennifer Hodgdon <yahgrp at poplarware.com> wrote:

Jennifer, you are doing fantastic work on the Codex!

> >> >> We have a few keywords we use: commit, has-patch, dev-feedback,
> >> >> 2nd-opinion, needs-testing, reporter-feedback.
>
> >> Yeah, it would be great if everyone used them, so the reports would
> >> return something useful, besides just a list of all the bugs that are
> >> still open. Oh well!
>
> > They are fairly consistently used, can you be more specific so we can
> > identify the problem?
>
> OK, run the "Needs Patch" report:
>      http://trac.wordpress.org/report/13
> (this returns the tickets that are open and not marked with "has-patch")
>
> Right now, 4 of the top 10 tickets in the list have something that
> looks like a patch file attached to them; farther down in the list, I
> clicked on 5 random items and 3 had patches attached.

That result surprises me a little. I don't imagine that sampling is
representative, but easily enough to correct if do find ourself at
such bugs. I will renew my vigil ;-)

> My thought was that, given that we have a couple of WordPress
> developers on the list, presumably someone could write a quick SQL
> join query and make a new report that checks to find Trac items that
> actually do not have patch files attached, since presumably the
> attachments are stored in a database table... ??

As I wrote previously, "That sounds quite complicated, and would
require attentional infrastructure. Is it a patch or another file? Is
it a complete patch or a work in progress or a partial solution?"

All group bug management systems need a participant triggered state
based change when a fix is ready for review / committing, in our case
that is adding a 'has-patch' tag.

Cheers,
Lloyd