Re: How can we improve the Changes Process?

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.

Any development of new features needs people interested in that work and
maintenance and resources. FreeIPA community has very few developers and
huge amount of users from various industries, community and commercial
consumers. Fedora infrastructure is just one of those users; even when
we add features required by Fedora Infrastructure, it is ultimately a
decision by the infrastructure team how and when to use them.

It is interesting to see that not only majority of CentOS Stream
downstreams use FreeIPA deployments for their community organizations as
well -- this might be influenced by Fedora Infrastructure, of course, --
but we keep seeing many community projects chosing to run FreeIPA for
their infrastructure as well, fully on their own, often without even
talking to us.

What we see a lot in many communities is a lack of volunteers who can
contribute to infrastructure code. This is not unique to Fedora
Infrastructure at all. Maintaining infrastructure is hard, tuning off
the shelf solutions isn't always easy either.

FreeIPA has support for passwordless authentication methods for more
than 12 years: first smartcards and OTP tokens, now OAuth2 federation
and FIDO2 tokens.

FIDO2 tokens support for Noggin was implemented recently; I tried to
find *anyone* from the Fedora AAA team to talk about that work for about
a year, to no result. Even now, when the code is available, I have no
responses.



>
>> IMHO it is more sustainable to use off-the-shelf software even if the
>> solution has worse usability, unless the payoff from a custom solution
>> is exceedingly valuable. Beyond using an off-the-shelf solution, it is
>> also important to cnsider what existing sofware we have deployed that
>> could do the job sufficiently well. Again, to minimize the number of
>> different services that we have to support.
>>
>> 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?
>
>> 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.
>
>
>
>
>--
>真実はいつも一つ！/ 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



-- 
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland

-- 
_______________________________________________
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