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: > > On Wed, Jul 1, 2026 at 4:49 AM Daniel P. Berrangé <[email protected]> > > wrote: > > [...] > > > > The problem with a "simple web app" is that while the initial job > > > may look simple, and impl may even be simple, we then have an > > > ongoing never ending burden to support this web app. > > > > > > We've got a long (and disappointing) track record in Fedora of building > > > things and then being unable to support them sufficiently well due to > > > lack of resources, especially when the original author moves on. > > > > We have a long history of not providing community support for > > Fedora-originated projects. Infrastructure or otherwise, it's rare for > > a project coming from Fedora to be broadly successful because there is > > no designed intent to market them and build communities around them. > > The "designed intent" to market stuff is for corporate products. For > community projects, it's more organic and messier. You know this as a > long-timer in OSS field yourself ;-) >
No. It's a culture thing, not a product vs project thing. > [...] > > > I would rather us go down the road of making simple web apps for this > > stuff. > > I'm not sure if the limited engineering time is worth spending on such > things (even with AI's help). People are already spread quite thin. > > > What we need to own up to is that we cannot count on Fedora > > itself to be an advocate for projects built by Fedora contributors. > > Those contributors need to actively do community-building work > > themselves. > > 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. > > > We can't even get sufficient resources to support & develop critical > > > infrastructure such as our accounts system (see recent discussions > > > about its sub-optimal support for 2FA that no one has had time to > > > improve for years). > > > > > > > I mean, this one is mostly the fault of FreeIPA. It isn't designed for > > community projects, and shoehorning it into Fedora has resulted in > > this flaw. > > This sounds like an unfair characterization of the folks doing the work > involved. I don't know if anyone else came up with better alternatives > that suit Fedora's needs and was willing to put in the work. > > > It won't be fixed because no corporate customer of IdM > > needs it, since the model works for business deployments. > > Sounds like an assumption. Maybe if we ask nicely withouht throwing > barbs, they might listen. > 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]. [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 > > It isn't going to get fixed because IdM doesn't consider Fedora an > > important customer/stakeholder/etc for feature development. > > I don't know the full background here, but again, this reads like an > assumption. > > [...] > > > > Deploying and maintaining a code forge is a non-trivial undertaking, > > > so it makes alot of sense to maximise its benefits to the project > > > by considering whether it can be put into service for other use > > > cases we have, such as the Change proposal workflow. > > > > > > > "Build vs buy" is an argument as old as time. But every time we choose > > "buy" instead of "build", the Fedora contributor experience has gotten > > worse. Can we please stop doing that? > > 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. I certainly do, but lately the idea of "worse is better" has taken root here. 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. Forgejo's tag soup and inability to have resolution statuses means that it's really hard to triage things with the same effectiveness. I've been part of project evaluations to move to forge trackers and for large projects, it's just a worse experience for everyone. 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 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. 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. [4]: https://www.mediawiki.org/wiki/Extension:WikiMarkdown > > > IOW, while I agree with your concerns about usability to some degree, > > > Fedora has to be realistic about what we can do with our limited > > > resources for infrasturucture & apps. I can't see it being a good > > > use of resources to build & maintain a custom app for this. > > > > > > > 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 > want to make the trade-off or not.) > It is not a trade-off worth making, IMO. -- 真実はいつも一つ！/ 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
