So I hope you've just realized that I'm only one person here.
So hello, I'm Frankie Shek, I am a product owner of the Peckitim in Riddet and I'm not
joined here by Dana from Suze.
And it's a pity because Dana has done all the hard work and you'll see my role in this whole
thing.
So, in the set, but I think there is still plenty of things to present and also I have
nice excuse to say I don't know to all of your questions so I think we are on good spot
here.
Okay, so what's ahead of us, I'll shortly compare what's in the open Suze World and what
Fedora, how there are the services connected so we are on a like somehow see the context
where we are, what we are looking at, then I'll introduce the Peckit projects and his role
in his in this thing and there will be like the story of how this all ended or went and
then finally the current solution what you can use now, what's what's planned for the future.
So, let's take a look at the basic structure of the distributions that should somehow
fit to most of the distributions, we usually have some place where the Peckitis are defined,
some kind of source control distribution gate or something like that, then we have some
things, some tool or service to take care of the built, then if you have like all the Peckitis
built, usually have something to like assemble that together, produce some artifacts and ideally
for good distributions there is some kind of quality assurance or testing going on, ideally,
not all, usually if you would like to get like the update and things to the user so there
is some publishing going on and maybe some monitoring, so let's start with Fedora, how it looks
on the Fedora side. So, the Fedora, we have a distribution gate, so it's a gate server,
where we have a gate repository for all the Peckitis like each Peckitis,
mostly each has a separate repository for each Fedora version that is a branch basically.
We have that figure as a front end or like this gate forge for this, which might not be true
and so soon, so this is going to be replaced by 4.0. For building Peckitis, we have Koji,
which shows how Fedora is looking at the things compared to open susay, Koji is quite simple,
let's say like it's a build system, so it does one thing and does it quite right, so it takes
care of the building build task and these things. In Fedora space, we actually have two build
system, there is also co-oper that has like a key part in the Peckit stuff and it covers
like the user, slash community targeted build, so if you are from the Ubuntu space like
Pepe, Pepe, and stuff, so that's like the thing that's going on here.
Then we have Panji, that takes care of like the repository of some plants, creating images and other
artifacts. Then there is an open QA used for the like discoloration and stuff and
slide the related, there is also body, body is used here to like move the stuff between the
Koji before it gets to the user, so if there is a build or a group of related builds,
this doesn't go straight to the user, but usually there is this so-called body update created,
which provides the way how to like try the stuff before it gets to the user, vote about that
and maybe block the update if something goes wrong. And there is a Koji that takes care of like
somehow like reverse the dependency issues can help us with this.
Looking at the open source side, the structure would be much much easier. Most of the stuff
is being taken care of by the Open Build service, OBS, so I'll try to if I mention one or the other
does it the same thing, OBS takes care of everything. So it has some kind of source control,
it's not a git, we'll get to that later, because there's not the simple stuff
and regarding building, it's both Koji, both Kooperi's case, so it covers both and also like
these other steps, everything is being covered and also automatic rebels when there is a
dependency update, everything is in OBS. There is also Open Kuay actually that's the place where
it was like for first time compared to Fedora, so it's easier something to share.
If you are interested in more details about like these differences,
done has had a total last year about this, so take a look at that,
here's a lot of interesting ideas and compliance and yeah and it was probably clear about this
because he ended the talk that Bob has some issues, so I won't properly shuffle the infrastructure
nor in Fedora nor in Open Susen, so but maybe there is something we can do on top of that and that's
actually what we try to do in general in the packet projects, our goal is to get
upstream developers close to the distributions and by vice versa, like in Pope ways,
so we are trying to like provide a downstream distribution feedback back to the developers
and when there is an upstream release, we are trying to help maintain, let's get the
get the release down to the distributions. So looking at the upstream workflow that's like this,
first use case packet is like a single service, but still has supports these like two kinds of
functionalities, so the first one is like acting as a GitHub or GitHub CI, so there is this
GitHub and through packet you can do like various, various tasks. Usually we leverage an existing
service, single purpose service to do the stuff, but build and use the facing workflow on top of that.
So for building, we support learning, scratch build, so like the test build and also copper builds.
With copper builds, we have a bunch of other stuff that you can do on top of that.
Back to the copper, you can not only use it as a CI, so not only to check if your package can
be built, but also to provide like persistent copper projects for your commits or releases, so
you don't need to wait till the code gets, for example, to Fedora and, you know, like approval.
Also, we are integrating testing farm, which is built on the TMT test format, which is like
spreading in one of various places of like this RPM space, but also in another space, you can
either run the test directly on the code or you can run it in a VMs that has the
archni-a-marti-fax from copper available installed on the VM.
Newly, there is also opens can have integrated, which is a static analysis service being open source
from an internal redhead service, so you can also use that. If you are interested,
we had to talk about that two days ago on CentosConnect, so that's a nice thing to take a look at.
Well, and regarding VM images, there is an image builder integration as well. So, let's take a look
at the Fedora automation of what we have in package, actually we need to move the stuff a bit
to make a space, because we are starting in abstin, that's our role. So, we are starting on GitHub
or GitHub, as I mentioned, but we can also use release monitoring called CentosConnect,
Anita, related things, that release monitoring is like data-based service that starts together
information about abstinence releases, and let's us know when there is a new abstinence.
So, where we know there is an abstinence, we can prepare this git for this new release
and upload an archive to the Lukasite cache. So, this job is results in a pull request in
in this git. Once the pull request is reviewed, merged, we are running automatics,
co-chip build, and when there is a successful co-chip build or a group of successful co-chip builds,
we are creating what we have played. Okay, so, whatever will happen soon.
Last year, I had a talk, we can get abstinence, close to together, and I prepared a bunch of
questions we are getting, and one of such questions was like, yeah, you are supporting just a single
distribution, we as an abstinence don't like that to debug that, and I've collected a bunch of
ideas what you can do, and actually someone suggested to you. So, yes, because it supports more
distributions, there is all nice, but it is not easy. Obviously, it has a custom versioning control
bolsing completely different way of how we were used to, and that's part of the whole system.
Okay, but by bother about this, it's not so easy. Yeah, it supports more distributions and
package formats, and also it can provide more artifacts than copper, copper is very nice, we
we love to work on that, but yeah, some limitations are there. So, we are starting the history.
Then, actually, send the first PR, how, like, year and a half, I go trying to like,
let's, let's introduce OBS into packet, because I have mentioned that,
done is both, like, community member of Open Suzan Fedora, so he would like to see a single
tool for all his packages and efforts. So, that's the date, yeah, please don't spend much time
on that, we are reveriting like this wraparound top of OBS, and yeah, two years ago,
yeah, and a lot of discussion, and yeah, but from the perspective of packet team,
we need to be also sure that if we introduce something into our code base, we need to care about that,
and so we need to be a bit cautious, so just a few comments. Yeah, so slowly,
done stop, we had time for that, so it like slowed down, which I completely understand,
because it's really complicated, and maybe it's also my fault, because I started packet,
we've on the base that there are two repositories, one for OBS team, one for Dams team,
and I wasn't aware that things can be different, otherwise elsewhere, so let's me on.
But, yet, last year I was thinking, like, can we get some help on that, and like, yeah, there is a
g-so going on, Fedora doesn't have, wasn't chosen at the time, but it opens a set date, so what
about doing something about that? Yeah, and actually, together with Dams, we've provided a
project, and we got Brian as a student working on that, so Brian took the code from Dan,
and starting building on top of that and spent the whole summer on that, thanks for all his
work, on that, but actually, some is quite short time to do something like that, so yeah,
there was like a lot of stuff going on, and he has done some stuff even after the project was
was finished, so, yeah, same story, it slowed down, it was like, we've done yeah, we would like to
finish that, we would like to finish that, and nothing was happening, but yeah, and that's my
cruise roll here, it was always like, yeah, Dan, what about submitting a talk to folks there,
maybe it will, like, force us to finish that, so yeah, it's a good idea, and yeah, nice thing to do
during Christmas, yeah, so yeah, two months ago, we are going back to the original public
quest, and Dan revisited his work, and actually, with magic, and no worries, the time doesn't match,
I've made a screenshot yesterday, so this is fine, just need that, okay, so how it works, yeah,
so yeah, we have an abstinence here, or when we are working on locally, so get your repository,
we create a OBS project, or set up like the stuff on the OBS site, if it's not already set up,
and then we prepare SRBM, and do the committing, and adjusting, prepare a change file, and
this stuff, because with OBS it's kind of like submitting an update to this given Fedora, and also,
so it's like a combination between copper and this git, so we need to do both, and then if the
build set set, we can report it to do use them, so currently it works only for command line,
so we are missing the service part, but in the future, this should like, in the context of
abstinence for for, it should result there, so another build service available for you,
but that might not be the only place, so let's do the demo, actually rather not, we don't have
done here, okay, so let's take a look at how you can use it, so you should install the great latest
great display kit, I've got the release of Halvan Hour ago, so the build made it, so I think you can
install it, and after like a few days you'll get it from Fedora, so that's the first thing,
okay, then you should have the package set up, you can flow this guide, there is a lot of information,
but usually when we are configuring the package, you just need to know what the name of your projects
and all the stuff, since we are heavily built on top of RPMs, so you should have a spec file,
not directly, you can also download it from somewhere, but you should have it, but we had
the talk in the morning about Rastuar PM, and stuff, so I think there are tools to help you,
people that you can have, then you should have, since we are talking about pick it command line,
pick it command line requires your own identity to work on, so pick it command line and the core
is like that it uses like your identity, the service part uses pick it's like own identity,
so you should like set up the OBS credentials, and don't be confused, if you set up token on OBS site,
it won't work, you really need to put their password, don't ask me, okay, so here's the command
you can use, basically you think and just if you want to wait on not wait for the build to finish,
so yeah, so what now, so what we would like to do, so the change of log might be improved,
but that is like heckishness, I think, not so important, the
another important, very important part is that the done is working on supporting submit request,
which is a way how you can introduce updates on new packages to the OBS board, like OpenSusa,
and so it will somehow match the way what we have, what I shown for Fedora, so you now,
you would be able to like from one place set up like automatic updates to both these distributions,
and the third one and the crucial one, you would like to have it in the service,
so for that, we would really, really like to know if you are interested in that, if it makes sense
for us to continue on that front, I'll mention how we can do that later on, but that's the crucial part,
and also since OBS supports like other distributions, I might want to take a look at that as well,
so, because you might not be sure, and after some tells you might be wondering,
what does it mean for me, so I've prepared some cheat sheet for you, so I have a project
developer care about my users on Linux distributions, yeah, please do set up package,
I for your project, so you are sure right away on OBS team that, and that your project won't
break, and it gets finally to the distribution of so you can, this is called like ship left
angle, so like moving test and stuff and verification to OBS team, so it's like it can be fixed,
right away when the things are developed, okay, so I want to have ArpNM repository for my project,
I've already mentioned that that you can already use the corporate integration to
provide you like the stable, stable, corporate repositories, the Yamrepositories for your projects,
either for the comments, in what is for example a different, different repository for
comets and main branch, different stable branch, and maybe different for OBSs, which for example
do so, you can like quite easily without much hassle, like have this available, and if you are
interested in like OBS, please do try locally, it can still help you save some time and creating
the setting up the project, and ideally let us know, okay, so I'm a federal amendment owner,
yeah you should set up a package in my automation for a project, simple, there is a dedicated,
this good specific onboarding guide for you, and okay, I'm an open to the maintainer,
yeah try this package OBS functionality locally, let us know, let us know, okay, and I'm
maintaining an added distribution on or ideally I take care of the infrastructure here,
getting touch with us, we are more than we more than welcome any like contribution, we usually,
we've like managed to do a couple of like various collaboration and a way that like someone
external, implementing the package core, as done it currently, and then maybe package team can
like build a service bar on top of there because the package core slash command line is quite
easy to work with, but the service is not so simple to like foreign newcomers, but we will
be really like to have more distribution supported or at least some collaboration on that front.
Okay, I've mentioned let us know, so either we are quite active and our primary communication
or something matrix, I'll show you the next slide so, but I've just created a discussion for
where we can like ask anything or mainly, either you stumps up or mention, I would like to
see this happen or I would like to use it for my projects, our team is outing splints are heavily
based on like the demand, so if we know that there are a couple of people interested in something
or are worked by some of some of our work, we can therefore working on that, if we are not sure
if there is anyone, we'll probably not spend the time on that, so if you want to influence what
we'll work on, let us know, yeah and the huge thanks for done for finishing this and also Brian
for spending the summer on that and also the team for reviewing that because you might not
supported like how many lines it was, it was really easy at all, so thanks for those for that and
that they were very willing to respond to my messages like I do this and I do that what about and
okay, so that was all for me, I like the MasterDone accounts and most of the stuff should be on
our webpage but the matrix channel is quite active and we try to be like, well come again
I'll be just stuff, so thanks, do we have any questions? No worries, I'll forward right into
down, it's fine. Hey, I know you have some kind of service that can run the bills but basically
did you like experiment with the Gita Batchons for example? Yeah, we have Gita Batchons actually
like that's the issue that Gita Batchons are not so fitted to the if you have like the existing
services and it's same with like a Gita Batchons, that it's not those who did when you have like
existing infrastructure and like this even based system that you need to like change the steps
going outside of your control and you need to wait for something, yes, that's the that's the
main issue, but yeah, there are some basic steps going on like having a packet,
Gita loves setup or Gita have if you want to like to be dead, if Gita is a bit easier but
but it it will basically be just a wraparone out command line and you will lose all the
like vessels on top of it. Thank you.
No more questions I guess. Thanks for the show.