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