Thread: bug tracking system
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 ... and we probably want to piggyback on our archives rather than having its own copy of the emails. But it's a starting point for discussion. -- Álvaro Herrera
On 2019-Jan-31, 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. I didn't really remember that Nathan's system had been discussed so widely. Here are the two main threads there were as far as I could find: https://postgr.es/m/20151004224254.GA1948@granicus.if.org https://postgr.es/m/20151006130524.GA4322@granicus.if.org -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
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-94a76c56fa3eed61@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
On 2019-Feb-03, Nathan Wagner wrote: > 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. Yeah, this is pretty common and unhelpful. We should reply to the mailing list with a commit ID or something. > I have used the regex /Fixes bug #([0-9]+)/ to automatically look for > commits purporting to fix bugs by number. Let's use that. > > ... 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. Hmm. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> On 2019-Feb-03, Nathan Wagner wrote:
>> I have used the regex /Fixes bug #([0-9]+)/ to automatically look for
>> commits purporting to fix bugs by number.
> Let's use that.
That will have caught exactly none of my own commits.
regards, tom lane
On 2019-Feb-06, Tom Lane wrote: > Alvaro Herrera <alvherre@2ndquadrant.com> writes: > > On 2019-Feb-03, Nathan Wagner wrote: > >> I have used the regex /Fixes bug #([0-9]+)/ to automatically look for > >> commits purporting to fix bugs by number. > > > Let's use that. > > That will have caught exactly none of my own commits. Well, what text do you use? I see "Per bug #XYZ" in the free-form text of your commit messages, though that doesn't explicitly say that the bug is fixed. If we agree that that phrase indicates that the bug is fixed, it seems fair to mark those bugs as fixed in Nathan's system. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Alvaro Herrera <alvherre@2ndquadrant.com> writes: > On 2019-Feb-06, Tom Lane wrote: >> That will have caught exactly none of my own commits. > Well, what text do you use? I see "Per bug #XYZ" in the free-form text > of your commit messages, though that doesn't explicitly say that the bug > is fixed. If we agree that that phrase indicates that the bug is fixed, > it seems fair to mark those bugs as fixed in Nathan's system. There are a couple of problems here. One is that we haven't really got an agreed-to formula for saying that this commit fixes that bug. It's not that uncommon for a commit message to reference a bug that it doesn't fix --- I did that just today, for example. So I'm worried that a regex that tries to capture all of the former will capture some of the latter too. The other problem is that not all bugs have got bug numbers to begin with. We just had some discussion about trying to label all pgsql-bugs traffic with bug numbers, but it wasn't sounding promising. I do have a modest proposal for improving things going forward. How about, if a commit purports to fix a particular bug, that we say "Fixes: https://postgr.es/m/<message-id>" in place of our current habit of saying "Discussion: ...". For bugs that have come in through the bug form, the bug number is trivially extractable from the message-id these days; but this method works for any mailing list report, not just those. (Obviously, you could also use a Discussion: line, if say there was relevant discussion outside the thread containing the bug report.) regards, tom lane
On Wed, Feb 06, 2019 at 10:50:51PM -0500, Tom Lane wrote: > I do have a modest proposal for improving things going forward. > How about, if a commit purports to fix a particular bug, that > we say "Fixes: https://postgr.es/m/<message-id>" in place of > our current habit of saying "Discussion: ...". For bugs that > have come in through the bug form, the bug number is trivially > extractable from the message-id these days; but this method > works for any mailing list report, not just those. Wouldn't it be the same as making the effort to have a proper "Reported-by" field for each actual bug fix then? We already have that attached to some of the commit logs for bug fixes. I personally try to follow that pattern. -- Michael
Attachment
Michael Paquier <michael@paquier.xyz> writes: > On Wed, Feb 06, 2019 at 10:50:51PM -0500, Tom Lane wrote: >> I do have a modest proposal for improving things going forward. >> How about, if a commit purports to fix a particular bug, that >> we say "Fixes: https://postgr.es/m/<message-id>" in place of >> our current habit of saying "Discussion: ...". > Wouldn't it be the same as making the effort to have a proper > "Reported-by" field for each actual bug fix then? No, that'd be additional effort on top, which I'm not sure I see a reason for. Nobody's given a plausible reason why we need a machine-readable way to identify the bug reporter's name from the commit log. And we get a fair number of reports with no name or an obvious pseudonym, too, so how would you handle that? regards, tom lane
On Wed, Feb 06, 2019 at 10:50:51PM -0500, Tom Lane wrote: > Alvaro Herrera <alvherre@2ndquadrant.com> writes: > > On 2019-Feb-06, Tom Lane wrote: > >> That will have caught exactly none of my own commits. > > > Well, what text do you use? I see "Per bug #XYZ" in the free-form text > > of your commit messages, though that doesn't explicitly say that the bug > > is fixed. If we agree that that phrase indicates that the bug is fixed, > > it seems fair to mark those bugs as fixed in Nathan's system. > > There are a couple of problems here. > > One is that we haven't really got an agreed-to formula for saying that > this commit fixes that bug. It's not that uncommon for a commit message > to reference a bug that it doesn't fix --- I did that just today, for > example. So I'm worried that a regex that tries to capture all of the > former will capture some of the latter too. I don't think any reasonable regex would have caused a false positive from the commit message in commit bdd9a99aac3. > The other problem is that not all bugs have got bug numbers to begin > with. We just had some discussion about trying to label all > pgsql-bugs traffic with bug numbers, but it wasn't sounding promising. > > I do have a modest proposal for improving things going forward. How > about, if a commit purports to fix a particular bug, that we say > "Fixes: https://postgr.es/m/<message-id>" in place of our current > habit of saying "Discussion: ...". For bugs that have come in through > the bug form, the bug number is trivially extractable from the > message-id these days; The bug number would only be extractable from the message-id of the first message. This proposal would require finding the message-id of the original message, rather than just looking at the subject of any message in the thread. That seems like more work than is really necessary. Furthermore, this only works if you know in advance that the message-id is a message id generated by the bug submission form, otherwise if a message-id has the same form, it might look like a bug id. What I'm dimly attempting to express is that I think this method would more subject to false positives than just quoting the bug number directly. But I'm happy to work with whatever syntax people want to use. I'm even happy to write a different regex for each person. I can easily write a script that would look for log messages where Tom Lane was the committer and look for a string of the form above. A bigger question, at least for me is do people actually want to use the system I've set up? What do people think of it? If people aren't interested in it, and won't use it, then it's not worth putting a lot more work into it. I'll keep it going for myself even if bug statuses never get updated because I occasionally find the text search useful. A brief look though indicates that there is already a way to search the mailing list archives. So, if the general sense is that what I've set up is sort of pointless, that's useful information as well. -- nw
Nathan Wagner <nw+pg@hydaspes.if.org> writes: > On Wed, Feb 06, 2019 at 10:50:51PM -0500, Tom Lane wrote: >> I do have a modest proposal for improving things going forward. How >> about, if a commit purports to fix a particular bug, that we say >> "Fixes: https://postgr.es/m/<message-id>" in place of our current >> habit of saying "Discussion: ...". For bugs that have come in through >> the bug form, the bug number is trivially extractable from the >> message-id these days; > The bug number would only be extractable from the message-id of the > first message. This proposal would require finding the message-id of > the original message, rather than just looking at the subject of any > message in the thread. That seems like more work than is really > necessary. The existing convention is already to cite the message-id of the start of the thread. I proposed this exactly because it's no more work than before for the committer. > A bigger question, at least for me is do people actually want to use the > system I've set up? Yeah, that's really the bottom line here --- there's been a lot of "if you build it they will come" theorizing about bug trackers, but we have little evidence either way about how people would really use one. regards, tom lane
On Thu, Feb 07, 2019 at 12:20:35AM -0500, Tom Lane wrote: > No, that'd be additional effort on top, which I'm not sure I see > a reason for. Nobody's given a plausible reason why we need > a machine-readable way to identify the bug reporter's name from > the commit log. And we get a fair number of reports with no name > or an obvious pseudonym, too, so how would you handle that? Hm. Or just rely on Backpatch-through? A decent bug tracker usually displays nicely what are the versions impacted, so this field should be parsed anyway. -- Michael