From Fedora Project Wiki
| Line 24: | Line 24: | ||
Some other systems that don't really fit: | Some other systems that don't really fit: | ||
* redmine: ruby, not packaged yet for epel. | * [http://www.redmine.org/ redmine]: ruby, not packaged yet for epel. | ||
* trac: poor performance, has a bunch of additional things over bug tracking we don't need. | * [http://trac.edgewall.org/ trac]: poor performance, has a bunch of additional things over bug tracking we don't need. | ||
* flyspray: dead upstream. | * [http://www.flyspray.org/doku.php flyspray]: dead upstream. | ||
* mantis: | * [http://www.mantisbt.org/ mantis]: php-based | ||
* rt: perl based, much more trouble ticketing than software bugs. | * [http://www.bestpractical.com/rt/ rt]: perl based, much more trouble ticketing than software bugs. | ||
* fossil | * [http://www.fossil-scm.org/xfer/doc/trunk/www/index.wiki fossil]: | ||
* 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. | * [https://launchpad.net/ 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. | ||
* | * [https://incubator.apache.org/allura/ allura]: (powers sourceforge). Provides a bunch of stuff we don't need like source code control, forums, mailing lists, etc. | ||
* [http://roundup.sourceforge.net/ roundup]: written in python ([http://bugs.python.org/ python issue tracker]), designed to be flexible, ability to interact with bugs via more than just web interface or XML-RPC. | |||
The main disadvantages would be 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. Theming is a bit of a pain, but is possible. How much the flexibility would work for us and how much pain we'd be looking at when upgrading would require more in-depth investigation. | |||
Theming is a bit of a pain, but is possible. How much the flexibility would work for us and how much pain we'd be looking at when upgrading would require more in-depth investigation. | |||
== Features /advantages == | == Features /advantages == | ||
Revision as of 15:03, 29 March 2013
THIS IS A DRAFT
PLEASE EDIT AND ADD HELPFUL CONSTRUCTIVE POINTS
PLEASE EDIT AND ADD HELPFUL CONSTRUCTIVE POINTS
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.
Why not another bug tracking system
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.
- 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 would be 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. Theming is a bit of a pain, but is possible. How much the flexibility would work for us and how much pain we'd be looking at when upgrading would require more in-depth investigation.
Features /advantages
- fedmsg support
- openid / fas support (possibly via persona support)
- subcomponent support?
- ie, kernel could have networking and filesystems with different owners
- Could rework fields or workflow that don't make sense for fedora.
- could drop or modify states for qa needs.
- Might get better response time.
- could archive old bugs as we wish.
- upgrades and changes could be on Fedora's schedule
- Could reduce load/issues with bugzilla.redhat.com
- Possibly add caching (may be difficult to do correctly).
- Retheme and branded to match the other fedora project web tools
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.
- Need to maintain our own up to date packages of bugzilla/deps.
- 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)