On 3/22/22 11:55, Matthew Miller wrote: > 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. It’s worth noting that Bugzilla is used for far more than just RHEL, CentOS Stream, and Fedora. Bugzilla is also used for LVM2, libguestfs, and many other community projects. So I don’t think it will be going away any time soon. That said, it does need to be modernized significantly; for instance, upstream Bugzilla supports Markdown IIRC. -- Sincerely, Demi Marie Obenour (she/her/hers)
Attachment:
OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ 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
