Re: Commit fest queue - Mailing list pgsql-hackers

From Gregory Stark
Subject Re: Commit fest queue
Date
Msg-id 87ve2offo5.fsf@oxford.xeocode.com
Whole thread Raw
In response to Re: Commit fest queue  ("Brendan Jurd" <direvus@gmail.com>)
Responses Re: Commit fest queue  ("Joshua D. Drake" <jd@commandprompt.com>)
Re: Commit fest queue  (Andrew Dunstan <andrew@dunslane.net>)
Re: Commit fest queue  (Andrew Sullivan <ajs@crankycanuck.ca>)
Re: Commit fest queue  (Kenneth Marshall <ktm@rice.edu>)
Re: Commit fest queue  ("Brendan Jurd" <direvus@gmail.com>)
List pgsql-hackers
"Brendan Jurd" <direvus@gmail.com> writes:

> In Trac, if I just want to loosely associate several tickets together
> I'd use *keywords*, e.g., put "index am" in the keywords list for
> several tickets, and then they'll show up prominently when I search
> for those terms.

As an aside, you've reminded me about another thing that bothers me about
Bugzilla and RT. In both cases they seem to put a lot of focus around the idea
of "searching" bugs. I don't really get why.

Maybe it makes sense if you plan to be like Mozilla and have 8-year-old bugs
that nobody ever sees let alone updates, but surely that isn't the goal.

In fact it seems like having the UI centred around "searching" pretty much
dooms you to that fate. Of course things will fall through the cracks if your
main UI only presents the things you decide to go look for.

I would think an interface which presents you with *all* unclosed bugs by
default, perhaps organized in some way (keywords, milestones, etc) would be
more conducive to getting attention to everything.

I'm sure you can do something like that in Bugzilla and RT but it sure doesn't
seem to be the way it's used in practice.

--  Gregory Stark EnterpriseDB          http://www.enterprisedb.com Ask me about EnterpriseDB's RemoteDBA services!


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Cached Query Plans (was: global prepared statements)
Next
From: "Joshua D. Drake"
Date:
Subject: Re: Commit fest queue