 Thanks for coming to the policy buff. I'm Sean Whitten and I'm Ross Aldery. Perhaps one of those needs more introduction than the other. We are 50 percent of the policy team. I realized about 10 minutes ago, the policy team is for people. So we actually have enough people to second our own proposals. It's a good job that is never the case that the entire team is active because that could cause problems. We thought it might be useful to start by giving an overview of the process that policy has. Yeah. So you get a show of hands like, how many people here already know how changes to Debian policy are made? Okay. Actually not all that many people. Okay. So let me give a rundown of the way that we go about doing this. This has been around for a long time. Manoj and I were the ones who hammered it out way back in the day. So the way this works is that somebody puts forward a proposal to change Debian policy or to add something that we currently don't have documented, and make sure that's open to the bug against the Debian policy package, which is also the thing you can install to get a copy of the current version of policy. Then there's some amount of discussion around, is this a problem that we need to solve? Is this the right way to solve it? So on and so forth. Then hopefully that process culminates in some proposed wording. Like here's an actual piece of text that would go into the document or text that should be removed from the document or whatever else. The point that that goes forward, we look for people to second that. So the general process is that anything that gets committed becomes part of policy should have three Debian developers who have agreed with it. So frequently that means two seconds because often the person proposing the language is a Debian developer. Usually I'll ask for another Debian developer if the person proposing the language is a contributor who is not a developer, which is probably more formality than we really need, but that's the process we've been using for a long time. The other thing that can happen, of course, is that somebody can object and then we don't have a process anymore. That's kind of the summary. Yeah, it happens quite a lot. It's actually one of the frustrations about working on policy. So we don't really have a disagreement resolution mechanism. We talk a lot is mostly the disagreement resolution mechanism. The hope is that we can find something that everyone will agree to. So it's government by consensus. I'm a big fan of consensus. I really like consensus. Often that will work. Often when it doesn't work and we can't reach consensus on any particular change to Debian policy, that often can indicate that we actually shouldn't be changing anything. They're like, we don't have an agreement on a project as to exactly how things should be working, and so it's perfectly okay to just leave it alone. But there are cases where I think we have some general agreement that this description in policy is wrong. What we have in policy right now is not what people are doing, but there's some disagreement over what we should say in policy, but there's no agreement on any particular thing to say in policy, and then we have a bug that's been open for 14 years. It's usually the way that ends up resulting. So that's the summary. It's designed to be very uncontroversial. There's a couple of other metal rules around this. One of them is that policy is not a stick to beat maintainers with, so that I think goes Manoj's phrasing originally, but the idea is that if you don't like how something is being done in Debian, please do not come and propose policy that says doing it the way you don't like is wrong. That's not how we want to function as a project. There should be some project consensus that what you're doing is wrong. If it needs to make a decision, you can't get consensus, then that's what the technical committee is for, or various other project governance things, but the intent is that for policy to be a technical repository of the decisions that we've made about how to make packages interoperate as part of an operating system, but not as a dispute resolution mechanism. That's one. The other one is that we try to make changes to policy that immediately make a bunch of packages buggy. So the idea is that if something's currently widely being done in Debian, even if everybody agrees it shouldn't be done in Debian, we generally encourage people to go fix it in Debian first, and then when we're down to like the long tail of un-maintained packages make changes in Debian policy. Let's get some mics over here for folks to use for questions and stuff. Even for the things that are on the level of shoot? Yeah. Even for things that are on the level of should, I say that we're a little bit more willing to incorporate new shoulds, even if we know that there's a bunch of packages that don't follow them. As long as there's a pretty strong consensus that we really don't want those packages to do those things. This used to be a lot harder back when I first originally started working on policy. These days, for most things that we want to add the policy, the first step is a Lintian check. If there's a Lintian check, we can get concrete numbers, which is fantastic and we can get a lot of movement already in the archive. As soon as Lintian starts complaining about something, a lot of people just fix it. That tends to flush out these things that otherwise sit around forever. I think the original header of Lintian was something like love the policy of beta policy. That's key. Turning it around, that's funny for the tool. Is there something lower than the shoot in the policy? A recommendation or do we have that somewhere, I guess? There are things in policy that are like, this is a good idea or consider doing this. There isn't a word. One of the things that has been a long-standing minor irritation about policy is that it stole RFC 29.11 language or 29.19 language but not really. If you're used to IETF standards process, everything looks familiar up until the point where we don't treat it the same way and it isn't familiar, and it's just weird. Although, to be fair, IETF has the same problem that they don't have a word for. This is a best practice but isn't actually a standards problem. The lowest they have is should, and various people have attempted to introduce other words without a whole lot of success and have run into odd corners of English pretending to find a word that will fit somewhere below should. There was some big argument over odd, and then everyone decided that odd was stronger than should, and so that didn't work. One thing I wanted to add to your description is that seconding a proposal is not just to say that you agree with it, but that you think there's consensus on it. That's why I'm mentioning. Yeah. You didn't see much. Right. In a project with 1,000 people. Yeah. The three people is not very much to make a change to Debian, but there aren't very many active people who follow policy closely. But generally, the people who do have a pretty good feel for what is a problem and what isn't a problem. One of the things that I find really rewarding about working on policy is that you get a really interesting understanding of what's going on across the entire distribution and also what goes into making a set of packages that can work together, and so it's quite the education sometimes. I think you said that making a change, but I also heard you say it shouldn't be making a change, it should just be documenting whatever happened before. Yeah. To some extent, that's, well, so there's a couple of things. One is that I think there is an understanding that from time to time Debian needs to make changes, and wants to introduce major new features or wants to change the way that we have historically done things, or something about the underlying ecosystem has changed in a way that requires us to document new ways to do things. Like one very obvious example would be introduction of system D in the archive. There's a whole nother way of managing what used to just be fairly straight. Well, used to be a NIT scripts that everyone understood, but which were not at all fairly straightforward. There's a giant chapter in policy about writing a NIT scripts. Sorry. I apologize. I speak extremely fast when I start talking a lot, so I'll try to slow it down. So there's a good example of a place where we actually want to change something is that if you introduce system D, now there's system D units. We need some documentation about how you deal with system D units, how you do transition from a NIT scripts into system D or transition back, how a NIT system helpers works with all of this. So that's a good example on the other front as well, because as you might know, none of that is in policy. So- Some of it is now. Some of it is now. As of yesterday. Great. So we have been playing catch up for a long time, and there's a ton of things that have happened in Demian that are not yet documented in policy. So even if we just focused on documenting the things that people have already done, we would have quite a bit of work to do. I think that we all would aspire to being in a spot where policy would be a little bit closer to the beginning of that process. My two favorite bugaboos on that front are multi-arch, which we have had in Demian for forever, it feels like at this point, and still is only slightly represented in policy, and triggers which completely change how maintainer scripts work and are completely not mentioned in policy, except that there's like a side document text file that says, here's how triggers work, which is more of an implementation detail than a spec. So that's where we've been at just in terms of resourcing. One of my goals for this BOF is hopefully to as well as educate people about how policy works, to maybe get some more people who would be interested in contributing and trying to close that gap. I guess I'll make my pitch for why I think policy is important. One of the big reasons why I started working on Demian originally because I had started with Slackware and then went to Red Hat, which was often common thing to do at the time, and then I had a version of Red Hat installed, and then they released the next version of Red Hat, and then I wanted to upgrade to the next version of Red Hat, and then that was not a thing that you did. So a friend of mine, and this was like in the late 1990s, and a friend of mine pointed out that that was the reason why he used Debian because you could upgrade from one version to the next, and that was why I switched to Debian and got involved in the project in the first place, and policy is a big chunk of what makes that happen. I think policy is an underappreciated reason why Debian is what it is, and I think that other distributions have started picking up that idea that you really do need to write this stuff down, but we have a fairly comprehensive understanding of what a Debian package is and how it works with other Debian packages, and back in the day, if you read through some of the details of, say, Chapter 11 in policy, which is the one that goes into the specific details of, here's how Usenet News programs work, here's how X programs work, here's how you handle terminal emulators, here is exactly how the backspace key should function in a Debian system. That stuff is actually really cool, and I think that we, it's hard to keep that level of detail and thoughtfulness around a growing project with tons and tons of packages, but I think it's a great ideal to aspire to that you can run an arbitrary program in Zydebian and hit the backspace key and it will delete a character that way and not do some other random thing, and I started using Unix back in the day when that was not a guarantee that you could rely on, so. Can you explain a little bit why you think that policy has a big chunk of that, because I, because you write down that that is something that you want, I mean, another distribution could as well be upgradable. Yeah, I think it's because, so there's. Wasn't a stick, right? Yeah, I mean, there's kind of two ways that you achieve those sorts of goals. One is to test everything very thoroughly and the other one is to write down what you expect people to do and you kind of have to do both of those, and I think that the testing is probably deserves the lion's share of the credit because that's what it uncovers the actual bugs, but if you don't have it written down how you're supposed to do something and you've got a project of thousands of people who are all contributing little pieces here and there, then the testing is going to uncover the fact that no one had any idea how to make their packages upgradable and then it will just not work, like the number of bugs you're going to get out of the testing process will be just like, oh, okay, well, we're not gonna do that then. So there's one of the things that really, because I've worked on Lentian as well, a whole bunch and would love to get back to doing that again when my day job stops eating all of my free time, the one of the things I'm working on both Lentian and on Debian Policy showed me is the vast power of just writing something down somewhere. It's amazing how much folks in Debian who are contributing to Debian packages really want to do the right thing. They really want to write great packages. They want to follow a coding style. They want to follow a packaging style. They want to make a package that works the way everyone expects the package to work and if you just tell them that somewhere and ideally test it as well, Lentian is like probably 75% of that and the writing it down is like 25% of that. They'll actually just go do it 90% of the time and the remaining 10% are mostly mis-understandings. And so if you write it down, then most of the work gets magically done and then you can chase the variations and get all the way to the quality bar you want to make but the writing it down is just amazingly powerful. Speaking of packaging styles, where do you stand on the idea of documenting DevHelper usage in Debian Policy? I mean, so far we've described packaging as the result and what a source package is but not DevHelper, which is what everyone does. Yeah. It is referred to. There's several places where it says the easiest way to achieve this is to use this DH tool. Yeah. So there's an interesting set of things that policies are trying to achieve there. And some of it, so there's a set of things that are happening there and some of them are just an era in which most of policy was written and some of them are conscious decisions and I actually am too close to it to be able to tease those apart so I can just kind of give you all the reasons and I'm not sure which one counts for more. So when policy was first written and even when I first started working on it, which was quite some time later, the Debian Helper I think was just getting started. There were a pile of other helper programs like Debian Helper that were around. It was not at all clear which of those people would mostly use and then CDBS came along later than that and also it kind of uses Debian Helper under the hood but it's not like the user facing interface for it. So policy was kind of neutral. Policy was what let Joey write Debian Helper in the first place and to some extent in the sense that policy was a specification for Debian Helper. Like here's all the things that you're supposed to do in a package and you can write a program that does those things and there's some value in not losing that. Like if we don't document what Debian Helper is doing under the hood, it makes it very hard to write another Debian Helper and I kind of don't want to lock that out. Like I think I can't imagine a world in which I would not use Debian Helper for a new package but at the same time like there's always it's, knowing what the bits are actually supposed to look like at the end of the day is still kind of important. So there's that angle of it that kind of the underlying spec thing. The other one is just the era in which it was written that Debian Helper was not the commonly agreed upon everybody was using this that it is now. So a lot of it is just legacy from before Debian Helper existed. So there is some appeal to having like a here's policy for people using Debian Helper and then here's the more detailed spec that's of what's under the hood and it's actually doing. But a lot of that just comes down to it's a lot of work to try to rejigger the document in that sort of fashion. I mean, patches that just add references to Debian Helper without using should or must, completely uncontroversial. We can add more of those. I, in my, it was sort of a very odd attempt to try to provoke Manoj to come back and start working on policy again, sort of. I didn't think it was gonna work, but you know, worth a shot. I actually converted Debian policy over to using Debian Helper for the 400 release. Until prior to that, it was something that Manoj started way back when it didn't use any packaging helper whatsoever. And it did the actual underlying package construction directly with deep package tools inside Debian rules. And I maintained that for years and years and years because I thought there's some appeal to that. Like your policy package should just use policy. And then I decided I was being silly and no one else could maintain it. And you know, it would be a lot easier for people to contribute if it just looked like any other Debian package. So it does now. But Manoj, I was kind of half expecting Manoj to show up and say, like, what, what, what? He didn't look at the source. Yeah, possibly not. I think he's busy. I think he's gotten drifted off to doing other things. Deb, as a dependency, Deb Helper's kind of a blip. Do you know that policy depends on tech live lying Greek to build? I mean, nothing against Greek as a language, but I think it's not really. Anyway, just a little poke. Yeah, so well, I mean, we've never made any real attempt. The purpose of that was never to minimize the dependency tree for Debian policy. Like Debian policy, it doesn't really matter how many tools it takes to build it. All of those dependencies come from the fact that we have DocBook XML and we wanna produce PDF. So if the world stops caring about PDF and PostScript, then most of that stuff could go away. But it seems like all of the really good tools for generating decent PDF files from some kind of a markup language pass through tech because nobody wants to reproduce what tech is doing because what tech is doing is scary. I actually think that even if you use like Sphinx with restructured text, you may end up with tech under the hood there somewhere if you want a PDF file. Oh, we should say that someone is working on making policy into to build with Sphinx and be written in RST. So hopefully that'll go through. We want to. I mean, it'll be, sorry, it'll be much more appealing for people to write patches in RST than DocBook. So hopefully we can make that happen. Yeah, I used restructured text for the first time for a work project about like three weeks ago. And I was like, okay, why have I been using Markdown all these years and what was wrong with me and why didn't I switch to this a long time ago? And if anyone wants to help policy but is less interested in writing patches to the text, then you should let us know if you want to help with that conversion. So the other thing is we have about 15 to 20 bugs that we think we can close pretty quickly this week. So if anyone is interested in doing any policy work this week, in person, let us know and we can try and get through those. It's everything we had on our list. So you mentioned LinkedIn and how when like you add something to LinkedIn, then it's easier to then get policy to include this thing. But like the process for other things to LinkedIn is more arbitrary, I guess. Like sometimes you get an Indian error and you think like why is this an error? Like it maybe should be a warning or it should be like an informative thing. And it's like, I don't know, it's unclear to me how the level of warning of a LinkedIn thing is applied and like someone managed to put an error there. And so now you can say, okay, now there was a LinkedIn error, now let's put it in policy. See what I'm saying? It's like a loophole of introducing something in policy through first introducing it in LinkedIn without the three developer succumbing thing. Yeah, well, I mean, even if it was in LinkedIn, we would still want to have seconds before it went into policy. The severity levels in LinkedIn are actually kind of an interesting topic. They're a little bit more complicated than they look like under the hood. LinkedIn actually tracks internally, tracks two different variables and collapses it into a severity for you. So it tracks an internal severity, which is about how serious of a problem does LinkedIn in the viewpoint of whoever wrote the check think that this thing that it's trying to detect actually is and it tracks a second variable, which is how, yeah, certainty, which is how likely does LinkedIn think that it's actually correct about the thing that it's checking. And so the errors, warnings, info, frequently the reason why something shows up as a higher one than it should is because the problem is actually real, but the check is wrong and the certainty level should drop. I think that the general goal for the LinkedIn stuff is that it should reflect bug priorities. So errors should be at least important and normal, LinkedIn checks should be like normal bugs and so on. One of the huge advantages of LinkedIn though is not even so much the doing it on individual packages and getting people to change things based on individual packages, as it is that once the check it's introduced into LinkedIn then the lintian.debian.org will run it on the entire archive. So one of the things that we would look at to incorporate something that LinkedIn found into policy is how many packages actually fail this check. So even if it's an error in LinkedIn, if there's like 5,000 packages in the archive that are firing this error, it's not ready for policy. Or even if it's a few, but the check is narrow and it's most of the packages in the area that the check is trying to check. It's one of the big ways in which we figure out is the policy change is gonna declare a bunch of packages buggy. You check LinkedIn first and see, okay, so LinkedIn says there's only this tail of packages that haven't been uploaded in a while. Probably okay at this point to just go ahead and incorporate it. As long as it meets the other bar of policy beyond that. And of course it goes both ways. Sometimes we incorporate stuff into policy just based on policy conversation and then it gets added to LinkedIn at some kind of a check afterwards. When I was active on both projects, I would try to write, each time I release a new version of policy, I would try to write LinkedIn checks for everything new in that version of policy that LinkedIn wasn't already checking. That one of those things that you can do when you have more free time than I have now, but it's still a good exercise to always run through the upgrading checklist and go, okay, can I write a LinkedIn check for this? If so, let's get that in there. LinkedIn is to me just one of the best things about Devin development, like having a really good linter, super important. And it has, to also partly answer your point, it has the override structure. So policy kind of, like if we have to write in exceptions, we have to actually write English text in the exceptions. The nice thing about LinkedIn is that if this rule doesn't apply to your package for some reason, you can just add an override file that explains exactly why this rule doesn't apply to your package. And now the comment in the override file is lifted up as actual text on the lintian.devin.org page when you look at the tags. So you not only can read through and see which packages fail, you can also see, oh, here's the reasons that people gave for why these packages fail and which is super valuable information for tuning the LinkedIn check, but also for like policy conversations. Yeah, on proposal full wise, I submitted a bug a long time ago to LinkedIn. We had a discussion. I think a lot of people are using the LinkedIn overwrites to say, yes, I looked at this warning, or mostly it's for the lower ones. I've checked in my package, it will remain there, but if I have 10 or 20 LinkedIn messages in every time that I upload, I go through them, that's a lot of my time. So I document that, yes, I looked at it and it will not for whatever reason be fixed in my package. It's not, so the bug that I filed against LinkedIn was basically, you actually want to have two things, saying, yes, this check is not valid for my package and yes, I looked at it and it's not gonna be fixed so that I don't have to look at it. Is this? Yeah. How do you see the use of this override? Well, how do you describe this? Is it really, the check is wrong? But I think that's not how a lot of people are using the overwrites. Yeah, that's probably true. I mean, if the check is just flat out incorrect and it's made an error on your package, I mean, at least when I was active in LinkedIn maintenance, I think this is what the current LinkedIn maintainers were still doing. The recommendation is just file a bug in LinkedIn and say, like, this check is just wrong, please just fix it. And in those cases, I would advise people to not add the override, just let LinkedIn fix the bug and have the thing go away. So all of those bugs open for a couple of years. But if they've been open for a couple of years, then people will obviously switch over to override for the reason that you said, because they get tired of seeing the thing all the time. I think that, I mean, I don't have a great answer for you. I would say that's what the comments are for though. Like, having a comment for the override is super useful. There was some talk a while back about having there be a LinkedIn tag for having a LinkedIn override without comments. I was just a little meta, but... One of the things that I have, for instance, in a lot of my packages, don't have upstream GPG signature. That's a low level thing, but I check all the links in the mornings, and every time I have to go through the list. It's not just me an error. No, it's not. Oh, there's a bug in the current... Raise to error now. There's a bug in the current version of LinkedIn that added to check for the brand new supported way of attaching the upstream signature to the source package, and it was erroneously set to error, which was not the intent. I think they're fixing it. That's not what I meant. I meant the low level... Oh, whatever. Yeah, so... I still want to check, because you've got a bit of a check. Yeah, another one that shows up that's been even older than that one is, like, you didn't install the upstream change log file. Well, there wasn't an upstream change log file for me to install. I'm not going to go ask upstream to write a change log file, like... Oh, create one. So, yeah. Some of those are pedantic. I don't want to see that one. Yeah. If you're pedantic, then... Yeah, I mean, well, I mean, I'm with you. I enable all pedantic warnings on all of my packages. I guess I just mostly ignore them. I feel like adding overrides for pedantic tags is probably fine. I mean, the whole point of pedantic tags was that, like, this is probably not stuff that's ever going to be a requirement. It's just a best practices hint, and you should feel free to ignore it completely, which is why we're not even going to show it to you by default. I agree, though, that it would be nice to have a list of, like, here's the low level stuff that really, I just, for whatever reason, structurally, this package is never going to care about these things. Like, the upstream just doesn't have a change log and ceased development in 2012, and it's not going to have one now, you know? Upstream change logs are dumb in the age of version control, that would be my position. Also that there's an ongoing discussion right now on the G-Lib C maintenance list about whether they're going to continue to keep the GNU change log in the source package, and one of the problems with continuing to keep it there is that the change log for G-Lib C is so large that it is a substantial portion of the repository when you are syncing it around is just the change log file, which is completely 100% duplicated in the get commit history. But because of the way that Git works, whenever they rotate the change log file, it creates a new blob that has to get R-synced around everywhere when you R-sync the repository around. I actually, like, I agree, I don't, I think there's an open policy bug about the difference between a change log and a news file that has been around for forever. I personally have the opinion that the only thing that's actually useful to put in user shared doc is the news file, and that the change log file is not sufficiently useful to be distributing in user shared doc. If it's the old style GNU change log that literally lists every single change to the source package. But yeah, we should sort that out at some point. So just from personal experience, I disagree completely with that. Okay. Because the first place where I look when I have an issue with the new option release is the change log file. I don't want to visit some website, and maybe I'm offline at the moment. So it's really, really helpful to having. Right, so the distinction I'm drawing is between the news file, which should actually list the things you would run into. I'm talking about the individual atomic changes. Okay. It's really helpful. Okay. So if the upstream version, actual version control repository were readily available to you through like Dev Checkout or something, would that be a reasonable substitute where you can actually like do get log and history and like see the whole thing? Well, sometimes I work on a train or I'm otherwise offline. And then I have the lack of information immediately. Okay. So and with my upstream head of for different projects, what I do when generating table is always generate a log file, a change log file from the history and put it in the table. Because if people then find my table and use that for dollar something else and then they see an issue, they also want to compare what are the actual changes that happened between table one and table two. So there is, I think, a life on the planet that does not always look at the VCS. So it's about documentation. Also, when it comes to finding old software where the VCS repositories have gone for like 10 years, I'm so glad that they have actually changed log in the files. So doesn't mean that we have to ship it in Dev and Devian. Yeah, no, it's actually one of the things I like about policy work is that I'll have an opinion, but then other people will have disagree with me and have interesting reasons. And it's like I learn a lot. The main problem that we run into mostly is that these files tend to get really large. So I used to ship the full change log for MIT Kerberos because Upstream did the same thing. They essentially ran Git log and dumped it into a file. It's part of the release. It was subversion or something at the time. And it was 90% of the size of the entire Kerb 5.0 package was just that file. And it was, because it was like 20 megabytes or something. So I guess the question I would have is like would you truncate it at some point? Like would you only keep the more recent releases for the purpose you're talking about? So what comes to my mind is now we nowadays split up source packages into several binary packages and we actually doubly keep the change log, right? Yeah, it's frequently, you can avoid doing that. But in order to do that, you have to sim link some stuff around and the sim linking is a little obscure. So oftentimes people just copy it because it's easier. Yeah, so one thing actually could be in addition to the policy that actually you have one main binary package, which is a common package, an arch all package and all other package have to zoom link so that you don't have the Kerberos log file that you were talking about or whatever like five times on the system because all the sub binary packages are installed in the system. So that would maybe reduce storage. Yeah. So truncating, yeah. But it's the history, it's the legacy. So it's a question if it needs to be in Debian but like the last two years are also often important for me when I look at stuff. Yeah, I mean all things are broken. I'll definitely make a pitch here for that. I think that a version control repository is actually a good place to at least additionally start that. And I get your point about the offline access but like I'll pitch D get as a way of being able to make sure that like there is an actual get repository that has the history of the package checked in that you can do reasonable get operations on and that you can clone if you need to get at it. And I saw from a long time back, I've started always basing the Debian package repository on the upstream actual get repository so that you have all the background history and can do that kind of stuff. Just two data points about the change logs thing. I think the same linking is an option to DH install change logs you can add to the rules file. And the other one is I think Ubuntu actually truncates the Debian change log just the last entry in their binary packages for some years now so. It's actually interesting it kind of goes to your point there where she's like I'm not convinced of the utility of the upstream change log but truncating the Debian change log actually really bugs me. So. So. If making the sim links is complicated, I mean you said you made it look like it was some kind of dark magic. Maybe it could be made simpler or better documented somewhere so that people would tend to do that. Like you said, just documenting things makes people follow it. So maybe if that point would be better documented, that would med use copies. This exists. There's DH link doc, just does that. Yeah, it's like a default. It's not people's favorite DH tool, because it seems to cause bugs. So I think that's what Russ was alluding to. But this does exist as a tool. Also, it's relatively new. And I had forgotten that it had gotten added. And you have to be careful about the version constraints, because it has to be an equal and not bigger than. Oh, because it's been an image. It's slightly tricky to get right. It's trading disk space for RC bugs, in my experience. The root problem, the reason why this is tricky, is actually kind of interesting. The problem is when you've got one source package that generates some binary packages and then some architecture independent packages, if you end up in a situation where you have a binary NMU, the version number of the binary packages ends up being different than the version number of the source packages. But if you want to simulink the entire user share doc directory, that includes the copyright file, which has to correspond to exactly the same version of the package that the copyright file is for. So you end up with this problem where it's hard to write the version constraint, because the package that doesn't contain the copyright file has to depend on the package that does so that when you install the package, you'll have the copyright file on your system. And it can be hard to write that version constraint in the dependency in the presence of BNNMUs when you've got binary packages and architecture independent packages. There's probably some way to solve this. I think Ubuntu had some way of solving this that just didn't put the separate copyright file on every file and then simulinked every other file in the directory, which is kind of the brute force away to fix that problem. It feels like there's some strategy here that we could make this better. So now you can upload source code. So at some point, uploading binaries will just be not done anymore. I definitely hope that that's the case, but it unfortunately doesn't get around the BNNMU problem, because what happens there is the package is rebuilt on only one architecture sometimes because that one architecture needed newer libraries or something, and then that one version will be different than the other versions. It turns out that versioning is actually one of the harder problems in Debian. And it's considerably harder than it appears like at first glance. I noticed that we are talking about change logs for the last 10 minutes. Is that really the hardest thing about the Debian policy right now? So I guess that's a good thing. One of the other things we were going to ask about actually was, so we'd love to have more people contribute to Debian policy. What can we do to make that easier? Because here's a bunch of interesting people who know a lot about Debian. RST will probably be a big stage of that. Yeah. But is there more? Weekly or monthly reports on the planet? I think the reproducible team has a lot of new contributors all the time these last years. And I think their weekly reports really help. So I think they're like a requirement for their sponsors. But they actually really, as a team, benefit from doing that because it gives a window to the outside. I mean, I'm not a developer. And just reading their reports, sometimes I want to help. So it helps having an idea of what people are doing. If you just made a list of the bugs you closed, or the lines of the policy you trained, or it doesn't require big writing, literally writing, just listing the bugs you solved in the last week or month. So it might just give people, well, at least get them interested in policy and know that it exists. Oh, so every time we release policy, we put the upgrading checklist on Debian Develop Announce. That should probably go to Planet as well. Maybe I'll just stop hosting it on my blog. So I'd like to say what Sonic said. And it's embarrassing now because I tend to forget checking Debian Develop Announce. But the divs, what you said, for what it is. Upgrading checklists. Yeah, the upgrade. So that checklist should really go to the planet because that's something that many people follow more. Yeah, half of this is posting that to Planet. And the other half is, I suppose, trying to release more often. I wouldn't want to release policy on a schedule so that we could post a planet on a schedule like reproducible builds do. But if we're releasing more often, maybe that wouldn't be an issue. Thanks for that. I think one thing that might make people contribute more is having a vivid policy process. And it was mostly dead a year ago, and now you're revived it. And I think most of the work to actually motivate people was just done in the last month. That we actually have a process that works, and we see updates. And it's super cool to actually see progress on the policy front. And I think, thank you very much for that. Sean was a big chunk of that. Well, with plenty of people backing me up. But what I mean by that is also that the fact that there are probably 100 bugs, rather than 250, they're all old, and that you first have to rebase is discouraging. Right. We are intending to mass close bugs that don't seem to be going anywhere. And that we personally don't think are important. But they can be reopened. So to exactly that end. So going also back to your point about more visibility of where things are at, I at one point had this grand plan that I was going to send out regular status emails, because the time I was thinking more in terms of email than in terms of plan at Debian. And particularly, here's the list of bugs that where we arrived at some conclusion that no one had written language, and where we had some language but they hadn't been seconded. And I even wrote a Perl script to generate those lists that's sitting in the Debian policy repository. And I think I ran it once and sent out one email, and then that was when that stopped. But we could probably do something along those lines. So all that policy process I talked about at the start, that all those steps in the policy process are represented by user tags in the BTS. So when you go to the default Debian policy BTS page, it has everything all kind of laid out by what phase it's in. So we do track that information, and we could just publish it, make it more available. Right. We're also planning to simplify the process slightly by collapsing three of the stages into one. So that'll probably help with that. The, in terms of like what the biggest thing is, like I personally, I think the biggest open issues with policy are not areas of disagreement, it's areas of where we just have things that clearly need to be documented that haven't been documented. Like if you go through the Debian policy bug list as we were doing earlier today, like it's just multi-arch, multi-arch, multi-arch. Triggers, triggers, triggers. Yeah, I think triggers is mostly in like one or two bugs. Multi-arch kind of spread itself over four or five or 10. System D. The init system stuff, like the entire how do you deal with the new init system stuff. We need to have some kind of a policy around when do you unmount how we handle system D timer units. Debian has a commitment to continuing to work with init systems that are not system D, which mean, and that's exactly the kind of problem that policy solves. So the policy is really important, I think, in particularly for the kinds of things where the maintainer may not ever use something that Debian as a whole is committed to supporting. If you don't, and so they're gonna test their stuff and the fact that the thing runs periodically is something they're gonna notice that that breaks. But the fact that it runs periodically if you're running system D, but not if you're running system V in it, they may never notice. So that's where it's important to write that down and make sure that we've got checks for that. So in that case, like if you wanna use a timer unit because there's some features of system D timer units and there are some really nice features of system D timer units, you can set sec comp filters and namespaces and do some really nice security features with them. You do have to also figure out how that's going to run under traditional cron when system D is not in the picture and that's something that the project can figure out how to do once, write some helper scripts around documented policy and then you just do this thing when you install a timer unit and then everything works correctly. So that's similar to all the work that went into init system helpers for being able to maintain a service file in an init script and have them shadow each other properly and when you disable the system D unit file it also details the init script so that when you reboot your system in the system in the CSV init it's still disabled. So that's the kind of tricky little irritating problem that policy is there for and that then we write helper scripts that implement the policy and then that stuff just works. Anything else that you all think of that we can be doing better that you think policy should be tackling? How does it currently interact with the developers reference? Developers, well, developers reference isn't normative. It's not normative, so it doesn't tell you what to do, it just. It just describes an opinion. Yeah, I mean developers reference is more opinionated I guess. You can't really file a bug for not following the developers reference. The other thing is that the policy is about the contents of what we produce and developers reference is more about how we do it. We share a mailing list though, like so we see a jitter's bug traffic and that was to aid in like moving stuff back and forth. Policy gets quite a bit more traffic than developers reference does in terms of bug traffic right now. I think there was a question in the back. One thing that may help related to policy is scripting the checklist. So we could run a script on a source package and tell if it's compliant to the policy according to the new checklist. It's kind of what Lynchian does. Yeah, yeah, but it's not clear when the Lynchian check is missing and what has to be checked manually. And if they were remarking that, okay, it's covered by Lynchian, that would be helpful. So you don't have to check everything manually. So annotating the list, that's a really good idea. Yeah, it would be also easy I think. Yeah, that actually is a really good idea. We could easily do that even just manually but I suspect that it would be possible for Lynchian to carry metadata in the check that says, hey, I cover this area of the policy and then we could even automate that part of it. Yeah. Is it actually so that there is something in the checklist that is not checked by Lynchian? And then around, maybe two? There are a fair number of things in the checklist that aren't checked by Lynchian. Usually there are things that are really, I mean policy has a lot of like very specific technical things of like if you want a cron job to run daily, then you install it and that's a cron dot daily. And that kind of stuff you can check. There are a fair number of things in policy. I don't have a good example that's coming immediately to mind, but they're considerably more subtle. Oh, a good example would be that we added a requirement that if a shell was a candidate for being slash bin slash sh on a Demian system, it had to support shell functions. But a particular limited subset of shell functions that are specified in POSIX. Like, I don't know how you would write a Lynchian check for that. I mean, I guess you could kind of write a test suite for that implementation of functions and then if you are bin sh then try to run it. But there's stuff like that that's kind of a little difficult to make sure it's checked in Lynchian. There's also some kind of general advice stuff. Like a change from a while back clarified exactly whose name and email address you should put in the end of the changelog entry when you upload a package. It's not really possible to check that in Lynchian. So for the checklist, it would be cool to say, okay, we have like 10 items on the checklist and item one, two and three are covered and some are not covered so that you actually know what to check manually and what you just can lay back and get some of the latest Lynchian version from Backport and that's fine. Instead of the Lynchian check name. Right, it might be worth just separating the list. Like in square brackets, the Lynchian check name matches that. Then it would be obvious the ones that don't have it. Yeah. Yeah. And also if you need to build the package to check the thing you are interested in. I mean, if policy imposes restrictions on binaries, you can't tell it from source. So you have to check the changes files. Oh, you're saying you'd like the checklist to be annotated as to whether or not the package has to be built to determine? Maybe, but if you have the Lynchian tag, it's enough because it's clear that Lynchian won't emit that tag from the source. Right. And stuff which can be checked on a single source file could be added to all the package test of the policy package. So you can check the whole system installed in OVM if you are really interested in. Sorry, I don't think I understand what you have in mind. There are the package tests. So you can say, okay, if dash is the default shell, it must support functions. And you can write a test to check that. I guess it could be in policy package. So package test for an installed Debian system. But it's far reaching, I think. Yeah, that's, Manoj wanted to do something along those lines. Like there was a, we talked about this like one of the Debian dev console quite some time ago that one of the things that would be really nice would be, in some respects, would be to have a much more machine consumable way of doing policy that would look more like the way that they did the POSIX standard where you have for every given requirement you have a normative section, you have an informative explanation and you have like a test suite that you could potentially attach to that. I love the document that would result from that would be very cool. The amount of work required to get there seems always seemed very hard and you lose a bunch of narrative flow when you try to figure out how to write policy that way. And I don't know how important the flow of, I don't know how many people actually just read policy anyway. But there are parts of it that are intended for that. Particularly like the first three or four chapters are sort of here's how the archive is laid out, here's like some basic concepts you have to understand around the free and non-free and sections and priorities and whatnot. But I still like, I keep having that in the back of my mind and think that serious standards bodies that actually have, you know, have put a lot more effort into this that have national bodies that have funding for people to come and work on this that write compliance suites and that kind of thing, they tend to structure their standards in that fashion where there's very clear distinction between here's the normative requirement, here's the informative discussion of why that requirement is there and there's markup that clearly indicates that and there's some presentation that lays things out that way. It would be really cool if we could get there. I think it's a lot of work on shuffling stuff around. Where does the Devin policy currently stand with regards to LSB and DFHS? So we are, so on LSB we are not, I don't think Devin policy really says a whole lot there except in the init system section. I think we say that you're supposed to comply with, forget if we say you're supposed to comply with LSB in the init system section or not. Well, we removed a bunch of stuff in this release because of the fact that init script headers are generally, I'm not sure if we actually mandate that though. Yeah, but other than that, I don't think we talk about LSB. For FHS we're at 2.3, there's an open bug to move to 3.0. One of the things that I'm a little bit, we actually just had this conversation today was the question of like, is this a priority for the project? We don't have a good feel for how important 3.0 is to people. The reason why the bug was raised is because FHS 3.0 allows userLibExec and there was apparently some desire to use userLibExec in the archive. We could handle that with just making an exception to FHS 2.3 that says you can use the userLibExec. That would be the super easy way to fix that problem. The more comprehensive would be to switch to 3.0. I don't know exactly how much work that is. I haven't really looked at the defs. The FHS seems to be totally dead upstream. Like 3.0 went out the door and then everything seems to have died. So I don't know how much future there is. And we already have quite a lot of exceptions on top of FHS, right? Yeah, we're carrying a lot of exceptions on FHS 2.3. FHS 2.3 hard-coded the red hat by-arch approach. So we're never going to do that. And the ongoing discussions on the FHS mailing list, there's still people advocating for that being the most sensible way to do multi-arch. And I don't understand what they're thinking. So there's a bunch of that. And then some of the rest of it was just that I think that they mandated some really, really restrictive compatibility with shells. And we were like, no, like, I mean, all the shells support this some amount of POSIX features. Let's not tell people not to use shell functions and some other stuff like that. We also have a, I think two or three of the exceptions that are specific to the herd because they want to put things in different directories and have their own structure. How are we doing on time? Well, we're basically out of time. Yeah, but over time, thanks again for coming. Yes, thank you very much.