Re: Bug tracker tool we need

On 04/17/2012 09:20 AM, Jay Levitt wrote:
> Antispam is (in the large) a technically unsolvable
> problem; even in the '90s, we'd see hackers start poking at our newest
> countermeasures within the hour. GitHub is a giant target, and PG
> probably benefits here from NOT being one.

Everyone who deals with list moderation and spam issues around 
PostgreSQL just got a belly laugh from that comment.  Hint:  the 
PostgreSQL lists had already been around and therefore were being 
targeted by spammers for over ten years before GitHub even existed.

> Pedantic note/fun fact: There was no email antispam in 1994

I like it when Magnus really gets the details perfect when making a 
deadpan joke.

Anyway, back to serious talk, I believe GitHub is a dead end here 
because the "primary key" as it were for issues is a repo.  A bug 
tracker for PostgreSQL would need to have issues broken down per branch 
and include information similar to the release notes for each minor 
point release.  Tracking when and how a bug is backported to older 
versions is one hard part of the problem here.

For example, Trac, Redmine, and Github all have ways to make a commit 
message reference an issue, something like "fixes #X".  That's fine for 
projects that don't have a complicated backport policy, but I haven't 
been able to figure out how to make it work well enough for a PostgreSQL 
bug tracker, to end up saving any work here.  In some cases, a bug 
shouldn't be closed until it's been backported to all supported 
releases.  Others will only fix in relevant releases.

Let's pick a real example from the last week of my life, where having a 
bug tracker would have helped me out.  This appears in a log:

ERROR: missing chunk number 0 for toast value 1167375 in pg_toast_2619

What I should be able to do here is search the bug tracker for these 
words and have it spit out an issue that looks like this

===

Bug:  Fix race condition during toast table access from stale syscache 
entries

Impact:  Transient query failures

Fixed in:

9.2.0:  http://archives.postgresql.org/pgsql-committers/2011-11/msg00012.php

9.1.2:  http://archives.postgresql.org/pgsql-committers/2011-11/msg00016.php

9.0.6:  http://archives.postgresql.org/pgsql-committers/2011-11/msg00014.php

8.4.10: 
http://archives.postgresql.org/pgsql-committers/2011-11/msg00013.php

8.3.17: 
http://archives.postgresql.org/pgsql-committers/2011-11/msg00017.php

8.2.23: 
http://archives.postgresql.org/pgsql-committers/2011-11/msg00015.php

===

Note that the "fixed in" version information doesn't show up until some 
time *after* the bug fix is committed, because they normally get rolled 
into the next minor release in bulk.

A bug tracking system for PostgreSQL will start looking attractive when 
it makes life easier for the people who do these backports and the 
associated release notes.  Start looking at the problem from their 
perspective if you want to figure out how to make that happen.  I don't 
have a good answer to that; I just know that Trac, Redmine, and GitHub 
haven't felt like a good fit, having used every one of that trio for 
multiple years now at some point.

-- 
Greg Smith   2ndQuadrant US    greg@2ndQuadrant.com   Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com