Video summary
The September 3, 2026 meeting of the App Runtime Platform Working Group focused on addressing a critical dependency issue regarding the Ifrit library, which had not been updated for some time and was causing problems in their application runtime. The team discussed the fact that while a pull request to fix bugs in the library had been opened by Geoff, it remained unmerged because the original author, Ted Young, was currently on vacation. Recognizing that they are the primary users of Ifrit and that external attempts to replace it have failed due to its complexity, the group concluded that forking the project is the most prudent course of action to ensure stability and maintain control over their infrastructure.
To implement this solution, the working group decided to fork the repository as a standalone project rather than adding it as a submodule, ensuring it appears correctly in Go module definitions. The plan involves merging the necessary bug fix pull request first to secure a stable version, followed by the creation of a new community repository for the forked code. Once established, the team intends to integrate this new module into their existing maintenance pipelines alongside other key components like the Routing API and Policy client, allowing them to manage updates and fixes directly without relying on the original author's schedule.
The discussion also highlighted the long-term benefits of this move, particularly for critical services such as routing and Jaeger, which require immediate attention and reliable updates. By taking ownership of the codebase, the group aims to provide a drop-in replacement that can be deployed quickly whenever issues arise, eliminating the risk of being stuck with outdated software. This approach not only resolves the current stagnation caused by Ted's absence but also empowers the working group to evolve the library according to their specific needs without waiting for external contributions or approvals.
In addition to the technical strategy, the meeting concluded with a celebratory note regarding Yuris's recent acceptance as an approver in the community repository, acknowledging his significant contributions over time. The team expressed satisfaction that this long-overdue initiative is finally moving forward and encouraged open communication via Slack for any further coordination, given the high volume of GitHub notifications. With the path forward clearly defined, the group adjourned the session with a positive outlook on maintaining their platform's health and independence.
Read the full video transcript
Hello everyone.
>> All right.
Oh.
I am.
>> Full house today.
Brandon, do you have anything to add to
the agenda or are you here to hang out?
>> I am here to hang out.
>> Okay.
>> [laughter]
>> Hello clients.
>> Hello.
>> Okay everyone, you want to get this
kicked off?
>> Um
Sure, I can. Um
So, I've
as we discussed over the past year or
so,
we have
uh
dependency in our application runtime on
Ifrit
uh library which was not updated for a
while, which caused I don't
And I
I've opened a pull request to update it.
Then I had a discussion with Ted Young,
the author of the of Ifrit.
It was
>> [snorts]
>> uh
36 uh
mhm mhm mhm
colleague of yours
Pivotal and um
I've updated the library. It turned out
that um we have some problems there, so
Geoff and Adam
took a look at the problems and Geoff
opened a pull request
to to fix the bug and but the pull
request is still not
merged.
Um
Ted was on a
on a vacation, so before uh asking him
to to merge the pull request,
um
I wanted to to discuss with you about
forking Ifrit.
Uh
Ted also suggested that we fork it as
we're the uh
biggest user and and I guess
um the single user of of Ifrit
that he knows of.
And now is the question how
how to do that.
Um we can simply fork and then um
it um
either repeat
module replacement in the
go.mod libraries in the go.mod
definition of the project and then
uh
let the responsible teams
do do everything else.
That will give us more more more power
or more
ownership and power as well.
Uh of the things that we use.
And um
Ted is also
suggested that we
fork it.
And I think I think that that's the
right thing to to do.
But how should we do it and open to
suggestions?
>> Yeah, I'm definitely pro forking.
Um
so that we can maintain control of it.
Uh I think if we fork it
um and add it to this working group
which is fine.
We can maintain it like we do. We have
other modules.
Routing API is a module? Policy client.
We have like a a standard way that we
deal with go packages that we maintain
that are used in multiple places.
And so we can slot it in one of these
pipelines I think.
And then I would vote for
us maybe a slow approach or like a
we do the best we can to move everything
over that we know about to use a friend.
But
not urgent. You know what I mean? Like
we of course do routing and Jaeger are
probably the most important
for our working group.
And then we just do our best effort
after that.
But I think the most important would be
getting it forked and having something
stable. So that way when there is an
issue and we need to change you're like
oh you're still using that old one. Come
over we have a new one that's a drop in
replacement.
>> Um yes.
Yes.
I don't also did some um GitHub GitHub
archaeology and and took a list of all
of the repos in the platform jark which
are using Eephered.
>> Mhm.
>> not that
uh
the number is is significant.
>> Yeah.
>> Um I've also spoken with with some
colleagues at SAP who
are using it and they tried to to
replace it with something but they said
it it's it's too complex. It's it's like
rewriting
there is logic in something so
I think we we need the control of it or
at least
>> Yeah, I agree.
I don't know what forking's for, I don't
think.
Like Ted said
>> Mhm.
>> That makes the most sense.
>> Mhm.
Yes.
>> Are yours?
>> Good then.
>> Hi. Now my microphone is working.
>> Yeah.
>> I mean definitely
we fork it
I think that that
we
we fork it.
And I will ask him to
to merge the the pull request from Joe
cuz the bug fix for the
latest things so
We will have some time until we
set up our all of our things that we
need.
>> Yeah.
Uh yeah, if if you can
bother Ted.
And if you want to be the one to to do
the actual forking
that would be great and like maybe
replace in one repo maybe routing as a
proof of concept.
Uh
I'm happy to take over the once it's
forked the setting up the pipeline for
it.
>> Mhm. Okay.
Okay, I'm I want a vacation till 14th of
September.
>> Nice.
>> Oh, [clears throat] yeah. Thank man.
>> [laughter]
>> Um
I will ask Ted to to to to merge the
pull request and then we'll see what Um
how are you going to to do the fork?
Will you create a repo somewhere and
we add it to it or
we add it to the source
in the source of the routing release?
>> I think um
make a repo with it. Not Don't do it as
a sub module. Do it as like a something
that would properly show up in Go mod.
Um and you can make a you can make a
repo by making a PR to the community
repo.
>> Okay, so then
let's do it that way.
>> Okay.
And [clears throat]
fork it.
And
How does that sound?
>> Sounds good.
>> Okay.
Yeah, it's been a long time coming. I'm
glad we're doing this.
It's been um
over 10 years since I worked on a team
with Ted.
>> [laughter]
>> Is there anything else we want to talk
about today or talk about with the fit?
>> Um
not about e-fit. Maybe like a one
pull request in the community repo about
yours becoming an approver
>> No, I didn't see it.
Sorry.
Very exciting.
This looks great.
That looks like a lot of contributions.
I'll double check it all um
after this, but it should be good to go.
Congrats, Yuris.
>> Awesome.
>> [laughter]
>> Thank you.
>> Always, please feel free to ping me. I
am following like 200 repos or
something, so
uh or ping me in Slack, I mean.
The GitHub gets drowned out, the GitHub
messages.
>> Okay, that's fine.
>> Okay, anything else we want to talk
about today?
Well, it's great to see you. Happy
Thursday.
>> Sounds good.
>> What up?