m (Kevin moved page Infrastructure FedoraBugzilla to Infrastructure Fedora bug tracker: we might not use Bugzilla, make the page more generic.) |
(rework to be more generic) |
||
Line 14: | Line 14: | ||
been made, this is in a information gathering stage at this point. | been made, this is in a information gathering stage at this point. | ||
== | == Other bug tracking systems == | ||
If Fedora went to managing it's own bug tracking system, is bugzilla the | If Fedora went to managing it's own bug tracking system, is bugzilla the | ||
Line 49: | Line 49: | ||
Advantages: email gateway support, ability to craft schema/templates for our needs, smaller footprint, python, ability to run seperate trackers per component. | Advantages: email gateway support, ability to craft schema/templates for our needs, smaller footprint, python, ability to run seperate trackers per component. | ||
== Features / | == Features needed/wanted. == | ||
=== MUST HAVE === | |||
These items are required in any solution we offer: | |||
* fedmsg support | * fedmsg support | ||
* openid / fas support (possibly via persona support) | * openid / fas support (possibly via persona support) | ||
* Support current maintainer / qa / release engineering / program manager workflows or provider better workflows. | |||
=== SHOULD HAVE === | |||
These items are things we really should provide, but we might be willing to not have them if there's workarounds: | |||
* Support for all infrastructure scripts that need to interface with the bug tracking system. | |||
* Way to move bugs from one component to another. | |||
* ability to note an upstream bug in upstream bug trackers. | |||
* support all the maintainer / qa states bugs can/should be in. | |||
=== Nice to have === | |||
These are things we would find nice to have, but aren't required right away: | |||
* subcomponent support? | * subcomponent support? | ||
** ie, kernel could have networking and filesystems with different owners | ** ie, kernel could have networking and filesystems with different owners | ||
* | * Retheme and branded to match the other fedora project web tools | ||
* | * email support for reporting/updating bugs with gpg signed emails. | ||
* | * ability to mark a bug affecting multiple releases. | ||
=== Wishlist / Future === | |||
* | |||
These are things we would like to have someday, but they aren't critical to an initial release: | |||
* way to archive old releases to static pages to avoid rendering time/queries. | |||
* Possibly add caching (may be difficult to do correctly). | * Possibly add caching (may be difficult to do correctly). | ||
== Problems/issues == | == Problems/issues == | ||
Line 71: | Line 92: | ||
* when a bug is mis-assigned to an epel pkg (in fedora) can't reassign to rhel | * when a bug is mis-assigned to an epel pkg (in fedora) can't reassign to rhel | ||
* security bugs cannot easily refer to both rhel/fedora versions. | * security bugs cannot easily refer to both rhel/fedora versions. | ||
* Database knowledge low on team, would need to figure out replication/ha. | * Database knowledge low on team, would need to figure out replication/ha. | ||
* would need to somehow keep python-bugzilla in sync with both new instance, and b.z.c | * would need to somehow keep python-bugzilla in sync with both new instance, and b.z.c |
Revision as of 19:17, 29 April 2013
Bugzilla/Issue Tracking in Fedora
Background
Fedora currently shares a bugzilla instance with Red Hat. This instance is managed and run by Red Hat. Some new features or changes that would assist Fedora are not a priority for this instance, which must focus on business needs. This page is an attempt to summarize the advantages and disadvantages in Fedora running their own seperate Bugzilla instance. No decisions have been made, this is in a information gathering stage at this point.
Other bug tracking systems
If Fedora went to managing it's own bug tracking system, is bugzilla the best fit for this use?
Most of the other free bug / issue tracking systems are a poor fit for a distribution managing a large number of components that additionally have their own upstreams.
Some other systems that don't really fit:
- redmine: ruby, not packaged yet for epel.
- trac: poor performance, has a bunch of additional things over bug tracking we don't need.
- flyspray: dead upstream.
- mantis: php-based
- rt: perl based, much more trouble ticketing than software bugs.
- launchpad: has a number of downsides for us. Big ones: "Building and running Launchpad requires a computer running Ubuntu" and it includes a bunch more things that we don't need like bzr integration, personal archives, etc.
- allura: (powers sourceforge). Provides a bunch of stuff we don't need like source code control, forums, mailing lists, etc.
Possible ones that do:
- roundup: written in python (python issue tracker), designed to be flexible, ability to interact with bugs via more than just web interface or XML-RPC.
The main disadvantages with roundup would be : very foreign to existing contributors, impedance mismatch with RHBZ for bugs that exist in both trackers, require rewriting a bunch of tools.
Advantages: email gateway support, ability to craft schema/templates for our needs, smaller footprint, python, ability to run seperate trackers per component.
Features needed/wanted.
MUST HAVE
These items are required in any solution we offer:
- fedmsg support
- openid / fas support (possibly via persona support)
- Support current maintainer / qa / release engineering / program manager workflows or provider better workflows.
SHOULD HAVE
These items are things we really should provide, but we might be willing to not have them if there's workarounds:
- Support for all infrastructure scripts that need to interface with the bug tracking system.
- Way to move bugs from one component to another.
- ability to note an upstream bug in upstream bug trackers.
- support all the maintainer / qa states bugs can/should be in.
Nice to have
These are things we would find nice to have, but aren't required right away:
- subcomponent support?
- ie, kernel could have networking and filesystems with different owners
- Retheme and branded to match the other fedora project web tools
- email support for reporting/updating bugs with gpg signed emails.
- ability to mark a bug affecting multiple releases.
Wishlist / Future
These are things we would like to have someday, but they aren't critical to an initial release:
- way to archive old releases to static pages to avoid rendering time/queries.
- Possibly add caching (may be difficult to do correctly).
Problems/issues
- Free sysadmin/dev cycles already low
- Could end up being slower due to lack of resources
- cannot clone bugs over to rhel packages/products easily.
- when a bug is mis-assigned to an epel pkg (in fedora) can't reassign to rhel
- security bugs cannot easily refer to both rhel/fedora versions.
- Database knowledge low on team, would need to figure out replication/ha.
- would need to somehow keep python-bugzilla in sync with both new instance, and b.z.c
- we don't have much perl dev depth in our team and bz is all perl
help that would be needed
- db people
- perl hackers
- bugzilla experenced admins.
- bugzilla and deps packagers for epel.
- load and functionality testing scripts (selenium, pymechanize, etc)