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

On Thu, Sep 24, 2015 at 11:33 AM, Josh Berkus <josh@agliodbs.com> wrote:
> On 09/23/2015 03:05 PM, Jim Nasby wrote:
>> On 9/23/15 3:12 PM, Thomas Kellerer wrote:
>>> They also support Postgres as their backend (and you do find hints
>>> here and
>>> there
>>> that it is the recommended open source DBMS for them - but they don't
>>> explicitly state it like that). We are using Jira at the company I
>>> work for
>>> and
>>> all Jira installations run on Postgres there.
>>
>> I'll second Jira as well. It's the only issue tracker I've seen that you
>> can actually use for multiple different things without it becoming a
>> mess. IE: it could track Postgres bugs, infrastructure issues, and the
>> TODO list if we wanted, allow issues to reference each other
>> intelligently, yet still keep them as 3 separate bodies.
>
> Speaking as someone who uses Jira for commericial work, I'm -1 on them.
>  I simply don't find Jira to be superior to OSS BT systems, and inferior
> in several ways (like that you can't have more than one person assigned
> to a bug).  And email integration for Jira is nonexistant.
>
> When we discussed this 8 years ago, Debian said debbugs wasn't ready for
> anyone else to use.  Has that changed?

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
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/

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