TrackerDiscussion

From PostgreSQL wiki

Revision as of 17:59, 29 May 2011 by Mastermind (Talk | contribs)

Jump to: navigation, 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.

Contents

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 yes yes
Creation of bugs via mail interface optional 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
  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).
Personal tools