Re: bugs and bug tracking

On Tue, Oct 06, 2015 at 10:57:42AM -0700, Josh Berkus wrote:

> On 10/06/2015 10:17 AM, Bruce Momjian wrote:

> > Therefore, our current default behavior is to ignore user reports,
> > unless someone takes an action to reply, record, or retain the email for
> > later review.  What a tracker does is to make the default user report be
> > _retained_, meaning we have to take action to _not_ retain a user report
> > as an open item.
> 
> Well, we can determine how that's handled.  There are bug trackers out
> there that automatically archive unconfirmed bug reports after a certain
> amount of time.  I'd personally recommend it.
> 
> Of course, that requires a bug tracker which can have an "unconfirmed"
> status.

This is essentially what I have done with the 'Stale' status.  Though
I have done at two years to be conservative, rather than 60 days,
which I think is entirely more reasonable.

> > Second, we have a mix of user reports.  Some bug reports are not bugs
> > and must be reclassified.  In other cases, uses ask questions via
> > non-tracked communicate channels, e.g. pgsql-general, but they are
> > really bugs.  So, to do this right, we need a way of marking tracked
> > bugs as not bugs, and a way of adding bugs that were reported in a
> > non-tracked manner.
> 
> Yeah, I was wondering about that.

I think I have suggested that there be a way to generate a bug id via
email.  Presumably someone could just copy that email address to make a
not-tracked discussion get a bug id.  If the system archived all the
lists (not hard) it would be possible to pull the other emails from the
thread into the bug (also not hard).  As for marking as 'not-a-bug'
this can easily be done via whatever mechanism might be used.
Something along the lines of:

Bug Status: not a bug

would probably work.  It's really whatever people are willing to
actually do.

> FWIW, when I talk about bugs which we lost track of, they're not
> generally unconfirmed bug reports.  Usually, it's stuff which a
> contributor replied to, but the bug was low-impact, circumstantial, and
> hard to reproduce, and came in during a busy period (like release time).
>  So I'd be perfectly OK with the idea that unconfirmed bugs hang around
> in the system for 60 days, then automatically convert to "stale" status.

My tracker would do this trivially if I changed the query to 60 days
instead of two years.

> Until we build up a team of volunteers for bug triage, we might have to
> do that.
> 
> Speaking of which ... this project is rich in skilled users who are
> involved in the community but don't code.  Bug triage is exactly the
> kind of thing very part-time community supporters can do, if we make it
> easy for them to do.

I can make it easy.  But that doesn't directly address two of the other
points:

1: Do we need any system for who is allowed to triage bugs?
2: Should an equivalent email be sent to the list?

Specifically with point number 2, suppose the above mechanism is
used.  When a triager marks a bug as (say) not a bug, should
the system just update the database, or should it actually
send a formatted email to the bugs list with the 'Bug Status: not a bug'
line (among others, presumably)?  I think it should send the email,
but I can see how that could be construed as junk.

-- 
nw