Re: Bug tracker tool we need - Mailing list pgsql-hackers

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.

Reasons:

- 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.

Jay

[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.