From Fedora Project Wiki

(This page is the first google hit for "infrastructure tracker fedora", therefore adding at least a link to that)
 
(13 intermediate revisions by 6 users not shown)
Line 1: Line 1:
 
{{admon/important|If you are looking for the infrastructure issue tracker| https://pagure.io/fedora-infrastructure/issues}}
{{admon/important|THIS IS A DRAFT|PLEASE EDIT AND ADD HELPFUL CONSTRUCTIVE POINTS}}
{{admon/important|THIS IS A DRAFT|PLEASE EDIT AND ADD HELPFUL CONSTRUCTIVE POINTS}}


= Bugzilla/Issue Tracking in Fedora =
= Bugzilla/Issue Tracking in Fedora =
Line 14: Line 13:
been made, this is in a information gathering stage at this point.
been made, this is in a information gathering stage at this point.


== Why not another bug tracking system ==
== Bugzilla.redhat.com pain points ==
 
We should note here pain points or issues with current bugzilla. We may be able to get the bugzilla team to help fix or work around them.
 
* There's sometimes private bugs cloned to Fedora components. Can we clear those flags when Fedora is the component?
* fedmsg integration
* openid logins
 
== Why does Fedora need its own BZ? ==
 
(This is to list out issues that the community faces with shared BZ instance with RH, and the points which make it easier to decide to host Fedora's own instance. Please list out exact features missing/wanted which are not available in RH instance rather than just saying more/better features.)
 
  *
  *
 
== 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  
best fit for this use?  
best fit for this use?  
Line 24: Line 39:
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.
 
* [http://trac.edgewall.org/ trac]: poor performance, has a bunch of additional things over bug tracking we don't need.  


* trac: poor performance, has a bunch of additional things over bug tracking we don't need.  
* [http://www.flyspray.org/doku.php flyspray]: dead upstream.  


* flyspray: dead upstream.  
* [http://www.mantisbt.org/ mantis]: php-based


* mantis:  
* [http://www.bestpractical.com/rt/ rt]: perl based, much more trouble ticketing than software bugs.


* rt: perl based, much more trouble ticketing than software bugs.  
* [http://www.fossil-scm.org/xfer/doc/trunk/www/index.wiki fossil]:


* fossil
* [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.


* 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.  


* Allura: (powers sourceforge). Provides a bunch of stuff we don't need like source code control, forums, mailing lists, etc.  
* [http://www.thebuggenie.com/ buggenie]: php-based
Possible ones that do:


=== Another Possibility ===
* [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.


[http://roundup.sourceforge.net/ Roundup] might be another possibility - it's written in python, used for the [http://bugs.python.org/ python.org issue tracker] and is designed to be flexible.
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.


Assuming that it would end up being a good fit for Fedora, the main advantages of roundup over bugzilla would be:
Advantages: email gateway support, ability to craft schema/templates for our needs, smaller footprint, python, ability to run seperate trackers per component.
* written in python instead of perl to better leverage existing experience
* flexible enough to do at least most of what we want
* ability to interact with bugs via more than just web interface or XML-RPC


The main disadvantages would be:
== Features needed/wanted.  ==
* Lack of experience with roundup
* It's not bugzilla
** very foreign to existing contributors
** probably have some 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.
=== MUST HAVE ===


== Features /advantages ==
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.
** Way to file bugs against any shipped component for users.
** Way to mark bugs as blockers or FE's
** Way to make sure anyone intrested gets email for bugs and updates on bugs.
** Way to move between components
** Way to mark bugs needing scm admin attention.
** Way to mark bugs under review / approved / rejected for package reviews
** Way to mark status on bugs per whatever workflow.
** Way to reassign bugs to someone else.
** Way to note information needed and from whom
** Must have a way for bodhi to note when a update is tied to a bug and what state it's in.
=== 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.
* Interaction with abrt/faf
=== 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
* Could rework fields or workflow that don't make sense for fedora.
* Retheme and branded to match the other fedora project web tools
** could drop or modify states for qa needs.  
* email support for reporting/updating bugs with gpg signed emails.  
* Might get better response time.  
* ability to mark a bug affecting multiple releases.  
* could archive old bugs as we wish.
 
* upgrades and changes could be on Fedora's schedule
=== Wishlist / Future ===
* Could reduce load/issues with bugzilla.redhat.com
 
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).
* Retheme and branded to match the other fedora project web tools


== Problems/issues ==
== Problems/issues ==
Line 77: Line 115:
* Free sysadmin/dev cycles already low
* Free sysadmin/dev cycles already low
* Could end up being slower due to lack of resources
* Could end up being slower due to lack of resources
* cannot clone bugs over to rhel packages/products easily.  
* cannot clone bugs over to rhel packages/products easily. <-- This is irrelevant to Fedora
* 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 <-- This is irrelevant to Fedora
* security bugs cannot easily refer to both rhel/fedora versions.  
* security bugs cannot easily refer to both rhel/fedora versions. <-- No need to RHEL != Fedora there can be much newer releases of the components in Fedora then in RHEL
* Need to maintain our own up to date packages of bugzilla/deps.
* 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
* we don't have much perl dev depth in our team and bz is all perl  
* we don't have much perl dev depth in our team and bz is all perl


== help that would be needed ==  
== help that would be needed ==  
Line 92: Line 129:
* bugzilla and deps packagers for epel.  
* bugzilla and deps packagers for epel.  
* load and functionality testing scripts (selenium, pymechanize, etc)
* load and functionality testing scripts (selenium, pymechanize, etc)
== Next steps ==
* Need to collect more things in the Features needed section of this page.
* Need to setup some proof of concept bugzilla and roundup instances to test ideas with.
[[Category:Infrastructure Planning]]

Latest revision as of 19:45, 15 May 2021

If you are looking for the infrastructure issue tracker
https://pagure.io/fedora-infrastructure/issues
THIS IS A DRAFT
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.

Bugzilla.redhat.com pain points

We should note here pain points or issues with current bugzilla. We may be able to get the bugzilla team to help fix or work around them.

  • There's sometimes private bugs cloned to Fedora components. Can we clear those flags when Fedora is the component?
  • fedmsg integration
  • openid logins

Why does Fedora need its own BZ?

(This is to list out issues that the community faces with shared BZ instance with RH, and the points which make it easier to decide to host Fedora's own instance. Please list out exact features missing/wanted which are not available in RH instance rather than just saying more/better features.)

  * 
  *

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.
  • 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.
    • Way to file bugs against any shipped component for users.
    • Way to mark bugs as blockers or FE's
    • Way to make sure anyone intrested gets email for bugs and updates on bugs.
    • Way to move between components
    • Way to mark bugs needing scm admin attention.
    • Way to mark bugs under review / approved / rejected for package reviews
    • Way to mark status on bugs per whatever workflow.
    • Way to reassign bugs to someone else.
    • Way to note information needed and from whom
    • Must have a way for bodhi to note when a update is tied to a bug and what state it's in.

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.
  • Interaction with abrt/faf

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. <-- This is irrelevant to Fedora
  • when a bug is mis-assigned to an epel pkg (in fedora) can't reassign to rhel <-- This is irrelevant to Fedora
  • security bugs cannot easily refer to both rhel/fedora versions. <-- No need to RHEL != Fedora there can be much newer releases of the components in Fedora then in RHEL
  • 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)

Next steps

  • Need to collect more things in the Features needed section of this page.
  • Need to setup some proof of concept bugzilla and roundup instances to test ideas with.