Re: Getting a bug tracker for the Postgres project
От | Christopher Browne |
---|---|
Тема | Re: Getting a bug tracker for the Postgres project |
Дата | |
Msg-id | BANLkTikLLN1vAPbdbFi+QJ-+JKVB6CzJuA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Getting a bug tracker for the Postgres project (Peter Eisentraut <peter_e@gmx.net>) |
Ответы |
Re: Getting a bug tracker for the Postgres project
Re: Getting a bug tracker for the Postgres project Re: Getting a bug tracker for the Postgres project |
Список | pgsql-hackers |
<p><br /> On 2011-05-30 4:31 PM, "Peter Eisentraut" <<a href="mailto:peter_e@gmx.net" target="_blank">peter_e@gmx.net</a>>wrote:<br /> ><br /> > On sön, 2011-05-29 at 18:36 -0400, Joe Abbate wrote:<br/> > > I've summarizes the main points made in the recent discussion and did<br /> > > some minor additionalresearch on the lists suggested by Peter and<br /> > > Chris Browne. Anyone interested in the tracker, pleasevisit<br /> > > <a href="http://wiki.postgresql.org/wiki/TrackerDiscussion" target="_blank">http://wiki.postgresql.org/wiki/TrackerDiscussion</a>and add your<br /> > > feedback/input.<br /> ><br/> > Based on that, and past discussions, and things we've tried in the past,<br /> > and gut feeling, and soon, it looks like Request Tracker would appear<br /> > to be the next best thing to consider trying out. What do peoplethink<br /> > about that?<p>My suspicion is that RT may be rather a lot heavier weight in terms of how it wouldhave to affect process than people would be happy with.<br /><p>What has been pretty clearly expressed is that variousof the developers prefer for the mailing lists and archives thereof to be the primary data source and the "venue"for bug discussions.<p>RT, and Bugzilla, and pretty well the bulk of the issue trackers out there are designed tothemselves be the "venue" for discussions, and that's not consistent with the preference for email discussions.<p>Thereare Debian packages for RT 3.8, and I imagine it may be worth tossing an instance, but I'd definitelycommend trying to minimize the amount of deployment effort done, as I think there's a fair chance that a numberof devs (I'll pick on Greg Stark :-)) are liable to rebel against it. It'd be interesting to see the reactions tothe interaction between RT, -hackers, and -bugs for a bug or three...<p>I'd be more optimistic that debbugs, or an adaptionthereof, might more nearly fit into the workflow.
В списке pgsql-hackers по дате отправления: