On Thu, Sep 24, 2015 at 1:25 AM, Thomas Munro <thomas.mu...@enterprisedb.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
