TrackerDiscussion

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
=== 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 <BR> 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).
Category:Community