TrackerDiscussion
From PostgreSQL wiki
Jump to navigationJump to searchThis 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
Requirements
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).
- OTRS: Perl, AGPL
- Request Tracker: Perl, GPL
- LibreSource: Java, GPL, no email
- MantisBT: PHP, GPL, no email
- Redmine: Ruby, GPL
- Flyspray: PHP, LGPL, no email
- Roundup: Python, MIT
- Bugzilla: Perl, MPL
- Trac: Python, BSD, no email
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
- Some way of capturing the discussion around feature requests
- Some way of capturing links to the mailing list discussion around feature requests
- Ability to reject feature requests (for historical purposes)
- Link between feature request/discussion and bug that triggered the request
Ease of use for developers
- Low overhead in accessing the system
- Email interface
Including the ability to do the following sorts of things via email- Creating bug
- Changing bug status
- Associating bug with version of Postgres that fixes it
- Associating bug with commit that fixes it
- Associating email thread discussing the bug with the bug
- Some way of uploading content (design plans, &c.)
- Easy way of linking trouble reports together
- Plain delineations (i.e. just the right number of categories, modules, &c.)
- Obvious how to use (not a lot of work to start using)
- Can be used by "experts" (f. doesn't make the tool so dumb that experienced users have to click 43 things all the time.)
- At least as reliable as CVS
- Facilities for flexible "triage" work
Ease of use for community members
- Web interface
- 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.)
- Bug reports are easy to make (don't need to create an account just to file a bug).
