Re: No Issue Tracker - Say it Ain't So!

On Thu, Sep 24, 2015 at 1:25 AM, Thomas Munro
<thomas(dot)munro(at)enterprisedb(dot)com> wrote:
> 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.
>
> Other interactions (curation of unresolved issues, reopening disputed
> issues, resolving issues where the committer or responder forgot to
> use the right magic words, etc etc) could be done via the web
> interface which would initially have only a couple of pages: one for
> paging through issues in different states and one for viewing/editing
> them. (Obviously you could go further and deal with assigning issues
> to people, and adding more states etc etc).
>
> I don't know much about pgweb and friends but it seems like we already
> have a bunch of Python machinery processing all mailing list traffic,
> a database and a webapp doing something pretty closely related. How
> hard would it be to teach it to track issues this way, building on the
> existing infrastructure, compared to rolling out a new separate
> product, and could the result be better integrated?

I think all this sounds pretty cool, frankly. The astute among you
will have picked up on the fact that bug-trackers are not my absolute
favorite piece of technology, but it seems like something of this sort
could be a significant advance over the status quo.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company