Re: bugs and bug tracking

On 10/06/2015 10:17 AM, Bruce Momjian wrote:
> First, let me say I am glad we are talking about this, and am open to
> the criticism that my and other's tracking open items by keeping them in
> our personal mailboxes is not only odd, but bizarre given the size of
> our community and the responsibility we have.

On the other hand, until we do have some kind of tracker, it is
absolutely essential. But at this point, it's more than one person can do.

This is kind of like CVS. We didn't upgrade so Subversion, becuase we
said "we already have a user-friendly interface to CVS, called Marc."
We only moved to git when it could provide us with solid advantages.

I believe the same thing is happening here. The inefficiency of the old
system (Bruce's mailbox) is becoming higher than the inefficiency of a
new, hypothetical system.

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

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

> My point is that we have our current workflow not because we are idiots,
> but because it fit our workflow and resources best. I am not sure if we
> have succeeded because of our current non-retain mode, or in spite of
> it. It might be time to switch to a default-retain mode, especially
> since most other projects have that mode, but we should be clear what we
> are getting into.

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

--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com