Re: No Issue Tracker - Say it Ain't So! - Mailing list pgsql-hackers

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):
>>
>> http://git.postgresql.org/gitweb/?p=pgweb.git;a=blob;f=pgweb/misc/views.py
>>
>> That is, the database interaction is limited to using a SEQUENCE to
>> generate a new bug ID, and then an email is sent to pgsql-bugs.  What
>> if we also created a bug record for that ID to track its status, and
>> allowed anyone with a community account to edit the bug record and
>> change the status?  There could be a simple page that lets you see and
>> search for bugs, with a link to the flat mail archive thread where
>> discussion is held.  All actual discussion would continue on mailing
>> lists.  That would be similar to the commitfest.
>>
>> I suppose some forms of cross-reference would also be useful: when
>> viewing the bug's page, you might want to see any commitfest items or
>> pgsql-committers messages that relate to that bug.  Perhaps we could
>> automatically create those links when bug IDs are recognised in those
>> messages, so that no extra workflow/maintenance is required in
>
>
> It would be nice if you could essentially promote a bug into a
> commitfest item, maybe through a status change.
>
>
>> straightforward cases.  To continue that line of thinking it would
>> also be possible for bug statuses to be changed when certain words are
>> spotted in either commit messages (which doesn't have to be a commit
>> hook, it could be taken from pgsql-committers messages) or pgsql-bugs
>> messages.
>>
>> Cf github commit message parsing:
>> https://help.github.com/articles/closing-issues-via-commit-messages/
>
> I was thinking along the same lines. If we could paste a bug reference
> number into the commit message and have that change the bug status it
> would go a long way to making this workable I think.

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?

-- 
Thomas Munro
http://www.enterprisedb.com