Fitness for purpose
Adamwill (talk) "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." - well sure, but then so is Bugzilla. We just got used to it. But it's not designed for a Linux distribution at all. It's really not meant to cope with a 10000-item long component list, for instance - one of the major sources of slowness of our BZ instance. It basically has one fewer 'product-ish' field than we need, so we can't split the bugs of large source packages up: this is a major and ongoing source of problems for the kernel team, for instance, because we have no good way to file wifi bugs separately from graphics bugs separately from networking bugs separately from etc etc etc.
BZ has no kind of working upstream integration at all. The External Tracker thing just doesn't work and hasn't for as long as I can remember.
BZ has no sensible way to track the same bug across multiple Fedora releases.
I just don't think this is a plus point for BZ, at a minimum. We've gotten used to dealing with BZ's limitations in respect to using it as a distribution bug tracker, but its limitations are just as significant as any other general-purpose bugtracker's in this context.
I hate to throw in a possibly incendiary topic, but there exists a F/OSS issue tracking system which is specifically developed for use by Linux distributions, and addresses many of the limitations I listed above. It's called Launchpad. I note that it wasn't on the list of possible alternatives.
Kevin We did think about that, I'll add a note about it. ;)
tflink Adam does bring up a good point, though. IF we end up moving out of RHBZ, it's going to be a huge amount of effort, even if we end up migrating to another bugzilla instance.
If we're going to do the work, I think it would be good to look at how we could improve our usage of an issue tracker if we weren't constrained to RHBZ:
- bugs affecting multiple releases
- bugs affecting multiple components
- bugs affecting multiple arches
- better concept of teams?
- allow for assignment to a team and/or an individual
- better integration with blocker process
- sub-component classification (something finer grained than the current component)
- more sanity in matching srpms to pkggit repos to bug "components"
I'm sure there are other things we could do, this is just the list of things that came to mind. Migration strategy is another thing that we might want to think about - not when it would happen but the kinds of tasks that would need to happen and how we would approach migration off of rhbz (after X date, no new bugs in rhbz; both places for a while; how we would migrate bugs if the metadata structure changed etc.)
eseyman Tflink, I'ld add "better integration with Fedora's feature process" to your list (not sure I care much for assignement to a team, though).
State of this page
It looks abandoned and outdated to me, can we delete or archive this page? Archival would ideally be done in a way that it doesn't clutter google results, I was searching for the "infrastructure tracker fedora" and landed here. Not what I searched for for sure. (Just added a link to the tracker in pagure.)--Dreua (talk) 19:47, 15 May 2021 (UTC)