* Josh Berkus (josh@agliodbs.com) wrote:
> I know we're big on reinventing the wheel here, but it would really be a
> better idea to use an established product than starting over from
> scratch. Writing a bug tracker is a lot of work and maintenance.
I tend to agree.
> > The two most common interactions could go something like this:
> >
> > 1. User enters bug report via form, creating an issue in NEW state
> > and creating a pgsql-bugs thread. Someone responds by email that this
> > is expected behaviour, not a bug, not worth fixing or not a Postgres
> > issue etc using special trigger words. The state is automatically
> > switched to WORKS_AS_DESIGNED or WONT_FIX. No need to touch the web
> > interface: the only change from today's workflow is awareness of the
> > right wording to trigger the state change.
> >
> > 2. User enters bug report via form, creating issue #1234 in NEW
> > state. Someone responds by email to acknowledge that that may indeed
> > be an issue, and any response to an issue in NEW state that doesn't
> > reject it switches it to UNDER_DISCUSSION. Maybe if a commitfest item
> > references the same thread (or somehow references the issue number?)
> > its state is changed to IN_COMMITFEST, or maybe as you say there could
> > be a way to generate the commitfest item from the issue, not sure
> > about that. Eventually a commit log message says "Fixes bug #1234"
> > and the state automatically goes to FIXED.
>
> I don't know debbugs, but I know that it would be possible to program RT
> to do all of the above, except add the item to the commitfest.
debbugs does most of the above by default, no programming needed... I'm
sure we could get it to integrate with the commitfest and have a git
commit hook which sends the appropriate email to it also.
That the emacs folks are using it makes me *much* more interested in the
idea of getting debbugs up and running..
Thanks!
Stephen
