On Wed, Jul 1, 2026 at 12:02 PM Kashyap Chamarthy <[email protected]> wrote: > > On Wed, Jul 01, 2026 at 08:25:04AM -0400, Neal Gompa wrote: > > On Wed, Jul 1, 2026 at 7:25 AM Kashyap Chamarthy <[email protected]> > > wrote: > > > > > > On Wed, Jul 01, 2026 at 06:13:47AM -0400, Neal Gompa wrote: > > [...] > > > > You seem to talk as if "Fedora contributors" and "Fedora itself" are > > > distinct entities. (I don't know if you're referring to Council or > > > something else). And active community-building requires "personpower", > > > the trade-offs involved: whether it makes _sense_ to do it, _who_ should > > > do it, who has the time to do it, and so on. > > > > > > > They are. If a contributor does something and wants to amplify it > > through Fedora, it requires support from the project entity to do > > that. This is a difficult thing to do today. > > I see what you mean, but "someone" from the "project entity" has to do > that amplification, which is usually some kind of marketing with some > funding. (Or, if you're an enterprising maintainer you take the matters > into hands yourself by blogging, etc.) >
Yes, I'm saying that people need to expect to just do it and fund it themselves rather than expecting Fedora to help them there. I learned this the hard way over the past several years working on both community infrastructure and deliverables in Fedora. > [...] > > > It's not. In a corporate environment, non-self-service MFA reset isn't > > as big of a deal because the scale and operational model is simpler. > > That said, if your company uses Google or Microsoft SSO, then you get > > it anyway if your site admin hasn't blocked it. I have only > > encountered one place that did, and that was because of unique > > security requirements that they had. > > > > And it has been asked before[1][2]. It was also part of the > > conversation at the FESCo level too[3]. > > Thanks for these links. I and others agree that self-service recovery > is important and it was already discussed on the 2FA thread. > > As for the first issue[1] you link below, Alexander already has patches > for passkey support. He's waiting for someone to test them: > > https://github.com/fedora-infra/noggin/issues/579 > That's not really an answer to the problem, also I'm not going to use passkeys, at least for now. It just complicates things for me, and the libfido2 passkey support is incompatible with most password managers. The point of the link is that self-service recovery+reset is table stakes for 2FA and not having it is a serious problem. > > [1]: https://github.com/fedora-infra/noggin/issues/579 > > [2]: > > https://lists.fedoraproject.org/archives/list/[email protected]/message/4LMIC5XF7XBFIG563DN7IZIVMBNGZLQD/ > > [3]: https://forge.fedoraproject.org/fesco/tickets/issues/3186 > > [...] > > > > This sounds like you are framing your personal take as "universal > > > truth". There's only so much energy and time to "build". As always, > > > it's a matter of figuring out the trade-offs involved. > > > > > > > You make it sound like I don't know that. > > Sorry, I forgot to add the prefix "as you know" ;-) > > > I certainly do, but lately the idea of "worse is better" has taken > > root here. > > This is uncharitable rhetoric. I understand you may be frustrated, but > you won't be winning friends and influencing upstreams by rubbing > blanket blame like this. > And the other approaches haven't worked either. "Uncharitable" implies lack of evidence or experience, but this has been the experience for *years*. > > Like the idea of using the forge tracker for Fedora bugs. It's a major > > downgrade for triage, tracking, and even bug lifecycling, because > > forge trackers are designed to be lightweight alternatives with a > > significantly weaker data model. They aren't designed to be a > > replacement for Bugzilla, they are designed to be a replacement for > > TODO files. > > That last bit sounds absurd. Codeberg has over 150,000 repos with the > same engine. I don't believe they're all simple "TODO" tracking. > > Since Fedora stays close to the upstream, the no. of Fedora-specific > issues per component should, in theory, be light enough for the Forge to > handle it. (I admit, I haven't studied the full depth of Forgejo > capabilities. I'm assuming that's going to be the case based on my > experience with it so far and from browsing Codeberg repos/issues.) > > Regardless. In 2026, it's a no-brainer to have issues and code live > next to each other. > No, it really isn't. If that were true, Jira, YouTrack, Mantis, Bugzilla, and other solutions would be solidly dead. It only makes sense if there's not much in the way of large scope processes and few actors. That is not how it works for us in Fedora. > > KDE's evaluation is notable because it crosses into the same issues we > > have: > > https://community.kde.org/Get_Involved/Issue_Reporting/Why_not_GitLab_Issues > > I don't deny there are no issues; it's what issues can we live with, > while moving on from ultra-legacy systems that are slowly dying. > As I've already said, this isn't true, and there's plenty of evidence to indicate it isn't. > > What keeps happening is that feedback is ignored and it is pressed on > > and it turns into a mess. I agree Red Hat Bugzilla is in a bad state > > and we need to have our own tracker, but I would rather us seriously > > consider just running our own Bugzilla instance and working with the > > upstream developers to incorporate the RHBZ features we use into > > mainline Bugzilla. > > More work and it's untenable, given the limited amount of engineering > time available. > We can also just pay the Bugzilla folks[1] (Dave Miller has a business for developing and hosting Bugzilla[2]), like we do Discourse folks and Element/Matrix folks. It would be silly to say we can pay for Discourse but we can't pay for Bugzilla. [1]: https://www.bugzilla.org/support/consulting.html [2]: https://justdaveitconsulting.com/ > > Likewise with the Changes process, I think that the trivial to create > > and update features of a wiki are incredibly valuable, even if > > wikitext isn't the favored way of writing anymore. But MediaWiki can > > be extended to support other markups, and there has been a Markdown > > extension in the past[4]. The extension is dead now, but it could be > > forked, updated, and Fedora-flavored Markdown could be integrated into > > it so that we have the clever little things for linking to packages > > and Matrix/IRC chats, and whatnot. > > This is still in debate; so maybe the above route is those working on > this might end up take. Remains to be seen. > > [...] > > > > > I also can't see it being a good idea to make it more difficult for > > > > contributors, either. To be honest, I'd rather just keep the wiki and > > > > maybe invest in an extension to support Markdown in the Fedora wiki. > > > > The backlinking and historical data is incredibly valuable. > > > > > > Agreed, this is a important point -- to preserve the backlinks and > > > historical archives of the Wiki. But that doesn't mean we have to > > > _stay_ on the Wiki forever. We could mark it as read-only and move to > > > Git-based, efficient workflows. (I know, this raises the bar for the > > > technically-inclined to edit pages. So it's an open question whether we > > Missing a word here: I meant "technically *less*-inclined" here. > It isn't wrong, though. It raises the bar for *everyone*. You just don't necessarily notice it. There are plenty of technical people who aren't really good at or able to work with those workflows. And Git workflows being "efficient" is a matter of opinion. Opinions on that for documentation wildly vary. -- 真実はいつも一つ！/ Always, there's only one truth! -- _______________________________________________ devel mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected] Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
