I'm supposed to present this talk together with a cash deep, but he cannot be here, so it's
only me.
And let's start then.
So, who are you?
Who are we people?
I'm part of the team, which is called Continental Engineering.
We are the team, which is responsible for infrastructure services, design, documentation,
and leadership of the project, and send those and people and some other things.
So, let's about it.
I'm part of the team, and how do we choose for you?
How do we get into the situation where we are going to switch to something new?
So, as a project, for a few years, we understood that our current solution is not really
maintained.
We don't have enough resources to maintain it, and be developing yet another open source project
is not necessarily a way to go in the open source world.
So, our team was approached by Federal Council, and we were given a mandate to compare
some open source forges, and choose or not really choose, we just created an analysis,
and submitted it to the Federal Council body to decide what will happen.
So, the solutions we compared were GitHub and for Joe.
One thing that Council decided was that we are going to do it for Joe even though at that
moment, for Joe it didn't have all the features that we need.
It still doesn't have them, but it's way better for us as a project to be part of something
open, and something which is very well alive, and it's being developed by somebody else
who can help us.
So, we can contribute, we can help the project grow, but we are not the one who is owning the code
this itself.
That was one of the reasons why this is in fail into the for Joe even though we were approached
by our sponsors, and we were offered to use GitHub Enterprise Edition, but this is
not really in a philosophy, etc.
Using proprietary solutions to build open source project is kind of strange.
So, we ended up with for Joe, and where are we now?
It's been about seven months, when we are eight months, when the Council decided what
are we switching to.
So, currently we deployed for Joe in one deployment, which we call the forge.
So, instead of how we do infrastructure, how we do things is that we have separate staging
and production environments, where the staging is trying to be like one or one to one with
the production stuff, so all the services are running there.
We have a production clusters, which are there to provide the services alive in production.
As a first, we deployed in staging, and started playing with it, we used different strategies
to deploy for Joe.
But eventually we ended up using upstream helm, and updating is a little bit
because a bunch of the images that we were used are not really, we didn't really like
them, so we changed them, updated some, modified the helm a little bit, and deployed it.
In the way we were deploying it, and we started experimenting it, we needed to find
the way how do we import all the work that we have already impagure.
Happily, for Joe is absolutely amazing project because it has the structure for
importing other repositories in it, so we just needed to contribute the structure of
pagure, the data structures that are used there, and how it will be imported into
the forge.
We did that, as we did, we introduced some bugs, which we needed to fix, and as we were fixing
it, we discovered smaller bugs, which were not introduced, but yes, so we started fixing
them slowly, but surely, and eventually we came to a state where the forge was up and running,
and we needed to provide our users with some additional functionality, because having
just the same thing that you had previously, is not really moving anywhere, right?
So we decided that we will enable the users to, the ability to ram the ground jobs, and
even though at that time, for you actually didn't really recommend it for your
actions, we decided to go the way, because we were not looking for a CI
runner, we were looking just for automation tooling, we allow for the
contributors and developers to automate some of the work tools that they have.
So we deployed it, we deployed it as a virtual machine on the top of the
hardware, where it's running a rootless podmem, and each organization in the forge has
its own runner, so eventually if somebody starts behaving, we can just kill their
containers, and we're good.
The other things that we need to do was integrating for Joe into our
our infrastructure, and that is one of the key features that we have in
the infrastructure is for the messaging, which is a queue that all services use and
just post messages there.
For now, the, which is the simplest way that we can, that's for Joe's
supports, and this is web hooks, so we use web hooks to just push messages
to our queue to report the rest of the stuff that we have in there.
So, this is the deployment that we call the forge.
This is a place where people across teams in Fedora do things, but not
necessarily the content for the distribution.
The content for the distribution services, we call this getting Fedora.
It's, it's a bit complicated and convoluted term because it means a lot of
things to a lot of people.
Let's just say, is the, is the place where the distribution
sources list.
We haven't yet deployed production early deployment here, because the use
case is a little bit different.
It's not just about having given repositories.
We need our, our users and group permissions properly mapped into
things.
So, we currently are in a very early stage.
We have a staging deployment.
We did some changing into it.
Again, we're using helm from upstream with a little bit of modification.
And now, we are in a stage where we imported about 40k of repositories into
it, and are experimenting with playing with, for Joe's, seeing how the
application reacts.
If, if it is ready to sustain the load that Fedora contributes, can make on it.
So, how do we do that, how do we build the things that we deploy.
So, we decided to use build system called conflux to build our container images that
we then deploy.
Since conflux does not really support anything else other than GitLab and GitHub.
It happened.
We had to do it a little bit, weirdly.
So, what we are doing is that we have our fork of for Joe, living in
codebarc, which is a service providing for Joe.
Where we do the development, we create new features.
If the features are acceptable to upstream, we will open a pull request and try to get
it and merge upstream.
If it's not, we are good with carrying on our own patches.
If the functionality is no good for upstream, why to submit it.
And this is basically the workflow.
We push things to codebarc.
They have a mirror, which mirror things to GitHub.
And from GitHub, build actions are triggered and conflux builds our images.
Push is done to our edge states.
Then we pull the images and deploy them in our deployment.
It's a bit complicated, but we work with what we have.
And try to make it better.
And a little bit of working with upstream, I would like to say that for Joe
upstream is absolutely amazing.
And we didn't expect that by your importer, which is very specific for
there are some other deployments in the world, but there is not much of them.
We will be merged upstream, but it got merged upstream.
And as I mentioned, we introduced a bunch of bugs, which we needed to fix.
So we fixed them.
And as we are fixing them, the team was able to, I think we got a
much like four or five pull requests across two releases.
It was V13 and V14, which is their nice.
Now, and again, working with for Joe upstream is absolutely amazing.
People are very nice and happy to help solve our problems.
So we got some guidance on changes that we would like to contribute.
I would get to the later.
But we are not sure how to approach it, because we do not own the cold base.
So we currently, we are in a space where we moved.
Our team is mostly working from the new forge.
There's a few repositories that are still missing that we are working on moving
them to the new place.
And the idea is, in the next six weeks, to have all of the
commenting and engineering teams working from the new forge.
And in Idol World, at the Flock Conference, that Flock is for
their contributors conference.
You can scan the QR code and join us.
And join us on the conference.
We would like to see all the community teams working from the new forge.
Again, this does mean just the teams that are not working on the content.
The content of the distribution itself is elsewhere.
So what the future holds for us?
And we would like to do more upstream fixes.
As you know, open source projects have their issues.
In this case, it's about 1,100 of them.
So about the community is nice about taking their issues.
So we can find about 70 good first issues.
If you never contribute, if you never contribute to jail.
And you know how to write the goal and code.
I would suggest if you want to contribute to something.
I would suggest to go scan the QR code, go through the tracker.
Find issues that are marked as good first issue.
They are very nicely described and usually easy to work on.
So please help us make for jail better for us and for everybody else.
So about the new features that we would like to see in for jail that we are missing for our workflows.
The biggest one we decided to call it by issues in public repositories.
As it says, it's about being able to mark some issues as a private.
Or being able to move private issues from private to public stage as a disclosure, for example, of some secret issues.
This is the biggest feature that you are working on right now.
We got some nice guidance from upstream on how to make this change.
Not disruptive for them and for other people.
So hopefully we will be able to contribute this new feature in upcoming weeks or months.
The other features that we have noticed are not only coming from us.
With our there are also in the tracker for jail.
Nested organizations and projects which means a set is just about the structure.
But structuring your content inside the for jail instance.
Ticket transitions for jail allows us to use some rudimentary planning and combat boards.
The problem is that the combat boards are disconnected from the issues themselves.
So having a nice transitions where you move things around the combat board.
Being able to transition the issues automatically will be really nice.
And pretty recently as we were migrating our own repositories.
We discovered that adding the ability to archive some tags that you use to tag an issue or poor request.
Meaning that you will the tag will look be useful anymore.
But it will still be visible to users is a feature that we would really like to have.
So this is the set of new new features that we will focus on upcoming weeks or months to and try to contribute an upstream.
Again, if the features are not acceptable for upstream.
We can carry them on and they can live in our fork.
And eventually maybe sometime get merged or not.
So why are we doing this?
What is the end goal?
So the end goal is to being able to modernize the workflow a little bit.
Having integrated it into the new services that further infrastructure and this project has at their disposal.
And that's like the packet service which is therefore to run automatically CI on their packages.
Or conflicts as I mentioned as a build service that will allow you to build containers.
Eventually maybe one time RPMs.
But currently it can be build containers.
So having the ability to build containers directly from further approach is one of the big things that we are focusing on.
So as I said, we are not really yet ready to provide distribution content from for Joe.
So this is basically kind of roadmap where we are heading.
As I said, we already have a staging instance for this get.
We would like to stabilize the configuration, have it already by the end of March.
Implanant the group and individual package repository access.
And may this year.
And ideally during summer and autonomous start to working on upgrading our tooling in federal project.
We actually can move somewhere.
And hopefully if everything goes as expected after the release of federal 45.
If we get our changes approved, we will submit changes to federal to do that.
We would like to start using the new for the for this for distributing the services and building the packages in federal.
And I would like to thank.
But they would like to thank the opportunity and thank the forger upstream which folks are very friendly.
And there is so many contributors they didn't fit in the screenshot.
And sorry.
I, you are on the there.
And I would like to thank Dean that is implementing the forge in federal.
Except for me, I don't think anybody made it.
For them this year, but hopefully in there.
Well, we will meet here and be able to discuss future of the forge for federal.
So with that, I would like to ask you if you have any questions.
Can you come and you probably must be there.
We use the way we use the way you are.
And the question the question was if we had some to link to use or some doing it and mess or we are using the UI to import our repositories.
So basically we use the UI, but we scripted away on the UI to be automated.
So when you want to import tens of thousands of packages, you don't have to.
Click on the UI 10,000 times.
Yeah.
Your slides show all the massive use of creation as a thing.
Wouldn't be upstream.
What do you think the door doing?
Whatever.
Can you continue?
You listed all the massive use of creation as an example of a patch that couldn't be upstream.
Isn't that why?
Automatically.
Did they mention that?
I don't think so.
This is why we have a diagram for the box to use each other.
Now I'm lost because that is the slide that was made by Akash Deep not me.
I understand the process and I know how it worked, but I don't know why he chose automated user creation.
Because that is not really the thing that we do because for Joe.
The question was why did we put the automated user creation as a feature that cannot be upstream?
But I think that's not really a good example because for Joe's supports or IDC.
So the account system is plugged into for Joe.
So the moment you first try to log in, you will be redirected to our provider.
And then your user is created in the forge.
And you have a local user which is mapped to the account system.
And then do you foresee a kind of needs in the Fedora project to do more project management type of tasks in the day or night,
epic features and users from each this time?
So the question is if we see the need for Fedora to do more project management style things in the forge.
And the answer is yes.
We are not necessarily looking for something robust, but something a little bit more than we have now.
As I mentioned, the automatic issue transitions, for example, if you have the combat board.
Things like this, like the small quality of life features, more than some huge, because we are looking at the simplicity of the project management.
Because it isn't for Joe, it's something that we want to have.
Like the simple clean user interface to work with, not some bloated things like giraffe or something similar.
I think there was a question.
Do you think that eventually a red cartoon of switch to this one?
So the question is if I can foresee if Fedora will eventually switch?
No, but I don't see red head switching to for Joe at any time soon, but I have had a chance to talk to some package maintainers and red head.
And they are not necessarily completely happy with the current solution, but it's the solution that the company is using.
So this is that it may be if you are able to prove in Fedora that our solutions is better and easier for developers.
Maybe, but most probably not.
Do you see a world in which for Joe is that actually tracking replaces Paxela for Fedora?
Yes, so question is if for Joe issue tracking will replace Baxela for Fedora and the answer is yes, but we are missing the crucial features.
One of the features that you are missing which is very important is the private issues.
Because when you get a bug report on your package and the bug report should be confidential, we can't just make everything public now.
So eventually at the end of this year I hope we will have feature party that will allow us to provide developers with similar feature set.
Not the same feature set because we don't want to implement Baxela in for Joe, but yes.
The question should be sure that I'm correct.
You mentioned that the project should be migrated before, let's say the target is blocked so June.
Does it mean that there would be a sunset and the commission will have to be loaded and it's just that.
Very good question.
So yes and no.
We would like to, if it wasn't me, I would like to the commission, but you're tomorrow, because there are issues with the code base, we are not able to fix.
But we are not going to the commission, but you're in a way that we will turn it off.
There's not what's going to happen.
We'll keep bugger running in redone mode for some time.
I'm not sure for how long and when we decide this is the end of the bugger.
What we will do is to generate static HTML pages from all the content that's currently on bugger.
And those static HTML pages will live there.
So people will be able to see what was there previously.
Do we have any questions about the local patches that you have for that different from the upstream?
Will be they just different too much in time, so let's say in one.
We hope you won't be able to apply them without rewriting.
So the question is about the divergence and about our patch set that we are carrying over.
So as I mentioned, I was really surprised that for you merged our impugger importer, because that's not necessarily a feature good for everybody.
And it seems from the attitude that for Joe upstream has that if we are able to provide quality features that we discuss with them first,
and we agree on the implementation that maybe we got them merged.
Currently, we are not carrying over that many patches.
It's mostly about some minor UI fixes that we not necessarily want to push upstream.
It's about the teaming of the fortunately, how it looks like.
And things like that, we are trying to carry over minimal patch set with minimal functionality and minimal code base.
But what other options did you explore and why did you choose?
So the question was what other options we explored and why for Joe?
As I said, we explored mainly GitLab.
And we tried to look into different projects.
We also looked at Gitty, for example.
But philosophically, we as a federal project are closer to for Joe as we are to, I would say, almost any other Bitforce project that is around.
Time's up, so thank you very much.
Thank you very much.