Re: Commit fest queue - Mailing list pgsql-hackers
From | Stefan Kaltenbrunner |
---|---|
Subject | Re: Commit fest queue |
Date | |
Msg-id | 47FE1FBB.3030704@kaltenbrunner.cc Whole thread Raw |
In response to | Re: Commit fest queue (Andrew Dunstan <andrew@dunslane.net>) |
Responses |
Re: Commit fest queue
|
List | pgsql-hackers |
Andrew Dunstan wrote: > > > Alvaro Herrera wrote: >> Stefan Kaltenbrunner wrote: >> >> >>> well what about having the tracker being subscribed to the list and >>> let it create a bug/patch/ticket id automatically for new mails - >>> that way all stuff is automatically tracked ? - That way it can be >>> categorized in the course of the following discussion but no history >>> gets lost. >>> >> >> This is (more or less) what the Tracman system proposed by Josh Drake >> does -- and it's awful IMHO. Amusingly, it's also more or less the same >> thing that debbugs does, which IMHO is really good. >> >> The main difference (again IMHO) is that Tracman tries to stuff the info >> in Trac comments, so it has to forcefully extract things from the email >> with rather poor results; whereas debbugs uses the mbox itself as the >> definite storage. >> >> Note that neither are really "subscribed" to the lists; rather they are >> some sort of gatekeepers, which process the email *before* they get to >> the list. (Actually, AFAIK in debbugs there is no actual mail list -- >> it's all mainly about appropriate CC's.) >> >> > > The issue frankly is not tracker features. The issue is who is going to > maintain it, doing pruning and triage as necessary. No tracker looks > after itself. heh very true ... > > Everybody has their favorite tracker (editor, OS, SCM, ...) ... we can > have endless fun debating them backwards and forwards and never reach a > conclusion, just as we do fairly regularly. The consensus last year > among a group of us who examined a number of tracker systems was, IIRC, > that Bugzilla had the best combination of features that people had > requested. (And it does have some email interaction). Stefan > Kaltenbrunner did some work on putting up a test instance and played > with integrating it with the Postgres bug system - I forget how far > exactly he got. the setup is more or less complete and the integration part was with the community login system (same we have now for wiki.postgresql.org) by adding a postgresql authentication backend as well as some experimental modifications to the email_in.pl script to enable autocreation of bugs from email. I did't push it further (or put it to a silent trial on say -bugs which is way less complex than -patches but might give us some ideas on the usability anyway) because I was fairly busy at the time and could not probably support it on a larger scale and it is far from clear that we actually want something like that. > > My understanding BTW is that debbugs is very specifically tailored to > Debian needs, and is not suitable as a general purpose tracker system. > And no other OSS project that we could find uses it. So, before we even > look at it again I at least would want concrete proof that these things > have changed. (Perhaps Alvaro has forgotten those discussions ;-) ) yeah that is my impression as well. > > (And yes, Trac sucks) +1 Stefan
pgsql-hackers by date: