Okay, so the idea here is that I'm going to talk about this program that we run in Ubuntu
called the Patch Pylos program.
It's mostly about driving patches that come from the community.
So if you're having painful moments with Ubuntu, you can send your patches away and we
will drive a patches in there and things will be okay.
So my name is Atos, I started playing with these rows back then when I was in school
with Fedora, I used to maintain a few leaf packages there, after that I joined Red Hat where
I was working into container stuff.
It's called OSBS, it's your container build system.
It's 41s who understand Fedora and the build systems, it's a plugin that goes into Koji or
Broo for run headers and it allows the build system that builds RPMs to also build OSBS images
and shift them into container registry.
So after that I was hired by Canonical to work on container stuff as well.
Which never happened and for some reason all of a sudden I'm now maintaining PHP and
Koji.
So that's it, I work on the Ubuntu server team in Canonical and there we maintain packages
related to servers like servers that database has high availability etc.
So the idea is you can send patches to Ubuntu right now.
There is an easy process to get your contributions uploaded here and you don't need to directly
contact the potential sponsor who will personally look at your stuff.
You just need to submit a patch in a launch pad bug and the whole process that there are
some automations that we will ensure that your patch will get attention.
Before we get there, let me try to explain how Ubuntu works in relationship to that.
So in that we have the idea of having package maintenance.
So each package has a maintainer.
The maintainer may be a team, it could be a group or it can be a single person.
The current DPL is leading several discussions around this to try to reduce the boss factor
on package maintenance.
In Ubuntu, the idea is slightly different, right?
So all the packages in the distribution are maintained collectively, meaning that there are
no single owners of packages.
If you are a quarter developer, you can touch pretty much the whole archive in the developer
release, right?
In our development release in Ubuntu, the packages, as I suppose everybody knows here, that Ubuntu
is a derivative distribution of the admin.
So packages are imported from the admin in the development release.
They are either in sync with the admin, meaning that they are the exact same package that
are in the admin.
For they have delta, we call them delta, which are patches that Ubuntu applies on top
of them, either to a powerful thing, as they were saying here earlier, or maybe the release
schedule of Ubuntu in that in are quite different, right?
So maybe there's a bug in the package, we forward the package to that in, and maybe they
want to merge, our changes, they want to upload our changes in time for release.
So we have to edit the output to our package, to ensure that we release a good version
of the package, like with specific fixes for instance.
So the usual path is the package is uploaded to that in stable by the admin general of
the package, then it's copied or merged manually by a quarter developer into what we call
the series like for instance, fledging out, proposed, this package is tested with a gate
in system that we use both in Ubuntu and the admin called Brutney.
So it does several sorts of tests like instability, it will this package be installable in
your cive whenever it migrates to the actual distraught to the release pocket.
If the package has auto package tests which are test that you run in this installed version
of the package, this test is run as well, it also runs test for its reverse dependencies,
and then if everything is okay there, it migrates to the release pocket, which is the
actual series.
I will explain what the series are in the second and the pocket.
And then we also have a stable release update process, which is the difference from the
developer release in the sense of we don't want to break things, we don't want to change
things, we want to have stable releases, right?
So we go through this two rough review process on the bug and on the changes you want
to propose.
And then if they are acceptable, it goes through this series, propose a pocket, it goes
through Brutney, there is some manual interface in there and then it finally lands in the
updates pocket for that series, right?
Okay, so how the archive is divided in Ubuntu?
We have series which are the code names, the nicknames for our releases, right?
So we have 20 or four, which is foco, 20, 20, 20, 40, and now we are working on 20, 50,
40, which is plucky, right?
In there we divide the series into pockets, right?
We have the release pockets, which is the set of packages for a distribution at the
moment of its release, right?
So we are preparing things right now for plucking, we are uploading things into the release
pocket, and as soon as it is released, this pocket gets frozen, and then after that
if you want to make changes there, we upload things to this update pocket, right?
We have the security pocket where the security team uploads, there fixes, the usual
is CD fixes, the push in there, we have the proposal pocket, which is where we grab things
to test and they go through Brutney through the gating system to land and then there's the
backport bracket pocket, which is similar concept that we have in that game as well.
Suits are the composition of a series in a pocket, so, okay, I will hold it, okay.
We have, for instance, plucky proposals, foco security, etc., so we usually refer to them
like that, right?
And finally we divide the whole archive and this is the important point that I just wanted
to get here, we divide the whole archives into components, right?
We have the main components, the restrictive components, the universal components and the
multi-versal components, and where do I want you to get, I want you to get here?
These components are divided like this just to show if the package in there is a free
software not and who supports that package, who will fix bugs for that package, right?
So, main and restricted are the components that are supported by canonic, right?
Main has holds the free software in a bundle and then we have restricted that where we have
not so, not that free software.
And then we have universe and multiverse, which are maintained by the community, and
universe is where we have the free software in a bundle, okay?
So, yes, today, last night, we have a little bit over 2,000 packages, source packages
in the main component, 17-inverse free-stits, and universe has over 36,000 packages plus
500 in multiverse, right?
What does this mean is that canonic only contains about 7% of the packages in the own archives,
which we call the Ubuntu-based packages.
Which leads to the remaining 93% of the packages are actually maintained by the community,
right?
This is not entirely true because sometimes canonic only employees have strict touch, the universe
packages for instance, like during a transition, as I said, we have a gate in system,
so if the reverse dependencies are not working well, the package will not migrate,
so sometimes we have strict touch, universe packages.
But usually that's not what we do.
So what am I saying?
I'm trying to set the expectation of our users because you need to understand that the
canonic will employ it for the developers.
Our most likely not actively looking at bugs filed against packages in universe.
For instance, when you file a bug against, let's say, more curial, the version control system
package, right?
Let's say you like it, you use it and then you file bugs in Ubuntu for that package.
There's a good chance that it will take a long time until you get a response in your bug,
or maybe you never get a response in there, because maybe there's no one looking at that bug.
And last, there's someone from the community that is also Ubuntu-Cordet for an uploader,
somehow, that will be taking care of that package, right?
So then again, how can universe bugs get fixed in Ubuntu if nobody is actually looking at that?
So there are a few ways on how those bugs get fixed, right?
First, there's a chance that the delumentiner of the package, as I said, the packages are
copied from the delumentiner type, right?
So the delumentiner is using launch pad, the launch pad bugs,
as a source of work for his package, because if you go to the delument tracker,
you'll see that there's actually links to for the delumentiner,
you'll see the bugs that are open in Ubuntu against their packages.
So some developers do look at those, right?
Maybe there are a community of loaders in Ubuntu as well,
like we have for the developers that are not working in the delumentiner.
And maybe they are interested in specific packages in universe,
and they will get to fix them, but I'm talking about 36,000 packages.
So I doubt that there will be people looking at all of those.
And other than that, we also have non-apploader contributions, and what are these?
Let's say you find that bug in material, and then you want to fix it,
and you have a patch for it.
All you need to do is attach that patch to the launch pad bug.
Our optimizations will realize that, I guess I'm going to hit here.
So after you do that, someone will need to load that patch for you, right?
You need someone with the loadbolites that will get your patch,
will view it, give you something back, interact with you a bit,
and then patch the package and upload.
But that will only happen if they are monitoring the bug.
Otherwise, how will they know that you sent them a patch, right?
So the response to this is that it's possibly a quibi, okay?
It's a quite simple page. It's a single page where, oh, this is awful. Sorry, guys.
It's a single page where all the patches that are attached to bugs somehow get listed
for the whole archive, for long-spat, right?
So a bunch of core developers or a loaders,
a motor, whatever, they can come to this page and they can see the state of external contributions
you've been to, okay, and help the community here, right?
Meaning that if you want to do a community working about it, you just go here and you can help people, right?
But maybe this is not enough, right?
Well, what will drive someone to come to this page and actually look at that, right?
So the answer to that is the Ubuntu patch pilot program that we have here.
So Ubuntu uploaders take turns, they take shifts, usually four hour shifts to work on this
sponsoring quibi. They are usually available in IRC, in Ubuntu developer, during those hours.
And you can check that to the channel topic.
If you read the topic, there will be an entry on who is the patch pilot that is working at that moment
at that time. They're not necessarily canonical employees, but canonical does indicate two developers
per weekday to work as pilots at those points.
So if you ever need to get something quick, don't, with in-depth questions, whatever,
just go to Ubuntu developer, check the topic, who check who is the pilot and you can think that
person directly in IRC, right? On the side note here, we're moving in one or two months to matrix,
maybe in the end, what we can help you here with, wherever, whenever it's going to happen,
because I don't recall. First of all, thank you. So one note here is that this program is not exclusive
for packages in universe. You can send packages to whatever package and we will look, of course,
that if you send a package to, if you send a package to a packaging main, for instance, let's say
you send a package to PHP, right? There's a high chance that someone, because it's a packaging main,
so there will be a team dedicated to that in canonical, and there's a chance that the team will
probably get to it before a test pilot says. But anyway, you get what you need, you get reviews anyway.
So it's not exclusive for universe packages, and one important thing here is that the program
prioritizes the non-cononical related work. So we want to actually
help the community land packages, we want to interact with you, we want to try their packages
and get more contributors aboard. Yeah, I guess this is it. The sponsoring
quiz is this, or I also have a QR code here, if anyone needs to want to check the page,
and there's an announcement, it's all because the program is a bit old, but it's explained
the whole program. So if you are a want to port a developer or a mode to, or you have, if you
have a plug-bride in any sort of packages, and if you'd like to help, maybe join the rotation, or just
see how the program works, you can build all the details in there. I guess that was a bit short, but that was it.
Thank you.
Questions?
Hi, I thank you for the talk. In the beginning, you mentioned Devion developers and
Vinti developers and Devion has teams and individual contributions, et cetera, and in Vinti,
you got, can you just explain what the responsibilities are of each of those teams, because I'm assuming
that if there is a new version of a package that hasn't been updated by the Devion maintainers,
you have Vinti, or not going to update it to a later version. There's a great question. Yeah.
That's not entirely true. I mean, mostly we are following Devion because we are derivative, right?
But we have packages in Maine and depending on how the team feels and how the team that is maintaining
that specific package decides to go for instance, for example, let's say that there's a package
that is in Devion, but it's Devion package with a development version, because we are two years away
from the next Devion release, right? And there is a new LTS version of that package out and that
incident package it yet. And in two months, we're going to release a new Vinti version. Most likely,
if that package is in Maine, the team that is taking care of this package will understand that
we want an LTS and we will go ahead of that in. We will package the version of that package,
that is nothing Devion. Or we can also interact with the maintainer and check if they are
really true, get packages from us to update the package in the next version. For instance, I did this
with PHP of the last release because we were on H2 and I wanted H3 in a regular I guess and then I
went ahead of Devion. And now Devion went ahead of us with H4 and now I'm trying to catch up.
There's a question from the chat that I'll relay. Do you think that packages have no specific
owner, but being community maintained by an Ubuntu is an easier system to maintain compared
to Debian or Fedora, for example? It's just different, I guess. Because when I joined the
Canonical, when I started working on Ubuntu, I was always afraid of stepping on someone
those. Because the idea that you can touch any package you want, it's like okay, but maybe someone
did something here and they don't want you to change this or that. So it's just complicated.
You have to learn how to navigate the distribution with time. Let's say.
We do, sorry, we do reduce the bus factor there with days, right? I guess that's what Andreas
in Devion is trying to do. Not having all the packages been maintained by everyone, I guess that
would never have. But I guess the idea is to share that there will be more people able to
response to a package in time.
You've shown the number of the packages that are there. Do you think like the so high number
is like sustainable long time? I think that can definitely help, but are you planning to do something
about that or just the idea about like if it is like fine or you are motivating bigger number
the better or? Well, the packages come from Devion, right? So, and I don't even think,
I'm not a vendor developer as well, I forgot to mention this. I don't even think that
they can answer this question as well. Because Devion as developer, you can upload packages and
then let's say you are packaging this shine in you JavaScript thing and then you upload 200
dependencies in one day and that's it. As long as they are maintained, right? I guess it's okay.
Okay. Any other questions? Now, all right, thank you.