On Fri, May 27, 2011 at 9:24 PM, Peter Eisentraut <pete...@gmx.net> wrote: > On fre, 2011-05-27 at 13:55 -0400, Robert Haas wrote: >> Also, I think it's about time we got ourselves some kind of bug >> tracker. I have no idea how to make that work without breaking >> workflow that works now, but a quick survey of my pgsql-bugs email >> suggests that this is far from the only thing slipping through the >> cracks. > > The problem is finding a usable bug tracking software.
On the "upside," we have gotten to the point where people that count are finding the CommitFest application, which Is Not Simply Email, to be an acceptable and useful thing to use. But I don't find that I notably *like* any of the bug trackers that I have encountered thus far. There are a few "PG-basable" options (e.g. - RT, Bugzilla), but it's not *quite* good enough to pick something just because it's running on our own DB. I suspect that, from a technical perspective, the emergence of distributed bug trackers (Fossil, SD, Bugs Everywhere), which parallels distributed SCM (e.g. - Git) may be part of the "way to go," but that's still pointing at technical mechanism, as opposed to workflow. There is a page on the wiki documenting requirements that have been discussed: http://wiki.postgresql.org/wiki/TrackerDiscussion It hasn't been touched since 2008, but I expect that wiki page would make a better starting point to restart discussion than anything else. And it is quite likely worthwhile to consider what linkages to the CommitFest schema/code/interfaces are relevant. I'll also poke at SD (https://github.com/bestpractical/sd) as having some ideas worth looking at, as it combines: - Being inherently distributed, where bugs are assigned UUIDs as identifiers, and where data is pulled via Git repos - Essentially text-based, by default, so that it doesn't assume/mandate communicating with a web server - Somewhat agnostic of data sources; it can push/pull data to/from RT, Hiveminder, Trac, GitHub, Google Code, and Redmine. And there's a useful principle here: if the PostgreSQL project's issue tracker can sync data against something like SD, then developers have extra options. I rather wish that Slony was using one of those 6 trackers, rather than Bugzilla, as I could use SD+adaptor, and be able to work on issues offline. At any rate, a useful step would be to dust off the contents of that wiki page, and see if there are more details that are widely agreeable. The (sometimes modest) successes of the CommitFest application should provide some useful guidance. -- When confronted by a difficult problem, solve it by reducing it to the question, "How would the Lone Ranger handle this?" -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
