On Thu, Jan 31, 2019 at 08:04:39AM -0300, Alvaro Herrera wrote:
> Here's a bug tracking system that Nathan set up many years ago and
> apparently has kept going unattended. It seems to me that it's
> something that we could base a semi-official bug tracking system on.
>
> https://granicus.if.org/pgbugs/
>
> There are clearly things that need fixed, such as failure to
> base64-decode the body of messages, etc
This is fixed now. I re-marked as stale bugs that haven't had any email
for 180 days. I have also done some basic triage on some of the
remaining bugs.
There are a lot of bug reports that never get a response. Take bug
15513 (https://granicus.if.org/pgbugs/15513 or
http://www.postgresql.org/message-id/%3c15513-94a76c56fa3ee...@postgresql.org%3E)
for example. I think it's either a documentation bug (assuming
incomplete documentation is considered a bug), or a feature request,
or possibly a bug. I don't know enough about either the pgrowlocks
extension or the internals of locking to tell the difference.
So, on to how I have updated the status marked for bugs. Where
a bug hadn't had any new emails for the last 180 days, I unconditionally
marked the bug as stale. Where I could find a message by grepping
the git logs that indicated a particular bug number was fixed, I marked
the bug as fixed. If the bug appeared to be a genuine bug, but in
another bit of software (usually pgadmin), I marked it as Not Our Bug.
If the bug report didn't actually seem to be a bug, but either garbage
(e.g. 15314), or user error, I marked them as Not a Bug.
If the bug seemed to be either an actual bug or something that would
have actual work done, I marked these as open. It's entirely probable
that some or most of these are actually fixed. There were a number
of cases where committers emailed in a "will fix" type message, but
I don't have any indication that this was actually done.
A few other bugs I marked as Unreproduceable or just Closed if that
seemed appropriate. In general, I have tried not to make an independent
judgment of the status of a bug, unless it was blindingly obvious what
the status should be.
It would be primarily useful if there were an easily machine readable
way to associate a commit with a "this commit is intended to fix bug
number X". I think the easiest way to do that is with syntax in the
commit message. People generally already do this with syntax like:
Author: Dmitry Dolgov
Reviewed-by: Tom Lane, Arthur Zakirov
Discussion: https://postg...
I have used the regex /Fixes bug #([0-9]+)/ to automatically look for
commits purporting to fix bugs by number.
I have thought about automatically marking as Open any bug report that
gets a reply email, but that's probably too broad. A lot of those
replies are variations on "this is not a bug", so Open wouldn't
really make sense.
In any case, the system is functional again, and I have done some
work in categorizing bugs. The full text search function works
as well, which I have found useful on occasion.
> ... and we probably want to
> piggyback on our archives rather than having its own copy of the emails.
I sort of do both. The pgbugs list is processed on my server via
procmail and a perl script, so I have a copy of the emails, but
the links for each email point back to the archives, rather than
my copy.
--
nw
