Alex wrote:
I still fail to see how Redmine doesn't fit into requirements summarized
at that wiki page[1], so that must be something other than formal
requirement of being free/open software and running postgres behind
(some sort of "feeling" maybe?)

Well, if those requirements are in fact requirements, Redmine could suit the purpose (perhaps with some custom extensions). But yes, Redmine "feels" wrong to me, though I have never been particularly happy with *any* self-hosted bug tracker.

Of those I've used - Redmine, Mantis, JIRA, Trac, Bugzilla, GForge, RT - Redmine feels the least-worst to me; it's about equal to Trac, and it's in Ruby so I could theoretically(!) improve it.

I think the biggest missing pieces in Redmine aside from custom CF stuff are: better search, single sign-on (it requires Yet Another Login), a better UX (AJAX, syntax highlighting) and better git integration (a la pull requests, where private git commits = patches). Those are some pretty big pieces. I don't think Redmine out-of-the-box would improve either CFs or community involvement.

Jay, Alvaro, Dimitri (and whoever else wants to speak up) could you
please describe your ideal tool for the task?

My opinion isn't all that important, since I currently have an infinite opinion-to-contribution ratio, but in my unicorniverse: We'd accept that open source hasn't always produced great UX, we'd use GitHub's issue tracker, allow volunteers to do "bug wrangling" triage via tags, use GitHub hooks to integrate with the existing CF app, and write archiving tools that would let us easily export everything off of GitHub for when (a) something better comes along or (b) GitHub pops out of existence or adds egregious licensing terms like BitKeeper.


- Familiarity: Many developers already have a GitHub account and use it
- Discoverability: GitHub has great SEO
- Tight integration of git with patch and issue management (pull requests, fork networks, etc); eliminates ceremony rather than adding to it
- Readable UI with syntax highlighting, etc
- Patch commenting and git integration encourage actual review-resubmit cycles instead of "Here, look, I fixed it for you" reviews
- Two-way email/web integration
- Meets Tom's "would be sort of neat" criteria[1]
- Could easily implement Simon's "pony" criteria[2] with tags and API
- Easily extensible with API and hooks
- Subjectively: Its design encourages better community and core interactions than any I've seen in 25 years.

GitHub could well be a non-starter, but if third-party-dependence is really the holdup, I'd volunteer to write the tools - in fact, a google of [export issues from github] shows a few that might already suffice.

Given that every other existing tool likely have pissed off someone
already, I guess our best bet is writing one from scratch.

ISTR there's a great "Writing your own bug tracker is an anti-pattern" blog, but I can't find it anymore.

Or maybe there isn't really a need for a tracker?  The core team have
managed to live without one for so long after all...

As an end-user, I've reported exactly one bug in a release version of Postgres, and it was fixed (and back-ported!) the next day. So I really can't complain about the tracking of actual bugs.

Sounds like we do need something better for CF/patch workflow, tho.


[1] Tom wrote:

Now what would be sort of neat is if we had a way to keep all the versions
of patch X plus author and reviewer information, links to reviews and
discussion, etc. in some sort of centralized place

[2] Simon wrote:

My I-Want-a-Pony idea is some kind of rating system that allows us all
to judge patches in terms of importance/popularity, complexity and
maturity. I guess a Balanced Scorecard for the development process. So
we can all see whats going on.

Sent via pgsql-hackers mailing list (
To make changes to your subscription:

Reply via email to