Re: [HACKERS] Bug tracker tool we need (was: Last gasp)
On Mon, Apr 16, 2012 at 06:29:47PM +0200, Magnus Hagander wrote: > FWIW, I think the closest thing we've found so far would be debbugs - > which IIRC doesn't have any kind of reasonable database backend, which > would be a strange choice for a project like ours :) And makes many > things harder... FWIW, Don Armstrong (the main debbugs hacker these days I believe) recently posted a blog post about a more obscure feature of debuugs (forcemerge), where he finishs with "so we can eventually keep a postgresql database updated in addition to the flatfile database.": http://www.donarmstrong.com/posts/debbugs_forcemerge/ I don't know whether this implies a full PostgreSQL backend or just a helper DB for some part of the functionality, but it might be something to keep watching. Regards, Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Bug tracker tool we need (was: Last gasp)
On Mon, Apr 16, 2012 at 18:24, Alex wrote: > > Dimitri Fontaine writes: > >> Alvaro Herrera writes: >>> I've used Redmine a lot, as you know, and I only keep using it because >>> it's a requirement at work. It is certainly not close to usable for >>> general pgsql stuff. (Trac, which we used to use prior to Redmine, was >>> certainly much worse, though). >> >> Same story here, still using redmine a lot, all with custom reports etc. >> >>> I can't say that it's all that slow, or that there's a problem with the >>> code, or that the search doesn't work right (and I've never had a wiki >>> edit disappear, either, and I've used that a lot). It's just the wrong >>> tool altogether. >> >> It's indeed slow here, and I agree that's not the problem. Not the tool >> we need, +1. > > 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?) One thing to note is that the referenced wiki page is over a year old. And that many more things have been said on email lists than are actually in that page. But as one note - I don't believe you can drive redmine completely from email, which is certainly a requirement that has been discussed, but is not entirely listed on that page. > Jay, Alvaro, Dimitri (and whoever else wants to speak up) could you > please describe your ideal tool for the task? > > Given that every other existing tool likely have pissed off someone > already, I guess our best bet is writing one from scratch. FWIW, I think the closest thing we've found so far would be debbugs - which IIRC doesn't have any kind of reasonable database backend, which would be a strange choice for a project like ours :) And makes many things harder... -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Bug tracker tool we need (was: Last gasp)
Dimitri Fontaine writes: > Alvaro Herrera writes: >> I've used Redmine a lot, as you know, and I only keep using it because >> it's a requirement at work. It is certainly not close to usable for >> general pgsql stuff. (Trac, which we used to use prior to Redmine, was >> certainly much worse, though). > > Same story here, still using redmine a lot, all with custom reports etc. > >> I can't say that it's all that slow, or that there's a problem with the >> code, or that the search doesn't work right (and I've never had a wiki >> edit disappear, either, and I've used that a lot). It's just the wrong >> tool altogether. > > It's indeed slow here, and I agree that's not the problem. Not the tool > we need, +1. 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?) Jay, Alvaro, Dimitri (and whoever else wants to speak up) could you please describe your ideal tool for the task? Given that every other existing tool likely have pissed off someone already, I guess our best bet is writing one from scratch. 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... -- Regards, Alex [1] http://wiki.postgresql.org/wiki/TrackerDiscussion -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
