I posted this on the Fedora Development mailing list, in the thread RHEL moving to issues.redhat.com only long term, and am re-posting here for broader discussion.
Here’s what I’m thinking: we should plan to migrate to something else in the next three years. There are two reasons for this, and only one of them is that Red Hat is moving away. The second is that Bugzilla isn’t a great tool for what we need anyway.
On the first part: yes, there’s a long, slow sunset, but I think realistically we’re going to see business-side attention drop significantly, and we’ll have correspondingly worse and worse service. Right now, there are basically only two people keeping it all going, which is heroic. I don’t think it’s too much pulling-back-the-corporate-curtain to guess that if one or both get tired of that and decide to go start a yak farm, Red Hat won’t prioritize hiring backfill dedicated in the same way. We could ask CPE to keep it going, but… there’s so much more I’d like to ask CPE. (And non-CPE volunteers? There’s so much that’s more interesting!)
So to the second part: Bugzilla isn’t what we really need anyway.
I’m not saying Bugzilla has been terrible — it’s served us well, in fact. And I have personal fondness for it that, which I do not for, say, the wiki. 
Buzilla is it’s deeply integrated in a lot of our processes, and we’ve got a lot of automations and so on. It’s important. But… there’s a lot that could be better. I think specifically:
-
It doesn’t serve as a single place to track everything. We’ve got stuff scattered around Bugzilla; issue trackers in Pagure GitLab, and GitHub; pull requests in all of those places; and more. Not to mention upstreams (and inconsistent approaches to tracking upstream issues). I’m not arguing that we need ALL things in one place, but it’s important that Bugzilla isn’t that now anyway.
-
Bugzilla a terrible experience for end users. Usually it’s the Wrong Place. When a user has a problem, that may or may not be caused by a software defect. This is a whole topic of its own, but in short, it’s really better for most users to report problems at Ask Fedora, and then possibly after triage a bug should be filed and tracked somewhere.
Many of our users are advanced and recognize real defects and file good reports, but this leads to even more frustration, because our response is inconsistent. Maybe that report should actually be upstream. Maybe it’s in a dependency package that’s really only loosely maintained. For whatever reason, a lot of perfectly good reports end up closed EOL, which is never a good outcome.
-
We’re inconsistent with PRs vs issues, which is confusing and makes more duplication. I have seen cases where a packager complained that someone filed a PR that they never noticed, saying “this should be a bug so I’ll see it”, while others close bugs with “please send a PR”. We could make stronger statements about policies, but as long as these two things exist in separate places, that tension will keep coming back.
Plus plenty of minor things: Our workflow still is shoehorned around a bunch of RH-centric stuff (lots of fields, flags, and statuses that we don’t really use or want). It’s not great for the review workflow, or for some of the other things we’ve twisted it to. A component-centric approach makes it hard to track larger issues. The SCM workflow is … not good.
And I’m sure there’s more. But I’m not really here to complain about Bugzilla. It’s just actually not filling our needs. I therefore think that Jira / issues.redhat.com wouldn’t either — although it’s got a ton of features on top, it’s fundamentally the same kind of thing.
We need define exactly what we do need, and figure out how to get that, in a sustainable way going forward. And fortunately, we DO have a few years, so for once we could do this before it’s a crisis.
I think we should create a project to figure this out. In fact, I think it should be a Fedora Objective. But, it also shouldn’t be a completely blue-sky initiative — we should avoid trying to develop a new gigantic piece of software that we own. (See past results on that, sigh.)
We do have some pieces already in place that should be part of the foundation (or at least other metaphorical bricks in the construction):
-
Ask Fedora is the place for users to report and discuss problems. This is our first-line of support, and it’s where we can do triage. Then, software defects may or may not be tracked relating to those conversations.
-
Package-specific issues should be next to the PRs. Let’s enable issue tracking on src.fedoraproject.org (with whatever gitforge we end up with that on). I think this makes sense for initial package review too, although that would need some workflow changes.
-
Bodhi and the CI results system and all of that. This is update-centric, but does also have a lot of issue-tracker-like characteristcs in the “karma” system, and it is inherently close to our release process. Maybe some of the process that currently goes through Bugzilla could move here.
-
The Fedora account system and Fedora message bus, plus the packager dashboard, the (under significant update!) Fedora notifications system, and so on. We have a nice underlying infrastructure for tying things together, and we can do more integrations. (Look at how Copr uses Discourse, for example. Or the Blocker Bugs app and its connections with Pagure and, um, Bugzilla.)
Obviously that’s not nearly sufficient. But we should look at all of our needs around tracking issues, plans, projects, blockers, and defects; consider different packaging cases with various relationships with upstreams; and imagine ideal workflows for users, packagers, project managers, spin and edition teams, QA, and all the other stakeholders. The last time we did this was in 2013, so… it’s a good 10-years-later exercise! (Infrastructure Fedora bug tracker - Fedora Project Wiki)
Then, once we have a good shared understanding of what we want, start fitting pieces like the above into that picture, define the gaps, and then find exactly what we need to fill them.
