 So welcome all of you to the volatile talk. And yet, I hope you can hear me. There's a basic idea behind volatile. Volatile is started. You see how it works, as all the started things. So volatile is started, it's more or less it's life during a discussion where Martin Troy Schulze and Jesus Kleinman were part of, as I discussed, well, how should the virus be updated during such a stable? Because a stable release policy is more or less just says, well, we won't update things except as a security box. Of course, it's not totally true. There are some other situations where packages can be updated. But it's not possible, for example, to bring really improvements in, but just to fix a C box. And a virus cannot recognize, in some virus types, is not a C buggy. It has important bugs, but well, they won't be updated in stable. And during that discussion, volatile archived section, volatile, was proposed, and the basic idea was to say, well, packages in that section get easier update rules in stable. But well, you all know how Debian works. Usually, nothing is done until one does it. So, yeah, we always decided, the idea was modified a bit in the ways that we said, well, first of all, we start with an extra archived volatile Debian net. This has also some advantages, we're not bound to use the installed type of those. But if we have an update, we can just install it right now. It's in the very, very same way as security during org works. Yeah, so that was the beginning of the discussion. Well, as soon as the first package for Woody was updated, that was the whois package. Whois had, well, no security issues or so, but just, it couldn't work with the .org domains. For .de domains, it could just tell if a domain is connected, but not who owns it. Which is of course both not, well, there's no security issue in it. But it's not too nice to work with such a package. So, we updated whois package. Now, shortly, now, but for Woody, we all knew that volatile is more or less just, we will try to set the technical infrastructure, right? So that we know how to do it, to look how the lines and up sources should look like, and so on. So, yeah, so for such the least, we made some, we updated some things. We have now in up source list, it's a very nice line, how it works. If you want a package, you can write depth, HTTP, volatile, Debian net, and Debian volatile. And here, you just write, well, you know for security, you write something like search updates. Here, you write search volatile and components you want. So, and now for search, we started with the first package to accept a scam off, the virus scanning engine. What happened in the success, what happened shortly after accepting a scam off was that we were hit by a lot of mirror requests of people wanting to mirror volatile, well, except after the car, we have now a mirror and an article. We have now a mirror and other continent of the world, in some continents more than one, and we have a lot of positive feedback. What I really expected was with, with, with Glamath, that we will get some negative feedback to say, oh, we jumped too far, because basically, we took a new Glamath version, but we modified the packaging to the old version. So, the packaging is the same. So that the change of behavior is, is only to detect the new virus. Yeah, but the user side was way more positive than we ever expected. So, I said to work fairly well. We had now as a second update to, to Glamath. Second update to Glamath is, is really only a security update. So we had a nice chance to learn how to deal with the security team, how to work with CVEIDs, and all that stuff. And as a result, it worked pretty well. We had good experiences with security team, but good experiences in our case means, we were able to make sure that the security team updates the package for both the search at about the same time as we pushed out the volatile package. We just had to deliver the security team all the packages are needed and the CVEIDs, but then it worked good. So volatile team learned one thing. We need a non-public contact address that we can give to the security team. The maintainers of packages we have in volatile, yeah. So, perhaps I should, well, so I think I should now say something about generic. How packages go into volatile or what they are supposed, what the guidelines for package are supposed to be. Or first, the most important thing with volatile generic is that we say, all right, first of all, it must not break anything. At least from the use of, from the administrator's point of view, using volatile should be as simple as using security. So it also means there's not just some new code coming in, not just a new block coming in, no new dependencies. But it should just work as before, but this is the bug fixes, with the bugs of course fixed, or with detecting new virus patterns, detecting new ways, if we speak about something like Jack Rootkit, which is discussed currently with checking new ways to hijack a computer, or whatever. So the second basic rule is, we do packages only in cooperation with the Debian maintainer for some very good reasons. As a one reason is, of course, it makes our life much easier. It makes our life, it makes our life easier when it comes to, when it comes to what do we really need? It makes our life easier, in the case there's some security update, like we had it with Glamath. And it makes our life easier because, yeah, it makes everyone's life easier, because we say, we must be able to use the Debian bug tracking system for volatile. So if there's any issue, users can just support the bugs as usual. And the maintainer needs to agree, of course, that we can use the Debian bug tracking system for that purpose. But in the end, it's for everyone easier to use that one than if we would do an extra bug tracking system for the few packages we have. And of course, we also definitely want that the upgrade from such was volatile to edge is as good as working as a direct upgrade from such to edge. And if you have to maintain in the loop for it, the maintainer says, yes, he will make sure that it works. And of course, it's very easier than if it's just a random collection of backpots. That leads me to the next topic. We are, volatile is not just a backpots collection. We really aim to make sure to say, okay, which, first of all, the question, if one asks, can we do an updated package of something? The first, well, the first question is, do we need it? Which bugs are going to be fixed by it? And Annalisa has a very good answer that says, this and this important bug are going to be fixed. Well, the default answer of such questions is, of course, no. And if somebody says, I need a backpot of something, there are lots of good sites as backpots, backpots.org, for example. That's not the aim of volatile. There are however packages where we say, okay, we really see the need to put them into volatile. But where at the same time we say, they are too much changed to put into the usual volatile packages. And for those packages, we have a section called Sloppy, so volatile Sloppy. Yeah, well, if someone had a better name, please say it. We had a discussion on the mailing list for about two weeks, where everybody says, the name is not good, but nobody had any other idea. Or there were some ideas, but we all agreed that any other idea is even worse. So if you have a good suggestion, please come up with it. We can still change it. In the Sloppy section, there are larger updates. And also, the Sloppy section is done in a way that the app doesn't use it automatically. So you have to pin up the packages you want to have. If you will do an update in the Sloppy section, we will put on code snippet for up references into the announcement. So people can just cope with that snippet. It can exactly the package they want to have from volatile Sloppy. We're currently discussing, Brandon was suggesting during another talk, that we put an XORC server package into volatile Sloppy. That would be a new package, so definitely not available for use in normal volatile. But on the other hand, it would allow a lot of new hardware to work. And it would work together with the current charge X client packages. And Brandon said, he promises that it will upgrade painlessly to edge. So on these conditions, we are currently concisoring whether to put it in volatile Sloppy or not, but that's currently not a decision. And decisions are usually done after we see the package not before. Because we are, of course, keeping care of a lot of small technical details. Of such a change, and also, for us, things important, like the change logs should really say what a change. Things like backport features from the upstream version is definitely not enough. Or I've seen a lot of change logs that way in Debian. Yeah, so I think that was now most of the very important or most of the overview of how volatile really works. And I guess there will be some questions. I can only see France starting with it. So please go on, France. I'm wondering what the reasons are to put something like X on volatile, even if it's volatile Sloppy. Why not just on backports.org? Because if you start doing that with volatile, I think you're going to be, you're going to put in danger the concept behind the real volatile. I think you should be very careful with that. I definitely agree that we need to be very, very careful with that. So that's the reason I said, there's no decision. We started concising it. I think concising it is not really wrong. If the maintainer says, he would be willing to do the work. And what I definitely would refuse, for example, is an updated X client package or something like that. What Brendan said, it would only be a new X server and nothing, not X space or so, and I think that might work. But I'm really not sure. And I have a bit of bad feeling about that in my stomach. I agree with you. Usually I listen to that feeling and I probably just need some more days to really come to a decision to a success. Either yes, we can do it or no, we should not. But I definitely agree that X, yeah, so it's definitely at least it's a borderline. But I'm not sure on which side of the border it currently is. It's also very easy for a maintainer to say now, yes, I promise to make sure the upgrade path will work. But we'll still do so in one and a half years time when we're going to be releasing Edge. And I think for packages that have fairly regular updates like Clamavet, it's much easier to keep the provider involved to make sure that the upgrade path will work than with updates that are basically done once or very infrequently. The provider may just forget he's on volatile, may lose interest in that part. And he may start to think about it as just another backports.org. I really think you have to be very restrictive with volatile and only do it for the packages that have like data updates with security implications, stuff like that, who is packages is also a good example. Things just stop working if information like that's not up to date. Yeah, I see the same problem as you do. So just, of course, I need to be careful. I'm not going to say, well, we will check this right from here. Because I'm really, especially for such decisions, I am a bit slow in deciding things. Because I really want to think them so and discuss them with other people. But I definitely welcome your input on it, Franz. And yeah, we will do a decision soon enough. And I also see all the reasons you said is very important reason what's against accepting XORC, yeah. I have a question, who do I ask about adding a package of all time? Because I sent the mail to, I think it was the message. There was some sent to develop an answer something about this. And I sent a reply to that address, and I never got the response about adding a package to volatile. Who do I contact? Yeah, okay, the basic is all that's what they've been volatile. It's they've been volatile. It lists they've been orc. It's also advantage that a lot of people see it. I have seen sometimes the quest directly flew into my private address. Especially some of the quest during about the same time as Sarge was released. And I'm quite sure that I forgot to answer to some of the mails. But if you would use it at that time, there was about ten hours of the day reading mails, answering mails, and pushing package in and out of Sarge, yeah, yeah. It happens, I'm very sorry for that, but it happens. And the role of this has a large advantage that there are more people reading it. And some people who are just saying, well, there was a mail. Don't just think you need to answer it right now. So please write anything to that mail address. And of course, what you want to have in the initial mail is, we want to make, or we want it to maintain a write, it's not just somebody else. And we want to be sure to know which are the basic functionalities that got missing during Sarge, and that should be added. And yeah, and something about how large are the changes. If it's a change of small, diff of it, or whatever it really may, it can work or start working on an informed position and not have to guess around, okay? So next question please. We are wondering that we may have to update COPE during the time of Sarge lifetime because all these proprietary instant message protocols will change during the Sarge lifetime. However, the problem is that COPE is part of KDE network, which is a very large package. Do you think that we should prepare just a COPE only upload for Volatile or just upload the entire KDE network with the back ports of the protocol fixes? Well, all these proprietary instant messaging stuff is really a pain in the ass. I agree. So just to make sure that we are all in the same position. Well, I'm definitely very opposed to upload something like KDE network to Volatile to update one of the parts of it. That's because I really think, well, it's too large or so there are too many things that are uploaded and if you want to change one of them, you might be perhaps better in a position where you upload a source package that only builds the parts you really need. But what I can say already now is that such an update won't be too easy for all sides to handle. For all sides it means for the maintainers, for the Volatile team, for everyone else involved because it's really a very, very difficult thing. And I also think we will have to learn something for Volatile during Sarge lifetime. And that is if we know beforehand that we have certain packages that are going to be updated quite often. Like we know for the instant messages. We should perhaps start to separate them into source packages before we release Edge, so that it makes our life at least during Edge's relief cycle easier. Also, we should try to separate data packages from source packages if it is possible, even if it's only a single data file. But if the data file is often updated as the binary file not, it might be worse to do it. Because if you have it separated, it's very easy to make sure that we didn't break anything. So yeah, I think such would be a bad thing to happen when we have to update things like game and so on. So next question, please. Peer. Okay, next question, on that side again, please. It's unfair to assume a sleeping people. So the Volatile archive was created to work around the staticness of the stable release. Do you think it's a good idea to have the current policy on the stable release? Do you think we should update with the newer kernel drivers and newer X drivers so we make sure the stable release is installable on the newer machines like the entire life cycle of a stable release? The answer to that is I don't consider Volatile to be a workaround. I consider, but if you want to change something in Debian, it doesn't change because someone says, hey, it's a good idea, usually not. Usually it's changed because someone starts implementing it. So we said, okay, we will implement now Volatile. And I hope to get enough feedback or that we get enough feedback. So the stable release manager can reconsider whether it's a good idea to include several types of packages in a stable release or not. Like for example, security packages are included and perhaps, well, of course, I'm quite sure that we accept only packages that are okay from the viewpoint of what should be included. But it's not my, it's not our call and send to make. But of course, the goal is of course that the Volatile packages are included in the stable release in the same way that the security updates are included. But there is still a long way to do that. And of course, yeah, there are different opinions how it should work. And you usually convince people to show that your way works better than the other way. And that's what I thought that will not, does try to do. Okay, some more questions, otherwise please hand the microphone back to you. Yeah, one more thing. There are plans to make such CDs with packages merged from Volatile. Do you think that would affect the perception of the stable release? I don't think that this one would have any effect on the stable release. When it would be really interesting, but I would say probably we won't do it. Would be if we would add a new occurrence series and make a new installer with it. But what I understand from Troy Hayes, he would prefer to not do it for very obvious reasons because it's not too easy to do it. But yes, I really think it's a good thing in Debian that we can just try or work on implementing something, show that it works. If it works, we can just merge it back into use in the proper Debian. And that's what Volatile is about. That's also a lot of other stuff that happens in Debian is about. That somebody starts to work on something, shows that it works. And we merge it back into Debian. What I like about the concept of Volatile is that it offers users a choice if they want to stay with the basic stable release or go an extra step further. I think basic Volatile could be included maybe in point releases, but on the other hand, what's the point? Because the nature of the basic Volatile system is that it's going to change very soon afterwards anyway again. So as soon as you release basically a point release, it's going to be out of date again. So you don't gain that much if you include the package in Volatile on a point release. It's different for the sloppy archive, but I really think that users should have the choice to have it included or not. And that would go against including it on point releases. Well, for the sloppy archive, I definitely agree with you. Well, for us, it depends. For example, so who is updated with it to Woody? We just need to update who is once. The newer who is updated were not as important as the one with the .org and .de registries. So for example, that one, my opinion really would have made a good match to get into the last point release. So I think sometimes it really helps. Of course, this climb up, I expect too many updates. So probably for that, you are partly right because even if you update it, well, if you update it in the point release, then you'll have a very more recent or have very much more spam patterns that they can use or virus patterns that they can use than if it wouldn't be updated. So in a word on how Glamov works for perhaps, Glamov has a data pattern and program code for the data patterns. And from time to time, they update or they add a new variant how the data patterns look like. And if you have all the program code, the newer data patterns are just ignored and Glamov gives out a warning to say, I'm too old, use something newer. So yeah, so even if you wouldn't have the very recent ones, but just more recent ones, it would be better since I have the very old ones. So I think even that would make sense. But yes, well, and it's definitely not very high on my priority list to get this thing done. And I personally expect that there will be no change for such with the stable release policy, independent how well or not volatile works. And if volatile works well during such, I think that's a topic that we will discuss for edge. So we have enough time to really reconcile if it's a good or a bad idea. Okay, next question please? Okay, so in that case, I think we're done for now with the talk. Thank you for coming. And I can see the later in the weeks of talks are, it's harder to get here. So thank you very much for getting up so early. I know how hard it is, so thank you very much.