From PostgreSQL wiki
Jump to navigationJump to search

This is purely a space to dump some of the stuff that was discussed on the now defunct tracker list and has no real official character.

See Tracker:BugzillaTest for information on our test tracker.

Discussion Points

This is a summary of major points made in the pgsql-hackers thread here


Listed in approximate order of general acceptance:

  • Free/open source software (PE)
  • Must run on PostgreSQL (GSM)
  • Must have an email interface (GSM)
    • Provide interface to turn a CCd or forwarded email into bug report (SK)
  • Via web interface, associate status with each bug (RH)
    • Suggested statuses: "OPEN", "FIXED", "NOTABUG", "WONTFIX" (RH)
  • Given bug number, find emails in pgsql-bugs that mention it in Subject line (RH)

Questions (with some responses)

  • People report bugs outside of web interface or mailing pgsql-bugs. How to keep track of those? (TGL)
    • First-pass triage done by moderately experienced users (BJ) [Implication: not everything needs to be tracked]
    • Many hackers/users will sign up for a reasonable tracker if available (PE)
    • A "moderately experienced user" may forward a copy of the email to the bug tracker in order to get it tracked
  • Who is going to keep it up to date? (TGL)
    • "Bug wrangler(s)" could devote 20 mins a day (BJ)

Disadvantages of Current Situation

Per Greg Sabino Mullane:

  • No way to search previous / existing bugs
  • No way to tell the status of a bug
  • No way to categorize and group bugs (per version, per platform, per component, per severity, etc.)
  • No way to know who is working on a bug
  • No way to prevent things from slipping through the cracks

"Buy" Option Short List

Suggested by Peter Eisentraut, from Wikipedia list. Includes implementation language, license and indication whether it does not have an email interface (according to Wikipedia).

Other mentions, by Chris Browne:

  • Fossil: SCM + bug tracking, C, BSD, SQLite
  • SD (Simple Defects): P2P bug tracker, Perl, MIT, SQLite or FS backend
  • Bugs Everywhere: distributed bug tracker, Python, GPL, uses DVCS for storage
  • debbugs: Perl, GPL, Berkeley DB, main interface for interaction is email

Previous Content

To be merged as needed.

basic criteria

basic technical and operational requirements

  • must work on common unix platforms
  • must support postgresql as a backend
  • must require no/minimal customization work for community adoption
  • must have community login integration

Management of bugs and issues

Requirement (yes/no/optional) Bugzilla 3.0
Creation of bugs yes yes
Creation of bugs via web interface optional yes
Creation of bugs via mail interface yes yes
Creation of bugs via external interface optional yes
Ability to query open bugs yes yes
Ability to query open bugs via web interface yes yes
Ability to query open bugs via external interface yes yes(SOAP/XML-RPC)
Ability to query historical bug data yes yes
Ability to change/set bug status yes yes
Ability to set and track people working on a given bug yes yes
Ability to categorize bugs by severity and release yes yes
Ability to moderate bug listing (not listed publicly until evaluator accepts) yes ?
Full-text searching of bug reports yes ?
Links to source control system events optional ?

Management of feature requests

Requirement (yes/no/optional) Bugzilla 3.0
Creation of feature requests yes yes
Creation of feature requests via web interface yes yes
Creation of feature requests via mail interface yes yes
Creation of feature requests via external interface optional yes (soap/XML-RPC)

Record Keeping

  1. Some way of capturing the discussion around feature requests
  2. Some way of capturing links to the mailing list discussion around feature requests
  3. Ability to reject feature requests (for historical purposes)
  4. Link between feature request/discussion and bug that triggered the request

Ease of use for developers

  1. Low overhead in accessing the system
  2. Email interface
    Including the ability to do the following sorts of things via email
    1. Creating bug
    2. Changing bug status
    3. Associating bug with version of Postgres that fixes it
    4. Associating bug with commit that fixes it
    5. Associating email thread discussing the bug with the bug
  3. Some way of uploading content (design plans, &c.)
  4. Easy way of linking trouble reports together
  5. Plain delineations (i.e. just the right number of categories, modules, &c.)
  6. Obvious how to use (not a lot of work to start using)
  7. Can be used by "experts" (f. doesn't make the tool so dumb that experienced users have to click 43 things all the time.)
  8. At least as reliable as CVS
  9. Facilities for flexible "triage" work

Ease of use for community members

  1. Web interface
  2. Communications about bugs are regular and understandable (no "report/request to black hole")

Ease of use for "non-community members" (e.g. new users, users who don't follow mailing lists regularly, &c.)

  1. Bug reports are easy to make (don't need to create an account just to file a bug).