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(at)2ndQuadrant(dot)com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com