Re: How can we improve the Changes Process?

On Wed, Jul 1, 2026 at 7:32 AM Alexander Bokovoy <[email protected]> wrote:
>
> On Срд, 01 ліп 2026, Neal Gompa wrote:
> >On Wed, Jul 1, 2026 at 4:49 AM Daniel P. Berrangé <[email protected]> wrote:
> >>
> >> On Wed, Jul 01, 2026 at 10:36:04AM +0200, [email protected] wrote:
> >> > On Sun, 2026-06-28 at 15:21 -0500, Maxwell G wrote:
> >> > While this can be preferable to some more technical Fedora
> >> > contributors, to me it kinda looks like trying very hard to avoid
> >> > making a simple web app instead, that takes the content of a couple
> >> > fields, validates the content of them if possible (change type set,
> >> > owner FAS account exists, Fedora version set, etc.) and generates
> >> > outputs as needed (plaintext email summary, static web page, etc.).
> >>
> >> 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.
> >
> >It even happens to Fedora Linux itself, if you look at the variants
> >other than the Red Hat-supported ones.
> >
> >I would rather us go down the road of making simple web apps for this
> >stuff. 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.
> >
> >> 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. It won't be fixed because no corporate customer of IdM
> >needs it, since the model works for business deployments.
> >
> >It isn't going to get fixed because IdM doesn't consider Fedora an
> >important customer/stakeholder/etc for feature development.
>
> You are wrong, Neal. I don't want to spent time in fruitless discussions
> but I'd ask you to refrain from unsubstantiated statements.
>

I am not wrong. Having MFA support is not the same thing as supporting
low-touch MFA workflows. Zero-touch MFA reset has been a requested
feature ever since we started talking about MFA for packagers. We
don't have it. Instead, we have to contact an admin to reset it. No
self-service recovery code based mechanism, or email verification
mechanism, or anything of the sort. These are all things that are part
of table-stakes for account systems like ours, and we don't have it.

This is a genuine hardship, and we know that it's something that takes
actual time from people since ~15 resets have been done in the past
six months alone. Self-service resets are, from my point of view, the
only major blocker to considering mandatory MFA.



--
真実はいつも一つ！/ 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