Re: Bug tracker tool we need

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.