Re: How can I check the treatment of bug fixes?

On Fri, May 27, 2011 at 9:24 PM, Peter Eisentraut <peter_e(at)gmx(dot)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?"