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.)
[...]
> 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
> [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.
> 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.
> 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.
> 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.
> 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.
> > want to make the trade-off or not.)
> >
>
> It is not a trade-off worth making, IMO.
We'll see what the rough consensus ends up being :)
--
Kashyap Chamarthy / Red Hat / RISC-V and Fedora
--
_______________________________________________
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
