Tracker:BugzillaTest

PgTracker Demo Installation

the old demo installation ran on a modified version of Bugzilla 3.0. It is had the following additional features over the stock version:

• full integration with the main website community login feature
• better creation of bugs via the email interface
• integration with the main website bug reporting form via the XML-RPC interface
• modifications to the internal API for some operations (like being able to "impersonate" reporters over the XML-RPC interface to get correct attribution)

basic concepts

pgtracker is currently supposed to be a bug and issue tracker primarily for pgsql-bugs@. It does not intent to replace the mailinglist in any way but it is supposed to augment and support it. To do that the main bug reporting form on the Website is now generating a Bug report using the XML-RPC interface(so that BZ can drive the generation of the bug id which needs to be unique).

The resulting bug is either:

• only made visible to people part of the "Tracker Team" in case it is a normal bug report

• only made visible to people part of the "Security Team" in case it is reported as a security bug

"visible" in this context means that the bug cannot be viewed by the public and needs to be verified by a member of the respective team. Those bugs are initially tagged as UNCONFIRMED which is a special state that will not cause any (email) notifications to be sent. This scheme can support both bugs sent via the bug reporting form and bugs submitted by the native BZ interface. Issues on pgsql-bugs@postgresql.org however tend to generate responses (both "this is not a bug" and "oh yeah this is a bug please try the following patch") pretty quickly - to cope with that the bugzilla installation is subscribed to the mailinglist and will simply add each reply as a comment to the tracker entry.

XXX: discuss handling of mails sent directly to the list

email interface

the bugzilla installation provides an email based interface that can be used or basic interaction with the tracker. The interface is documented here.

this docs lack a bit of information on what fields one can manipulate through that interface so here are some examples:

replying to a bugreport with:

@resolution = INVALID
this is not a bug please look at the docs to find out why

in the body of an email will result in the mentioned bug to get:

• a status of "RESOLVED"
• a resolution of "INVALID"
• a comment of "this is not a bug please look at the docs to find out why"

(selected) list of available commands(all ned to be prefixed with an @ to be recognized by the email interface):

bug_id -- bug identifer (needs to be either in the Subject in the form of "[Bug 1234]" or mentioned in the mail)
short_desc -- sets/updates the summary text of the bug
classification
product -- name of the product (ie PostgreSQL)
version -- PostgreSQL Version
rep_platform
op_sys -- Operating system
bug_status -- Status of the bug (one of RESOLVED,ASSIGNED,REOPENED,CLOSED,VERIFIED)
status_whiteboard
keywords
resolution -- sets the resolution of the bug (one of FIXED, INVALID, WORKSFORME, DUPLICATE, WONTFIX)
bug_severity
priority
component -- component this bug can be attributed too
assigned_to
qa_contact
cc
dependson
blocked
longdesc
content

WARNING: the current version of the email interface will only recognize commands if it is in the very first line of the email

bug states

general descriptions of the available bug states are available here

• UNCONFIRMED (this state is only visible to members of the bug tracker team)
• NEW (this is the default state for all accepted bugs)
• ASSIGNED
• REOPENED
• VERIFIED
• CLOSED

components

• plperl
• plpgsql
• optimizer
• documentation
• psql
• backend
• contrib
• libpq

loose ends

• robustify the email interface
• make the site look prettier
• emails sent directly to the list
• submit some of our modifications to upstream
• deal with people changing their emailaddress in the community login profile
• document that bz can only deal with the emailaddress for login and not the username
• explain the "logged in vs. not" business
• commands are case sensitive ie. "@resolution=wontfix" != "@resolution=WONTFIX"
• automatically handle attachments