 So my name is Adam, and this will be a mostly discussion about modularity. And there will be short intro to just keep everyone on the same page. And then we can discuss various problems mostly like what should we modularize, what should we modularize, what is it useful for, etc. So who knows modularity? Who heard about modularity before? Almost everyone. That's good. Okay, so modularity is something regarding multiple versions of applications. That's probably true, right? And yes it is, this is the basics. But then there's the other question, if it solves all the multiple version problems? And that's where we have some confusion, because the answer is definitely no, not really. There are things that you could do before regarding multiple versions that you can do now. It helps with some things that you couldn't do before, but there are also cases that you could do without modularity, but modularity doesn't really help you, and we'll dig into those. So let's have a quick recap first, before we start discussing about the modularity concepts, what it is. So who heard about streams? Almost everyone heard about streams, of course. So just to recap is to put it super simple, like if I have Fedora releases, and there are some packages, if I want to modularize something, if I want to modularize the language, what happens is that just like there's this envelope around the package of language, and that's it. It's built a little bit differently, it's consumed, it can be consumed in a very similar way, but that's basically all the difference, but this isn't why we made it, right? We made it before because we want to have multiple versions. So there are two versions of the language, I still have the two versions of the language, but I can build both Fedora releases, so there's more flexibility what version you want to have, and you don't need to really care about what Fedora release you have because it's available for both. And there's this space called lang, because we have the lang modules, and you can think about it, there's just one slot on your system for every module, so you can install both, right? You can only install one version at the same time. So this is streams, I don't think that's new. Who heard about stream expansion? Okay, three people. So stream expansion is something, how do we deal with multiple versions of dependencies mostly? So imagine I have two language streams, the same ones we have before, and I have two applications, and both applications can work with both languages. I can say that I just want to build this, and it somehow expands, and that what happens with the binaries. I end up with four binaries of the app, and for each language I get two, so I can basically deploy both combinations on my system, and this is the way how I can deal with switching the languages but keeping the version of the application, like that's how we can do it. It switches the binary, but the application version stays the same. And I know this is a little bit confusing, but you can also look at it from the other side, so you can say that I have two versions of applications that are compatible, both with two languages. So that's basically stream expansion. And then, I've already mentioned this, but no parallel installation, so that's the same picture we saw. I can only install one stream of language onto a given system. And that was basically the basics of modularity, like really high level. And now I have some examples. I have three examples of packages that we can look if modularity can help or not. So, because modularity is still in progress, like a lot of things have been already completed, but not everything has been done. So I'll be looking if it helps right now, and if it helps by design, which means like when all the features are completed. So the first one is DWM. Anyone knows DWM, by the way? Cool. It's a window manager. It's a package that nothing depends on. So it's just an application, and we can see if it modularizes, right? The answer is yes. It does by design. It does right now, because you can just put it in the envelope, build it, even in multiple versions, and it's available if it runs out. I think we have four streams, four versions available. You can install it, consume it by the same way you did before. This is the most simple example. Okay, Node.js. It's a language. It's an interpretive language. There are also multiple versions, but some applications might require it at build time or run time. And I have the same question if it will work fine. Okay, the answer is current state almost, and by design, yes. Why I say almost? So if something requires Node.js at build time, which is not a module, that's a problem right now. But by the module design, if you have a Node.js, and if you have a default stream of Node.js, I don't think I've mentioned default streams. Who knows about default streams? Okay, almost. Cool. So if you have a module stream as a default stream, it behaves as a normal package, so you shouldn't see a difference. But there's a difference now in the build route. It's not visible, so that's why I'm saying it's almost. How we got around, how we basically work around this, that we built also Node.js and standalone packages. Stephen did that. So that works. So there are still some things that need to be coming. And the last example, I couldn't think about anything specific, but it's a library that changes really rapidly. And application need to adapt, right? Do it. And they don't do it at the same time. So you will need multiple versions of the library on the system at the same time. So, again. Oh, do you have an example? Look at two. Look at two. Which is the one that caused a whole lot of problems in your library recently. Okay, so look into an ICU. Two examples of this. And the answer is no and no. Mochilati doesn't really deal with parallel installation, but there are existing mechanisms that we can still use. Compat packages, for example. It doesn't make sense to put them in strings because you can install in parallel. But, yeah. So this is something that Mochilati doesn't address, but it's been addressed way before, and we don't have to solve it again. If that makes sense. Can you explain on that? I can. Yeah. So, who heard about Compat packages? That might be a good question to ask. Alright, just a few people. Alright, sorry about that. So, in Fedora, or in any app in distribution, how it works in an app in packages and each app being named can be present only once on your system. And if you have multiple versions and you do an update, that's not true. And, okay, there are exceptions like the kernel package. No, that's not true. If you are speaking about RTM, then you can have multiple. Okay, so both Fedora works. There's general practice, yes. The package manager is something different. So, now we are talking about the... Okay, so technically, with DNF, with Fedora, how it's done now in the most common sense, we get one package at the same time. There are special cases, but there are very special cases. It's more importantly, it doesn't actually matter how the RTMs are suited or anything else. You can only have one copy of the same library that the rest of the system is aware of because it does dynamically look up all the libraries on the system. So, if you don't change the names of them, it gets confused. Yeah, so, yeah, like, if you have a file on your system, it can be just that one's in the path, right? If it doesn't include the version. So, but they have libraries that need to be there in multiple versions. So, what happens? So, you can rename the file. So, it's a different file name, so it exists at the same time. But you also need to rename the package. So, what people do, they would either put the version into the package name and maybe get actually word compact as the compatibility. And there are ways how to deal with this, but you need to basically change the name of the package and change them over the files. So, that's how you can install multiple versions next to each other. And this is something that modulality doesn't address because modulality deals with alternatives, basically. So, if I show the slide that we have there, I can choose language one or language two and I want them to behave the same. I want to have the same executable, for example, on the system. I just want to choose the version. I don't want to change the packages in a way that they will install somewhere else. Like, for example, with software collections or other mechanisms that can mangle that, right? So, whenever I don't want to change the package and want to have multiple alternatives, modulality could be the good solution, but when I need other hacks, it basically doesn't help if that makes sense. Okay, so that's an idea if we should introduce the concept of compact modules. I don't think that that really makes sense. It's a perfectly reasonable thing to include compact packages within a module stream, but I think you really only need to have a layer. I think moving that to a module layer is... But assuming that I have pair of libraries which are actually coupled to each other... This is a module stream. But I want the same use case, like to install two versions of this library on the system at the same time, but each of those libraries is actually combined with another package. So I have a group of packages which work together, and I want you to be installed at the same time. Then you come to compact modules. Again, I still think that you can implement that on the RPM side where each module will carry... Module A will carry dependency A dot SO dot 1, and module B will carry dependency A dot SO dot 2. So what I think is going on here is that when I have modules, I have only one package language one, but they can have multiple packages in them, and what modules can also represent application language runtime, and they can help you with installation as well, like if you have multiple packages, but from an application you can even have multiple ways how to install the application, like a minimal installation or additional features or a database server client. So you can basically group multiple packages in one module and use it as an envelope and you can go to the application, and that's basically what you want to do. But you want to have these two versions at the same time, right? You want to have the envelope feature, but you want the parallel installation. So for that, we can do something like this, and we're already doing it with Python, for example, which is a little bit of an edge case, but basically we have Python modules that are called Python version, like Python 3.6, Python 3.7, and because there are different module names that contain RPM with different RPM names, that contain file with different file names, but they don't collide. So you can basically do that. So this is like a compact module. I don't want to say that because that might stick. But yeah, you can basically engineer that. The process is a difference from the top level of module names and the entire set of packages which are in code. And like two sets of files. Exactly. So it's a similar concept to RPMs. Like whatever is the name, so you can have one app in the name on the system, one module name on the system. But yeah, if you make sure that there's no collisions, you can definitely do that. What is the advantage of having a Python like this and doing like the old, just parallel install, like having three Python 2.7 and Python 3.6? So actually, probably this is that with Python. Just as a point, because we actually do have modules that are module names, Python 2.6 and Python 2.7, and then Python 2.6 and Python 3.7, which are parallel install and modules. Yeah, the stream. This is quite what you've been doing in the stream for a committee. Python is one of the very special cases. It's a module for more critical reasons than it is for technical ones. But it is still parallel install. It's kind of a word around it. Python was a very odd case that I kind of broke the assumptions, so we figured out a hack around the board. There might be user benefits and package benefits in packaging something, I guess the ratings were wonderful, but even the example I had like that which was just one stream, you can learn from the from a package perspective, is that you can, instead of building all the packages individually, something individual built, every single package for every single for the release, you can submit the module just once. Just the module built, and we have a system that will always have builds for you, and we even have a way out to describe build for example. So like it might be easier for you to describe your application this way than having it just rebuild by one command. And we even have some like a lot of things in there that if you publish one package, you can only build the one package, and things like this. They're not super advanced, but like basic stuff you can do. So that's like the package advantage. If you're interested about it, you can use that. The user benefits are if the application is for example more complex, and as I am, like basic packages, and you don't want people, you don't want people to figure out like what the individual packages are. Like for example, I like the database example. If you have a database with multiple packages, and you can have some sort of row files, installation row files, you can install database as a server, or as a client, and it will be the right thing just for it. Pretty installable. So like, that's what the user experience is like. And then, from the packaging perspective as well, like what I talked about with the stream expansion, like this. If it's a language, less people stream expand on that. They can build modules on other modules. So that's way easier for them to manage. So like, mostly the orchestrating part for the builds and the user experience. Back to my slide deck, I just wanted to basically walk through these examples and make sure that like everyone is kind of on the same page. And the way, I don't want to say fires, maybe they're the fires, in paragraph with like misunderstanding how to use modules and some people that maybe trying to modularize this example, which, and then saying like, modularity is broken, which is not. It's just, having been architected for this. So, like if you have any questions, problems, or maybe topics to discuss, then we can all learn and maybe take notes and make sure that the documentation is right, or that would do things, that everything is just like, useful also to explain that we did, this was not just, that we didn't design it that way, so we explicitly chose that that was not a problem we wanted to solve. That's a good point, yeah. Yeah, that was, this is, yeah, this is very designed, because we don't want to re-implement things. If your goal is, we only want to implement something. We don't want to implement things that were not possible easily before, right? But for our installation, the existing ways, like the combat packages, or containers, or other ways how we can achieve that, we don't want to make it without making that continuous or something, right? We just want to make it easy to pick the alternatives, which was, which was the most designed use case for like an enterprise world, where one application money, one user space, and you don't need multiple questions in there. Okay. Some of this, some of the lessons learned from software collections, what red had been relevant in software collections, it pulled the users over time, and to find out how they were using it. And they really liked the concept of being able to install, you know, having available a variety of different versions of things to install, to install different monitors, different pipe on, etc. But they really didn't like the way SCLs forced them to think, to install stuff in alternate locations, they had to rewrite their software to find the SCL locations. So, and what it turns out is that they were almost never using the parallel installable feature of SCL anyway. They were generally creating containers or VM hosts that had picked one and just used it. They weren't using the two or three versions in those cases. So, when we started to design modularity, we expressly took that requirement out of it, which simplified a great many things, because in that modularity, you can just, similar to the old alternatives, we just slapped things into their standard location and any existing software that you built on top of that doesn't need to be modular. So, that was a very conscious choice, not to support parallel installations in that direction immediately. Before I get to your question, which I will, immediately, I see like some people look like, this is not like super entertaining talk, and to be a discussion. And if you just came to learn about modularity, and you want to leave, I won't be offended. But if you want to contribute to the discussion, let's do that. That's fine. By Steven. I just want to hold you by force if it's interesting for you, if you just like want to learn. We have other sessions, like right after this one will be a session by Melanie, who's right there, who will teach you how to build modules, and we'll have one more, I think, tomorrow was Sunday, it's like a two and a half hour brainstorm for the discussion that will be actually actually solving problems. This one is aimed for larger audiences to learn to figure out things, but later though we much more focused group that will actually implement fixes. I just want to shift it all because my point of view with the use cases here is to express that we are all valid and reasonable, and it sounds like we solved the problem which we chose to solve not just all the problems in the world, but my concern with modularity lies between the concept of API packages and non-API packages of a module. So I think this is the root of our problems in modularity right now because I don't know if we can describe what this means yet. So in a module we can use many packages, and you can choose which packages you consider to be your public interface of the module the things which you provide by this module and which packages you just use as a part of this model but only to build this module to make it work. So you don't expect users to use the non-API packages from your model in any other way only just the model should do that. Basically you don't support any other packages. I think there's a little misunderstanding about API and I can sum it up. So yeah if you have a module with multiple packages and the module has a stream and I have for example the language one, language two and if you choose language one and you do updates you will get the latest version one but you won't switch to the version two this is for compatibility reasons and the compatibility is defined somehow and if for some reason there are multiple packages like language one and something that the language one uses we can express that the compatibility is only in the language one package. So the other one can get changed maybe even randomly and you shouldn't expect it to not to change because we define the guarantee in the language package so that's the API she was okay so even like we can okay so so the other the other aspect of the API field is expressly to describe to your user community that we only you know we only all these other components that are part of it are supported insofar as they implement that insofar insofar as they support this package if you have other problems either I can or won't maintain for that because I don't have that expertise you know I pulled this in because it's a tendency and nobody else was maintaining it in Fedora so I'm going to say I'm putting in this in this module stream it's just for my module if it needs to be used from other for more than one module that at that point those two the two module often needs to describe it to decide where they're going to put it are they going to maintain fully and move it into Fedora or are they going to put it into a special module stream so that it can stay it can remain limited in scope that is a problem that needs to be sorted out between the module authors and it is a known issue this is particularly difficult it is a niche because from my understanding this API non-API difference only is stored in like in module metadata and when you use modules you basically don't see it in any way from how you operate your packages you don't need to know what this package is you do you see DNF info I mean just like I mean sure you have to go look for it a bit but the information of what RPMs are part of the API is available to consumers so even using DNF info on a package it marks that there's a non-API non-API transformer DNF module you have to look at the module itself these packages are API if I look into that I think she's right I think it doesn't expressly say which packages you have in the solving system that aren't API that issue this module which is probably a USN we should fix yeah yeah I mean although in a sense you don't care but you want to know the use case for example I have a couple of modules installed on my system and now I start to work on my other project I'm doing my personal application with some dependencies and so because these non-API packages are put in the same name space as any other packages I don't get any alerts that I'm using a non-API package for my work I just didn't notice it it's just available in my system and I implicitly start to use it and no one tells me learn about it that this is a problem that I need to go to my tenure that I need to figure out that we need to take this package to the API level or to another module or to my system because otherwise it's just implicitly available and I use it as implicitly available so basically what you're describing is exactly the problem of like rail optional right is that you know we've had this we probably from a US perspective we probably should say that these things are you know less supported whatever that means let's look at the rail in this this is no I'm saying this I don't want to use it it's a metaphor that is the rail option is a 100% wide optional kept getting used and everyone thought it was supported because it's the exact scenario it's the same exact problem but if you've been on Matu Miller's talk in the morning he was talking about people someone they don't want to marry him for everyone and this is basically it like without modularity that was a problem with modularity that is still a problem it's a different implementation but it's so we there's at least a field that you can define like these packages and you're right I don't think we are going to have on this one sale I was thinking maybe we don't need different names but the other thing about the other thing about this is that it's mostly only a problem in default streams yes for non-false for not you know if it's in a non-false stream it just doesn't appear unless you but if you can solve it though anyway if I enable this stream a non-defalse stream I also get my names case of packages with the package and they didn't know that it's a non-packageation reliant so I don't have a different stream with very reliable packages and non-reliable so I mean we have a bit of size modules too right and your size is probably kind of using some library out of copper that you know you thought was all coming from mainland fedora right so we have this problem kind of across the board yeah but with copper I think I do review them in mock environment we know that my list is installed and I get the point but like I want to install something but with modules I get it installed only with default but I get it installed because the part of the module but I just don't know but it's not yeah it's copper so then it's like it's on a library yeah but the training is the same or both the same program for software collections because once you enable software collection you enable all the libraries and you don't know what is the support level for the libraries the system there's no difference but you enable everything from the collection But there probably are U.S. things that we can do because we do have that metadata that we can use in some of the collections that are available, we probably could have a DNF that we say, hey, you know, at the bottom of its transaction, yes, you know, the following packages, which are limited general orders, they're not supported for general purposes. But the second aspect of the same problem is that we kind of don't read the level of the internship in Fedora, like the Java packages started telling us, like, we say that this package is maintained as a part of the default stream, but it's actually, this means this package is not maintained. If it's a non-impact package for the default stream, that means this means we have an entity supporting Fedora from this package, yes, so we should... I think there's a good strong argument that default streams may only carry API packages. And so that if you absolutely don't want to maintain it, you may not be a default stream, you may be a non-impact package. So the default stream cannot expose or contain non-impact packages. Can you be like a binary package? I mean, we are going to have some build-up stuff that you can mail in, you know, pull things in just a little bit. No, don't install. I think this could be a good, actually, solution for the main problem we have right now. But also, we need to add this to our communication that, like, yeah, you can't call yourself a maintainer of something in Fedora, but if you maintain it in only non-API way, it's like it's not a full maintainer, so it's something different. And we need to differentiate the status of maintainers, because if you maintain your proper package and if you're a maintainer, then the API package would use for something. It's a lot different. It's a different level of commitment. So I should take some notes on that, that exact concept that Matthews talked about earlier. I think one of the things we might want to do is create a big, fast account that is essentially semi-maintained. Well, that is the main society. Maybe creating one module maintainer is a status that's also a little... Yeah, exactly how to do it, but I think we probably want to encapsulate in the actual database that these are not full... That we know that the person who's doing the builds is not a real maintainer. Which is happening, it might be happening now with packages, but this will be much more transparent. I'm also thinking of our message to new contributors where we need to tell them that we're actually looking for maintainer of a package, even though it's existing in our model of repo, we're actually looking for a proper maintainer of a package. And if you have these per cycles, we need to advertise this possibility to take his name to the proper figure repository because we need to... So this is a really good discussion, and I think we're now solving a problem in a very good way. So if you could please take a note to open the description. And maybe if you want to come to the ball to maybe discuss it twice deeper. That would be great. And yeah, that's definitely... Like, we have some of the data in there, but exposing it definitely. And the policy proposal for not including learning the package in the building is also something that I see as well. And yeah, I don't want to shut this down, but I also would agree... Sure, sure. ...with space, and then we can... So you just wanted to know the thing that we need to tell this information somewhere. I just... Oh. Right. Yeah? So I mean, I don't think that's really a serious problem, but I mean, it's a very automatic dependency, especially on the app end, it's a little bit of a guarantee, because I think it would... Yeah. ...such issue when the module... dependency... Pardon? ...exploited an object, somehow interfere with the normal app end approach, definitely. So if there was automatic dependency, the app end dependency was the module? So it would be... Or maybe... ...some kind of next space. I think what you want to say, I want to give you a little bit of help. How module works? If you, for example, enable this module, I want to install the language to package. It happens in two stages. So, like, all of the packages, let's say, are in one repo, okay? The package one, language one, language two. So first step is that you enable the language stream to module. So, what happens? You have a pool of packages, all the normal packages, you start with those, and then you take all the packages from the enabled modules, and basically put them on top of it, you might replace some packages from the module. And then you have a limited set. So you only have limited set of this package one, language two, and nothing else in this case. And then a standard package transaction happens. So this is... It looks... It works somehow like repository. So, like, the modules basically leaves the content set that you do with dependency resolution and then with dependency resolution. So that's how we work for it. Does it help with the question? It's like... It's like... It just tries to... Oh. We can't do that. Yeah, because we can't do that. As I was just saying, the question was... I'm not sure it's right. It's an impediment. So I was just saying that the question was... Is there a meaning to that in the case of this short? Because I think what's been... the things from the moderated module, where it's been closed into works, not from the non-mobiliarity point of view, where we experienced that in time, where the non-modular... Yeah. ...the non-modular set of packages that is the non-mobiliar system. But... Yeah. So I would say that within the distribution, we should make sure that the distribution is somehow consistent or somehow... That would be the way... But the non-modular distribution is not consistent. There are plenty of packages to consider. Yeah, but it makes sure that it's broken. But exactly as Steven said, even if there are... because there are alternatives, in a sense, multiple packages provide the same file, for example, in different implementation, or whatever. So this can happen. And we should make sure that it's broken. We can just... if we install something and you can't install something else, that's completely normal. That happens with the non-modular system the same way as it can happen with the non-modular system. So, looking at this on the project level, that's one step. But then we can have third-party repos, like IBM, BeautyLover, whatever, that basically can't interfere with your system. And... I mean, you can have a repo that's just great service in the company, and there's no control about that. So it's not a new problem, but... But that updates testing. So, to give you an example of how... Sometimes, though we are... every week of the type, we have to be able to have some... I can't see that... any of that features. We have this example, that we don't want to force this library on the user that don't want the patent-enabled version. And that's... for example, we disable automatic dependency on this library. So, it's kind of the same... issue. I mean, don't want to... But that sounds to me like you're trying to second-guess the packages' decisions as well. Yeah, that's a good talk. And that's... that to me is something you should file as a bug against the package, not that I expect to be part of the launch of everything. Yeah, I think we could have taken that as our example. What does that mean? I think it's great to have a vision to take care of. I think it's a... So, the other idea I was trying to explain is that maybe there isn't a need to have... I think the Bitcoin example was interesting because with Python, you have some kind of dedicated system being carried for a given Python version. And what I think is interesting would be to have some kind of namespace linker for a given model in reality. So, I think this is solving a different problem. Yes. What should I say? Let's say there's a big dependency on robots. Right. No, I get that. But, like, as I... on the... Let me just switch this night. Like, when I said that what should I say doesn't solve all the pyrologies really, all the multiple versions probably. At this point, you want to... Like, what I think is, it feels like a big project and there are a lot of technical changes to make it happen because it's kind of complex. But the concept is very simple. It's just people may be expect more of it than it actually is. It's basically putting everything into an envelope and have alternative strings. Basically, nothing else. You don't want to... At a fundamental level, it's basically, like, enabling... enabling a real-world application effectively and then with the schematic that just says that the collaboration that was already there wins. Yeah. That's pretty much as... most basic with... much like, it's just an actual repo. And we're not influencing the dependency resolution or nothing. It's just... Yeah. Because we could have done that with repos, but then imagine that you would have so many repos on your system that you would have to manage. And also, a repo is not an application. A repo represents, like, a vendor or third party or some entity. And their software, like Fedora repo, party inclusion repo, and they have lots of applications in them. Right? So it's like, repos, within repos, that is also one comes in how to think about it. And also, if you have those dependencies, like the stream expansion, for example, like, if I won't have an application to work against these two, but for example, the stream one might not work with stream one of these. So you can describe this, you can describe it both for the user, so only the right instance can happen for the user. And you can also describe it in the build infrastructure. Like, this is all built automatically, and from the build side it's mostly, most of this image. Like, it just, like, explodes automatically, but if it knows, if you define that, for example, this language stream doesn't run in its application, it only goes stream automatically for you. So, yeah, it's basically just the same thing. And, yeah, but, no difference in resolution, innovations, or anything like that, or no, I'd be interested to say that, I'd be interested to say that. One, one time, one additional time. One additional time, but that's an implementation. So, yeah, that's a nice problem to solve, and I think that's, you will sort it the same way with and without modularization. So, yeah, it's a real problem that you can solve outside. And I don't want to, I don't want to say, like, this is my problem, just solve it somewhere else, right? I don't want to say, I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm I'm So maybe he's there, we're going to expect it to be supported with federal authority and I think that's the best way how you can tell. So if there is, for example, no JS. There is intent to be able to do that down the road but we had, we had a bit of a clashing with that infrastructure because they were taking down sources that we were interested in, that the line amount to be able to report that information. So we haven't been asked how to get that information with storage properly. So for the time being, we really only work with the release standards. Can I say it wasn't by design. We should be able to sort of tell about your idea or not. For all of it, it's one of the good news, I guess, about that then you can have a different super project from prior actually. What was the current policy on this? Which support side was one of the, do we have restrictions now? For defaults? For defaults. So what, just to make people aware. If you have built and released it on a Fedora release, it must be supported to the end of that release. Can you kind of have anything shorter on that? Realistically, you know, if you stop stripping updates, it's gone. But a user can reasonably expect to have you fix it because it's still a support release. And the second plan for Rally? No, Rally doesn't have a complicated policy. And originally, Rally, I thought it was originally planned it would be super simple, but it's not. So there is a web page in the customer portal with a list of when each thing is, what is lifetime is. So go look at that before making assumptions. But yeah, having independent life cycles for the modules, like independent from the release, that was one of the goals. They go to implement it somehow, yeah. So it's always the whole release, and maybe other ones. But basically, you know, you can rely on being, you know, kind of a third, that release, right? But then you won't necessarily have it for the next release. You can look at the next release if it's there, if it's not there, that's the best way for you to find it right now. Do you have a question? Well, at least on the plus side, I'm trying to do a distribution upgrade between them and stop you as well. That's true, yeah. If you try to, you know, if I system upgrade from 30 to 31, during that resolution, you say, oh, the node.js quality is no longer available. So you have to decide if it's going to be standardized if you're working on it. We basically do the same thing to decide, like, if that's what works, right, if the package wouldn't upgrade, it would basically happen for you, at least now you know that it's going to happen. It doesn't happen silently, right? It's the key. We can also choose to now start to maintain if you want. All right? Sure. Yes. We're trying to, basically, it's one of those things where you don't know what you don't know. So, you know, we have guidelines. Like, there is docs there. It's just, we didn't know what things were missing until we ran into the problems to go right about. Right, yeah. It's sort of a binary. But, yeah, this is exactly what, that was supposed to be the goal of this session, like to collect confusion and document maybe or answer them. And if you don't see that or if I describe it badly or something, just you know that for me, I don't think so. We'll write it again. Whether it's good or bad. Please. Hi. Remember, there was one other question which may feed into this question is the pattern of creating modules per minor version, basically. Is it a good or bad practice? What's the dependence on the package? The purpose of the stream is to provide updates that remain to their main pattern. If you have a project that, you know, on each minor release, like, say, V8 who changes its AVI, that needs to be a step up the stream. If you have a project like Node.js which only changes its AVI on a major release, then that's just right. And it's really good and it's well-deserved for each person. Even in the case of some of the AVI stuff, we had to talk for a long while about the fact that the CS, the dog tag that's built on, sometimes changes AVI in minor releases and sometimes doesn't. So what we redefined that is, you know, 10.6 means 10.6 and forward until it's no longer compatible. So 10.8 might be a new stream because 10.6 and 10.7 were the same, but they didn't. That was complicated and that was mostly because they're terrible version. Like PHP. Right, like that. You can basically decide if you create the Python 3 stream or Python 3.7 stream or Python 3.7.1 stream. How much do people care? All the upstream, basically, how do they drag? As Stephen says, you can have 3.5, 3.6, 3.7, so you can create another stream and they don't need to be... Yeah, use the best gentleman or your knowledge to think that you're packaging and I think that's the best advice for packages that don't have any kind of consistent consistency whatsoever and just acknowledge that it's not going to get that in the which is just telling your users we can't guarantee this is going to be compatible. The streamers don't need to represent versions. We call them streams and versions for this reason because they have some kind of stream updates that make sense and you can say these are compatible or these make sense in this way so you can define streams as you need to. Excuse me, isn't there DWM dev or whatever? There's one version of DWM then. DWM has like four streams, three versions and the one is latest which is like role-playing. I wonder if we need to add some limitations like on the policy world so please don't create models where we did commit or something. If we have to get that fine detail, we will but I'd like to assume that most of the people who are active for Fedora have at least been through DealerGuarding. Like we can define all the rules in advance or maybe let something break and then fix it later and also that goes to discussion like Fedora is not supposed to be broken but it's supposed to be doing innovations sometimes something breaks and we fix it quick enough that's good. I would also like to point out yet again that the guidelines and rules and all that stuff around RPM could not spring wholly from the mind of God at one point and then magically we were correct right? It took many, many years and many, many revisions and many people in great efficacy to make what we have today module suffer some of that same stuff we've learned some from what we know about our camps and how our camps work the problem space is actually smaller so I think we can do a better job at the outset we need people to make comments and recognize that we didn't think of everything up front and so we need to document it if we see stuff. I think we're running out of time. Thanks for coming and if you want to have a packaging stay here if you want to figure out how to fix some things modularity that's the ball I don't do I think it's Sunday. So it's in the schedule