On Tue, Mar 15, 2022 at 07:17:16AM -0400, Josh Boyer wrote: > If you mean try having a conversation with the community before > something goes into effect... that's what this thread is. Depending > on how you count, at least a year in advance if not 3. I was going to reply last week, but last week kind of turned out to be One Of Those Weeks. 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: 1. 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. 2. 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. 3. 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): 1. 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. 2. 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. 3. 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. 4. 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! (https://fedoraproject.org/wiki/Infrastructure_Fedora_bug_tracker) 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. -- Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx> Fedora Project Leader _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
