On Thu, Sep 24, 2015 at 11:33 AM, Josh Berkus <j...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers