Alright. Hello everyone. Thanks for coming. My name is Adam. I work for Red Hat and I
do send-off stream for Day Job. I'm the send-off stream lead and I want to talk to you about
send-off stream and how we, Red Hat, use it to get work done on RHEL and how you can
use it to participate but also build your stuff and we'll see. Okay, so just to set
the context, before send-off stream we did something like this, like when we created
RHEL, where Enterprise Linux, I keep saying RHEL, we took what's in Fedora, that's where
the innovation happens and then we had like a long process to build RHEL out of some
of that and when that got out, somewhere later, sent-off stream, sent-off Linux happened
and yeah, that was interesting but the problem was that when you find something in that rebuild,
you can't really change much because the goal was to be a rebuild of RHEL. So what we did
with sent-off stream, we kind of switched it a little bit. Now the process is like there's
more steps, so we have Fedora still, there's nothing changing about Fedora, that's still
the primary place where innovation happened, that's the upstream, there's something called
Fedora ELN, which is like a subset of the content, rebuilt with RHEL configuration and
that's the next major RHEL release. So if you go out and look at Fedora ELN, that's
what RHEL 10 is sort of right now, then sent-off stream happens, this is where the development
of RHEL happens in public and if you talk to Red Haters, they will sort of somehow combine
these together, sent-off stream and RHEL because this is really our development space and I'll
have more details later, so this is tracking the next minor version of RHEL and this is
what you can use, but you can also contribute to it and we'll get into details. So this
is basically if you heard Fedora ELN sent-off stream, this is what it is and I have some
more details here, this is Fedora, Fedora Rohite sources, this has its own sources and this
is the build-build flag and you can also see there's a different amount of packages, it's
just like more information there. Okay, so let's talk about how we get work done or how
you can get work done in sent-off stream, how that works. So there's this diagram and we're
not going to go box after box, no worries, but I just want to demonstrate that you see
that we have bugzilla where work tracking happens, there's a merge request coming to the GitLab
and then basically everything is synced, so the upper part is the sent-off stream infrastructure,
this is RHEL internal infrastructure and as change happens, it gets built in both, it
gets tested in both and when that passes test, both get released further to the process and
finally it gets into both RHEL and sent-off. There's something called sent-off development
compose and production compose, which is basically when this compose is sort of like
a repo and ISO and container images, just like a snapshot that you can consume and yeah,
there's one that happens after the test, that happens every day and then the verification,
this is like an internal process paperwork and stuff and then that goes through the production
compose and I can even show you how that happens in the system, so this is what a bugzilla
bug looks like, someone was adding, this is like half a year ago, a multipass TCP to RHEL,
so they created this, they did the merge request in GitLab, everything was visible publicly
and they submitted a build first in sent-off stream, that got through, got built in RHEL
as well, if I scroll down there's tags, that was like the multiple steps, the gates pending
candidate, that's how you can know where it's in the process and it basically got through
that and now if you're using sent-off stream you already have it installed because that's
half a year ago for that change, but this is basically the flow how it works.
Let's talk about contributions now, for some context I'm starting with RHEL 8, RHEL publicly
said that we'll do minor releases of RHEL every six months and major releases of RHEL
every three years and this is what we've been sort of doing eight and nine and something
called ABI, I got that as a note for myself, with RHEL we make some promises to customers
about ABI guarantees and support statements etc, basically whatever you would expect from
Enterprise OS, so we don't want to break things for customers in the major version and this
will influence what contributions we can take, so the easiest one is bug fixes, if you find
a bug and you can fix it, feel free to do so, we'll be very happy to take it, test it
and if it doesn't break things for the customers, merge it, get it in and that's the easiest
way to contribute, you can also contribute stable updates from upstream and buy stable
that gets to the promises, basically as RHEL ages it gets further from the upstream because
we need to keep things sort of stable in the ABI way, so we still release updates like
every single minor release, but most of them are backwards, so again welcome to contribute
updates that are stable, we'll again fix them, test them, build them and get them in, but
yeah, and backported features here, this is what I mentioned basically already, I just
have a slide for that, okay, what we can take is the ABI non-compatible updates and if you're
wondering about details there's the document called RHEL application compatibility guide,
you can find it online on the Red Hat's website and it'll explain exactly how it works, but
most packages have the ABI stable for the entire 10 years of RHEL life cycle and we
take it very seriously at Red Hat because customers build applications and they want
them to run forever without changing them, so we don't want to break this for them, so
please don't submit things that would break ABI, we would need to politely explain why
not and reject it, that's what you can contribute to Fedora ELN for example and we'll get to
that.
Okay, I have maybe for docs, typos, man pages, there's a thing for customers, if they go
to the customer portal and they have a bug with documentation, they can report an issue
and get it fixed that way, otherwise we tend to batch them together so they land all at
once so maintainers can focus more on actual feature development, back porting and stuff,
so these are welcome but they might take longer to get in because of this and this is a detail
image of the life cycle, if you want to get your change into a specific minor version
of RHEL, we don't have a way in the bugzilla to really communicate it but you can get in
touch with the maintainer and you can sort of anticipate, by the way, minor release,
this is the dark blue, extended update support, this is the light blue and then update services
for SAP, so even like we're done with minor, we still might be supposing it for up to four
years and the arrows is like where CentOS stream work happens, so it tracks all of them
and just changes make it to the minor releases and yeah, you can sort of anticipate like
where it gets but there's no communication like where exactly, so if you really need
to, you would need to talk to the maintainer, yeah, we have this for eight and there's also
seven, there's like a lot of things going in the background and if you want to contribute,
let's talk about how, so you can open bugs in bugzilla, you can test stream, if you find
something, you can open bugs and hopefully get it into the next minor release, you can
open merge requests in GitLab, create a GitLab account but first please make sure that you
have a bug so you start the conversation with the maintainer so they know what's coming
and they can also help you with the change and then you can track the change, this is
again from the diagram, we have these three tags in Koji which like we used to track the
process and you can preview things in the development compose or the production compose
base where it gets, you can get the composites on this URL and there's slash production slash
development but otherwise they go to the mirror so if you go to CentOS or you will find CentOS
stream there, okay, let's have a look at use of CentOS stream, of course you can use it
to preview REL test features that are in development, see what's coming before it actually gets
to REL, I think one of the interesting part is that you can use it, if you build something
on top of REL you can use CentOS stream in your CI to preview how it would work on the
future REL so you can get ready for the next minor release and one advantage like compared
to a rebuild is that you can, if you find a bug like in CentOS stream you can actually
get it fixed for you and get it in REL proper so this is like what we're trying to do there
and this is actually one of the most interesting for me so we have special interest groups,
there's like the Hyperscale SIG, there's Cloud SIG, there's the K-Mode SIG and they work
in the CentOS stream community and they build their own stuff on top of CentOS stream so
they have like a stable enterprise platform but again compared to a rebuild they can actually
influence what's happening, they can submit changes, unbreaks things for them and get
it into REL proper, I know the Hyperscale SIG they're maintaining bunch of stuff before
they actually merge it and there's really interesting stuff going on, you're welcome
to come in and create your own SIG and use the community build system to build everything
and CentOS stream is definitely there, that's the primer build targets.
So that was mostly CentOS stream, I have something about CentOS stream 10 and REL 10 as well
basically we saw this diagram and with REL 10 we're right here so if you want to contribute
towards REL 10, get it in Fedora Rohide which means get in Fedora ELN if it's within the
REL package set and at this point you can change APIs, you can do whatever Fedora would
normally do through Fedora changes so this is like the most flexible time of contribution
to CentOS stream 10 and REL 10 and later when we get to do stream this is from REL 9 but
the process is the same we have like Rohide and Fedora ELN, imagine this like Git branches
and Fedora Rohide is the rebuild ELN, follows it and we branch CentOS stream from that and
then later start doing REL and yeah we call that bootstrap that phase that will be happening
somewhere later and yeah that's how it happens so you can get your changes to Fedora ELN
right now and that was a different...