Re: Bug tracker tool we need

On Mon, Apr 16, 2012 at 23:48, Jay Levitt <jay(dot)levitt(at)gmail(dot)com> wrote:
> 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.

That's probably one reason people aren't jumping on this. Because
there is no tracker out there that people actually *like*...

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

It being in ruby is actually generally a liability in the
postgresql.org world - we have very few people who actually know it.
And some of those who know it no longer want to work with it. So if
you're good with Ruby, and want to contribute, feel free to contact me
off-list because we have some things we need help with :-)

> 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

We already have redmine working with single password (though not
single signon) for a limited number of projects such as pgweb.

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

I think we can all agree on that :-)

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

Most of the more senior developers don't use github. Other than
possibly as a place to store a plain git repository. So that's not
really relevant.

> - Discoverability: GitHub has great SEO

I'm willing to bet that postgresql.org has better SEO when it comes to postgres.

> - Tight integration of git with patch and issue management (pull requests,
> fork networks, etc); eliminates ceremony rather than adding to it

There are some things that help there, certainly. Pull requests is
basically email, but fork network tracking and such can be darn useful
sometimes.

> - Readable UI with syntax highlighting, etc

Yes, this part is very nice.

> - Patch commenting and git integration encourage actual review-resubmit
> cycles instead of "Here, look, I fixed it for you" reviews

The amount of spam coming through that system, and the
inability/unwillingness of github to even care about it is a killer
argument *against* github.

We have working antispam for email. The github antispam is somewhere
around where email antispam was in 1994.

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

It *is* a non-starter, because (a) it's a third party dependency, and
(b) AFAIK they don't provide *data access* to the issue trackers.

If the actual issue trackers were stored in git, like the webpages are
for example, it would be a different story...b

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

I'm sure there's more than one :-)

If it was that easy we would've written one already. But doing that is
likely going to be a lot of work, and it needs to be maintained.

(Not that picking another one means it doesn't need to be maintained -
I've seen so many things broken by upgrading redmine or bugzilla that
it's silly...)

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/