On 09/23/2015 10:25 PM, Thomas Munro wrote:
> On Thu, Sep 24, 2015 at 1:31 PM, Joe Conway <mail@joeconway.com> wrote:
>> On 09/23/2015 05:21 PM, Thomas Munro wrote:
>>> Do you think it would make any sense to consider evolving what we have
>>> already? At the moment, we have a bug form, and when you submit it it
>>> does this (if I'm looking at the right thing, please correct me if I'm
>>> not):
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.
> 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.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
