WEBVTT 00:00.000 --> 00:11.240 Okay, so the idea here is that I'm going to talk about this program that we run in Ubuntu 00:11.240 --> 00:14.440 called the Patch Pylos program. 00:14.440 --> 00:17.880 It's mostly about driving patches that come from the community. 00:17.880 --> 00:23.480 So if you're having painful moments with Ubuntu, you can send your patches away and we 00:23.480 --> 00:29.360 will drive a patches in there and things will be okay. 00:29.360 --> 00:37.120 So my name is Atos, I started playing with these rows back then when I was in school 00:37.120 --> 00:50.680 with Fedora, I used to maintain a few leaf packages there, after that I joined Red Hat where 00:50.680 --> 00:54.440 I was working into container stuff. 00:54.440 --> 00:57.800 It's called OSBS, it's your container build system. 00:57.800 --> 01:04.460 It's 41s who understand Fedora and the build systems, it's a plugin that goes into Koji or 01:04.460 --> 01:12.360 Broo for run headers and it allows the build system that builds RPMs to also build OSBS images 01:12.360 --> 01:16.920 and shift them into container registry. 01:16.920 --> 01:22.600 So after that I was hired by Canonical to work on container stuff as well. 01:22.600 --> 01:26.080 Which never happened and for some reason all of a sudden I'm now maintaining PHP and 01:26.080 --> 01:27.080 Koji. 01:27.080 --> 01:37.460 So that's it, I work on the Ubuntu server team in Canonical and there we maintain packages 01:37.460 --> 01:46.040 related to servers like servers that database has high availability etc. 01:46.040 --> 01:56.040 So the idea is you can send patches to Ubuntu right now. 01:56.040 --> 02:02.040 There is an easy process to get your contributions uploaded here and you don't need to directly 02:02.040 --> 02:07.760 contact the potential sponsor who will personally look at your stuff. 02:07.760 --> 02:13.840 You just need to submit a patch in a launch pad bug and the whole process that there are 02:13.840 --> 02:22.840 some automations that we will ensure that your patch will get attention. 02:22.840 --> 02:28.000 Before we get there, let me try to explain how Ubuntu works in relationship to that. 02:28.000 --> 02:34.000 So in that we have the idea of having package maintenance. 02:34.000 --> 02:36.000 So each package has a maintainer. 02:36.000 --> 02:43.120 The maintainer may be a team, it could be a group or it can be a single person. 02:43.120 --> 02:50.120 The current DPL is leading several discussions around this to try to reduce the boss factor 02:50.120 --> 02:52.480 on package maintenance. 02:52.480 --> 02:56.360 In Ubuntu, the idea is slightly different, right? 02:56.360 --> 03:02.080 So all the packages in the distribution are maintained collectively, meaning that there are 03:02.080 --> 03:04.760 no single owners of packages. 03:04.760 --> 03:10.920 If you are a quarter developer, you can touch pretty much the whole archive in the developer 03:10.920 --> 03:16.360 release, right? 03:16.360 --> 03:22.600 In our development release in Ubuntu, the packages, as I suppose everybody knows here, that Ubuntu 03:22.600 --> 03:25.880 is a derivative distribution of the admin. 03:25.880 --> 03:30.200 So packages are imported from the admin in the development release. 03:30.200 --> 03:34.800 They are either in sync with the admin, meaning that they are the exact same package that 03:34.800 --> 03:36.160 are in the admin. 03:36.160 --> 03:41.600 For they have delta, we call them delta, which are patches that Ubuntu applies on top 03:41.600 --> 03:48.120 of them, either to a powerful thing, as they were saying here earlier, or maybe the release 03:48.120 --> 03:51.040 schedule of Ubuntu in that in are quite different, right? 03:51.040 --> 03:55.600 So maybe there's a bug in the package, we forward the package to that in, and maybe they 03:55.600 --> 04:00.160 want to merge, our changes, they want to upload our changes in time for release. 04:00.160 --> 04:06.160 So we have to edit the output to our package, to ensure that we release a good version 04:06.160 --> 04:10.560 of the package, like with specific fixes for instance. 04:10.560 --> 04:17.360 So the usual path is the package is uploaded to that in stable by the admin general of 04:17.360 --> 04:25.640 the package, then it's copied or merged manually by a quarter developer into what we call 04:25.720 --> 04:33.920 the series like for instance, fledging out, proposed, this package is tested with a gate 04:33.920 --> 04:38.280 in system that we use both in Ubuntu and the admin called Brutney. 04:38.280 --> 04:45.480 So it does several sorts of tests like instability, it will this package be installable in 04:45.480 --> 04:52.080 your cive whenever it migrates to the actual distraught to the release pocket. 04:52.080 --> 04:57.840 If the package has auto package tests which are test that you run in this installed version 04:57.840 --> 05:04.040 of the package, this test is run as well, it also runs test for its reverse dependencies, 05:04.040 --> 05:09.640 and then if everything is okay there, it migrates to the release pocket, which is the 05:09.640 --> 05:10.640 actual series. 05:10.640 --> 05:15.080 I will explain what the series are in the second and the pocket. 05:15.080 --> 05:24.080 And then we also have a stable release update process, which is the difference from the 05:24.080 --> 05:28.720 developer release in the sense of we don't want to break things, we don't want to change 05:28.720 --> 05:31.920 things, we want to have stable releases, right? 05:31.920 --> 05:39.720 So we go through this two rough review process on the bug and on the changes you want 05:39.720 --> 05:40.720 to propose. 05:40.720 --> 05:46.840 And then if they are acceptable, it goes through this series, propose a pocket, it goes 05:46.840 --> 05:50.960 through Brutney, there is some manual interface in there and then it finally lands in the 05:50.960 --> 05:54.880 updates pocket for that series, right? 05:54.880 --> 05:58.600 Okay, so how the archive is divided in Ubuntu? 05:58.600 --> 06:05.240 We have series which are the code names, the nicknames for our releases, right? 06:05.240 --> 06:11.440 So we have 20 or four, which is foco, 20, 20, 20, 40, and now we are working on 20, 50, 06:11.440 --> 06:14.520 40, which is plucky, right? 06:14.520 --> 06:18.280 In there we divide the series into pockets, right? 06:18.280 --> 06:27.280 We have the release pockets, which is the set of packages for a distribution at the 06:27.280 --> 06:28.840 moment of its release, right? 06:28.840 --> 06:32.560 So we are preparing things right now for plucking, we are uploading things into the release 06:32.560 --> 06:38.680 pocket, and as soon as it is released, this pocket gets frozen, and then after that 06:38.680 --> 06:45.120 if you want to make changes there, we upload things to this update pocket, right? 06:45.120 --> 06:49.200 We have the security pocket where the security team uploads, there fixes, the usual 06:49.200 --> 06:55.440 is CD fixes, the push in there, we have the proposal pocket, which is where we grab things 06:55.440 --> 07:00.200 to test and they go through Brutney through the gating system to land and then there's the 07:00.200 --> 07:07.320 backport bracket pocket, which is similar concept that we have in that game as well. 07:07.320 --> 07:15.080 Suits are the composition of a series in a pocket, so, okay, I will hold it, okay. 07:15.080 --> 07:22.840 We have, for instance, plucky proposals, foco security, etc., so we usually refer to them 07:22.840 --> 07:24.480 like that, right? 07:24.480 --> 07:27.880 And finally we divide the whole archive and this is the important point that I just wanted 07:27.880 --> 07:32.280 to get here, we divide the whole archives into components, right? 07:32.280 --> 07:36.760 We have the main components, the restrictive components, the universal components and the 07:36.760 --> 07:41.560 multi-versal components, and where do I want you to get, I want you to get here? 07:41.560 --> 07:46.120 These components are divided like this just to show if the package in there is a free 07:46.120 --> 07:52.160 software not and who supports that package, who will fix bugs for that package, right? 07:52.160 --> 07:59.160 So, main and restricted are the components that are supported by canonic, right? 07:59.160 --> 08:05.520 Main has holds the free software in a bundle and then we have restricted that where we have 08:05.520 --> 08:08.240 not so, not that free software. 08:08.240 --> 08:12.400 And then we have universe and multiverse, which are maintained by the community, and 08:12.400 --> 08:18.480 universe is where we have the free software in a bundle, okay? 08:18.520 --> 08:26.480 So, yes, today, last night, we have a little bit over 2,000 packages, source packages 08:26.480 --> 08:34.320 in the main component, 17-inverse free-stits, and universe has over 36,000 packages plus 08:34.320 --> 08:36.200 500 in multiverse, right? 08:36.200 --> 08:43.920 What does this mean is that canonic only contains about 7% of the packages in the own archives, 08:43.920 --> 08:47.760 which we call the Ubuntu-based packages. 08:47.760 --> 08:54.760 Which leads to the remaining 93% of the packages are actually maintained by the community, 08:54.760 --> 08:55.760 right? 08:55.760 --> 09:01.680 This is not entirely true because sometimes canonic only employees have strict touch, the universe 09:01.680 --> 09:06.880 packages for instance, like during a transition, as I said, we have a gate in system, 09:06.880 --> 09:11.880 so if the reverse dependencies are not working well, the package will not migrate, 09:11.880 --> 09:16.360 so sometimes we have strict touch, universe packages. 09:16.360 --> 09:20.280 But usually that's not what we do. 09:20.280 --> 09:22.280 So what am I saying? 09:22.280 --> 09:27.960 I'm trying to set the expectation of our users because you need to understand that the 09:27.960 --> 09:31.160 canonic will employ it for the developers. 09:31.160 --> 09:36.640 Our most likely not actively looking at bugs filed against packages in universe. 09:36.640 --> 09:42.280 For instance, when you file a bug against, let's say, more curial, the version control system 09:42.280 --> 09:43.280 package, right? 09:43.680 --> 09:48.640 Let's say you like it, you use it and then you file bugs in Ubuntu for that package. 09:48.640 --> 09:55.040 There's a good chance that it will take a long time until you get a response in your bug, 09:55.040 --> 10:00.560 or maybe you never get a response in there, because maybe there's no one looking at that bug. 10:00.560 --> 10:05.840 And last, there's someone from the community that is also Ubuntu-Cordet for an uploader, 10:05.840 --> 10:10.560 somehow, that will be taking care of that package, right? 10:10.640 --> 10:19.920 So then again, how can universe bugs get fixed in Ubuntu if nobody is actually looking at that? 10:19.920 --> 10:22.640 So there are a few ways on how those bugs get fixed, right? 10:22.640 --> 10:27.440 First, there's a chance that the delumentiner of the package, as I said, the packages are 10:27.440 --> 10:29.200 copied from the delumentiner type, right? 10:29.200 --> 10:34.000 So the delumentiner is using launch pad, the launch pad bugs, 10:34.000 --> 10:39.760 as a source of work for his package, because if you go to the delument tracker, 10:39.760 --> 10:43.680 you'll see that there's actually links to for the delumentiner, 10:43.680 --> 10:47.120 you'll see the bugs that are open in Ubuntu against their packages. 10:47.120 --> 10:50.000 So some developers do look at those, right? 10:51.600 --> 10:54.320 Maybe there are a community of loaders in Ubuntu as well, 10:54.320 --> 10:56.960 like we have for the developers that are not working in the delumentiner. 10:58.800 --> 11:02.880 And maybe they are interested in specific packages in universe, 11:02.880 --> 11:08.080 and they will get to fix them, but I'm talking about 36,000 packages. 11:08.080 --> 11:12.000 So I doubt that there will be people looking at all of those. 11:12.800 --> 11:18.240 And other than that, we also have non-apploader contributions, and what are these? 11:20.320 --> 11:23.760 Let's say you find that bug in material, and then you want to fix it, 11:23.760 --> 11:25.360 and you have a patch for it. 11:25.360 --> 11:30.400 All you need to do is attach that patch to the launch pad bug. 11:31.680 --> 11:37.840 Our optimizations will realize that, I guess I'm going to hit here. 11:37.840 --> 11:43.200 So after you do that, someone will need to load that patch for you, right? 11:43.200 --> 11:46.000 You need someone with the loadbolites that will get your patch, 11:46.000 --> 11:49.600 will view it, give you something back, interact with you a bit, 11:49.600 --> 11:52.480 and then patch the package and upload. 11:53.120 --> 11:57.360 But that will only happen if they are monitoring the bug. 11:57.360 --> 12:01.200 Otherwise, how will they know that you sent them a patch, right? 12:02.160 --> 12:06.160 So the response to this is that it's possibly a quibi, okay? 12:06.160 --> 12:13.120 It's a quite simple page. It's a single page where, oh, this is awful. Sorry, guys. 12:14.720 --> 12:23.440 It's a single page where all the patches that are attached to bugs somehow get listed 12:24.080 --> 12:28.240 for the whole archive, for long-spat, right? 12:28.560 --> 12:31.120 So a bunch of core developers or a loaders, 12:31.120 --> 12:37.360 a motor, whatever, they can come to this page and they can see the state of external contributions 12:37.360 --> 12:42.720 you've been to, okay, and help the community here, right? 12:43.760 --> 12:48.720 Meaning that if you want to do a community working about it, you just go here and you can help people, right? 12:48.720 --> 12:50.320 But maybe this is not enough, right? 12:50.320 --> 12:55.040 Well, what will drive someone to come to this page and actually look at that, right? 12:55.680 --> 13:01.040 So the answer to that is the Ubuntu patch pilot program that we have here. 13:02.240 --> 13:09.600 So Ubuntu uploaders take turns, they take shifts, usually four hour shifts to work on this 13:09.600 --> 13:17.840 sponsoring quibi. They are usually available in IRC, in Ubuntu developer, during those hours. 13:18.560 --> 13:24.160 And you can check that to the channel topic. 13:24.160 --> 13:31.760 If you read the topic, there will be an entry on who is the patch pilot that is working at that moment 13:31.760 --> 13:40.000 at that time. They're not necessarily canonical employees, but canonical does indicate two developers 13:40.000 --> 13:45.120 per weekday to work as pilots at those points. 13:45.200 --> 13:50.560 So if you ever need to get something quick, don't, with in-depth questions, whatever, 13:50.560 --> 13:55.760 just go to Ubuntu developer, check the topic, who check who is the pilot and you can think that 13:55.760 --> 14:05.200 person directly in IRC, right? On the side note here, we're moving in one or two months to matrix, 14:06.720 --> 14:12.000 maybe in the end, what we can help you here with, wherever, whenever it's going to happen, 14:12.000 --> 14:22.160 because I don't recall. First of all, thank you. So one note here is that this program is not exclusive 14:22.160 --> 14:28.560 for packages in universe. You can send packages to whatever package and we will look, of course, 14:28.560 --> 14:34.000 that if you send a package to, if you send a package to a packaging main, for instance, let's say 14:34.000 --> 14:40.640 you send a package to PHP, right? There's a high chance that someone, because it's a packaging main, 14:40.640 --> 14:46.800 so there will be a team dedicated to that in canonical, and there's a chance that the team will 14:46.800 --> 14:53.440 probably get to it before a test pilot says. But anyway, you get what you need, you get reviews anyway. 14:55.440 --> 15:00.400 So it's not exclusive for universe packages, and one important thing here is that the program 15:01.520 --> 15:08.720 prioritizes the non-cononical related work. So we want to actually 15:08.720 --> 15:16.640 help the community land packages, we want to interact with you, we want to try their packages 15:16.640 --> 15:24.400 and get more contributors aboard. Yeah, I guess this is it. The sponsoring 15:24.400 --> 15:30.080 quiz is this, or I also have a QR code here, if anyone needs to want to check the page, 15:30.640 --> 15:35.680 and there's an announcement, it's all because the program is a bit old, but it's explained 15:35.680 --> 15:42.800 the whole program. So if you are a want to port a developer or a mode to, or you have, if you 15:42.800 --> 15:48.800 have a plug-bride in any sort of packages, and if you'd like to help, maybe join the rotation, or just 15:48.800 --> 15:55.600 see how the program works, you can build all the details in there. I guess that was a bit short, but that was it. 15:56.480 --> 16:00.480 Thank you. 16:04.880 --> 16:08.880 Questions? 16:16.800 --> 16:21.840 Hi, I thank you for the talk. In the beginning, you mentioned Devion developers and 16:21.920 --> 16:29.280 Vinti developers and Devion has teams and individual contributions, et cetera, and in Vinti, 16:29.280 --> 16:35.360 you got, can you just explain what the responsibilities are of each of those teams, because I'm assuming 16:35.360 --> 16:43.360 that if there is a new version of a package that hasn't been updated by the Devion maintainers, 16:43.360 --> 16:49.520 you have Vinti, or not going to update it to a later version. There's a great question. Yeah. 16:50.320 --> 16:56.000 That's not entirely true. I mean, mostly we are following Devion because we are derivative, right? 16:56.000 --> 17:02.080 But we have packages in Maine and depending on how the team feels and how the team that is maintaining 17:02.080 --> 17:10.880 that specific package decides to go for instance, for example, let's say that there's a package 17:10.880 --> 17:17.040 that is in Devion, but it's Devion package with a development version, because we are two years away 17:17.120 --> 17:25.920 from the next Devion release, right? And there is a new LTS version of that package out and that 17:25.920 --> 17:33.760 incident package it yet. And in two months, we're going to release a new Vinti version. Most likely, 17:33.760 --> 17:39.920 if that package is in Maine, the team that is taking care of this package will understand that 17:39.920 --> 17:45.760 we want an LTS and we will go ahead of that in. We will package the version of that package, 17:45.760 --> 17:52.240 that is nothing Devion. Or we can also interact with the maintainer and check if they are 17:52.240 --> 17:58.080 really true, get packages from us to update the package in the next version. For instance, I did this 17:58.080 --> 18:05.280 with PHP of the last release because we were on H2 and I wanted H3 in a regular I guess and then I 18:05.280 --> 18:09.760 went ahead of Devion. And now Devion went ahead of us with H4 and now I'm trying to catch up. 18:10.080 --> 18:18.240 There's a question from the chat that I'll relay. Do you think that packages have no specific 18:18.240 --> 18:24.320 owner, but being community maintained by an Ubuntu is an easier system to maintain compared 18:24.320 --> 18:34.800 to Debian or Fedora, for example? It's just different, I guess. Because when I joined the 18:34.880 --> 18:39.680 Canonical, when I started working on Ubuntu, I was always afraid of stepping on someone 18:39.680 --> 18:47.280 those. Because the idea that you can touch any package you want, it's like okay, but maybe someone 18:47.280 --> 18:51.680 did something here and they don't want you to change this or that. So it's just complicated. 18:51.680 --> 18:55.680 You have to learn how to navigate the distribution with time. Let's say. 18:56.400 --> 19:07.120 We do, sorry, we do reduce the bus factor there with days, right? I guess that's what Andreas 19:07.120 --> 19:11.680 in Devion is trying to do. Not having all the packages been maintained by everyone, I guess that 19:11.680 --> 19:19.680 would never have. But I guess the idea is to share that there will be more people able to 19:19.760 --> 19:23.040 response to a package in time. 19:29.760 --> 19:34.960 You've shown the number of the packages that are there. Do you think like the so high number 19:34.960 --> 19:42.640 is like sustainable long time? I think that can definitely help, but are you planning to do something 19:42.640 --> 19:50.160 about that or just the idea about like if it is like fine or you are motivating bigger number 19:50.160 --> 19:58.640 the better or? Well, the packages come from Devion, right? So, and I don't even think, 19:58.640 --> 20:03.280 I'm not a vendor developer as well, I forgot to mention this. I don't even think that 20:03.280 --> 20:09.360 they can answer this question as well. Because Devion as developer, you can upload packages and 20:09.360 --> 20:17.120 then let's say you are packaging this shine in you JavaScript thing and then you upload 200 20:17.120 --> 20:24.080 dependencies in one day and that's it. As long as they are maintained, right? I guess it's okay. 20:24.080 --> 20:33.760 Okay. Any other questions? Now, all right, thank you.