 So hi, I'm Phil. This is Adam. He tends to be a bit shy, so You noticed That malkin already did the other talk. I'm doing this talk, but he will help with the questions, of course So I want to show what we are actually doing if anybody has an Interest in actually helping us He can find some pointers. He can like get to know what would help us to get our job done So that's a rough outline about I will talk shortly about how the team is structured Then about how we communicate internally Not really how people communicate with us What we are doing What kind of documentation exists if it if it exists? And what kind of tools we use and then I hope we have enough time so that people can actually ask questions about how things work Because if you know how the tools we use work, it makes it easier to communicate with us Makes it easier to get started if you want to do a bit more than you're currently doing with your involvement with the release team So About the roles commonly we say and our homepage says we're divided in both managers Who have the final say who have to feel responsible? We have the assistants who do the actual work And We have results Whom we can direct to tricky questions about where we don't know ourselves what to do So some of that is true Especially a tricky questions part So we're grateful that we still have the old release managers around to help us when we need it In reality though, it's mostly consensus driven. Whoever does it gets to make the decision. So normally we have some kind of common sense and People pick what they want to do and when they are sufficiently capable to do it They just do it alone and they don't have to ask every time should I do that? Can I do this? So the last point actually says There's one exception if you do destructive actions, you might want to ask first So there are some things that are not easily recovered from In this case, you better ask before you're doing that if you're unsure that it actually works, but that Works pretty well for us. So We feel as one team. It's not that we are always like looking up at our managers and asking them what to do But it's really sort of we try to find a common opinion on something and then we decide on it Unless nobody wants to actually decide and then somebody gets to pick So it's Like other things in Debian So the communication channels are mainly the mailing list in IOC. There's pretty much Communication between us on IOC So the mailing list is Debian Dash release at list Debian.org. Everybody can subscribe We are handing this a bit differently from the code of conduct in that we You have to tell me what you want me to do Okay, I see like this no Okay, so We are handing this a bit differently Though I think it's not noted in that we are actually Writing a mail to the person and they see the list which is a total no-no on the other lists But we do that in the assumption that we are on that list and the others are not so It's all archived if you want to see what we are doing you can take a look IOC is not archived except in people's locks, which is a bit sad because there's so much knowledge in it But it's for us an efficient medium of communication So Debian Dash release is basically also a public channel There's no such thing as a backroom channel where we discuss things those things have existed in the past We do though have an internal discussion list Team at release.debian.org which is sometimes used for the tricky questions about how to announce something How to argue with a maintainer or There are cases where the leader contacts us about something and doesn't want to do that in public because he isn't sure what we think about it so there are some threats going on there, but it isn't much and Yeah, I listed that because it's also in the topic of the IOC channel Sometimes there are Titan pads that lists like to do items. What's the left to do for we see there's one Right So if somebody does a capture on that video and puts that mailing address online that would be unhelpful For the team list that was the comment because it's not spam-filtered So if you want to get involved the most useful thing is probably if you're lurking around on the IOC channel There are some people who are not on the release team who speak there a lot Helpful comments a lot There's some unhelpful comments, of course, but if you need like A discussion about a thing that you want to get like into Weezy It might make sense to use IOC if it's much back-and-forth, but of course it's not archived and you can also look on the mailing list and If you want to be sucked in you're staying there. You're doing helpful comments And at some point we might just grab you and not trying not to let you escape so that you're actually doing work Which might of course be detrimental to other things you do in Debian, but okay That's really important release team work so what we're doing is coordination a lot like transition timing and I know that people are unhappy with that that they have to wait ages until they get the transition approved, but that's Also manpower dependent and dependent on how well those transitions are prepared of the others So you could of course make sure that they are not screwing it up We're doing binonym viewing Related to transitions we are temporary boxy verities so that the count is what we think it should be We're doing cleanups like removals from testing of course also partial removals of some architectures in Unstable sometimes if it's clear that this is the way to go We do some maintenance like on britney some other tools. I will show you later And there's one package in the archive even we have which is Debian archive key ring and We really do a real lot of upload reviews. So that's our main job. We do it for proposed updates We do it for testing now and sometimes we also do it pre upload when we are asked is this okay? to upload as for the documentation Yeah, it's not nothing, but it's not much We really like that to improve But of course if you have a limited time and you need to get work done writing documentation might be a bit on the bottom of the list There's some documentation linked from our team wiki page there's Information about how point releases are done on a special page Yeah, we hope that in the near future we will have more documentation on that so That's our team page which basically says how to contact us what we are doing and you see There are a few checklists. There's a bit about britney. There's a bit about the transition tracker I will talk about in a moment and For stable you have everything you ever wanted to know about stable release management in Debian But we're afraid to ask or how I learned to stop worrying and love the cue viewer Which actually if you care about the stable release process tells you what we are doing Right so tool-wise I think everybody knows britney Which is the testing migrations lucky enough we now have britney to running which is a rewrite of the original Python script which is actually more readable than the original version Now of course I messed that up so There's a repository for it britney to dot get and there's glue code in britney one dot get for historical Reasons Yeah, so That's just the wrong way round if you want to run britney you Basically check out britney to dot get and you look at britney one dot get on how it's really invoked That's just because we're we didn't move that yet. Then there's the incredible transition tracker called Ben by Medi doggy and stefa and glon do which is This thing I Don't know how many people actually look at those pages or know those pages So there are a few okay Actually, if you're doing a transition, we are creating a page for it. There's an overview page, which is lucky enough pretty Empty right now because we're in freestime actually What we need from you is which packages need to be rebuilt and Previously you submitted a like a whole list of manual collected packages and what this thing does is You actually have an expression that matches on the packages files and says okay This depends still on the old one and we wanted to depend on the new one And then you see which ones actually still need to be rebuilt and can schedule been an abuse accordingly This gets also pretty there you see almost completed transition It still requires people to actually look at it and schedule the bin and amuse, but it's very very helpful to see Where we are within the transition then we have a Few tiny tools That we are using right now like D Which displays you adaptive between testing in and whatever we want to migrate which is mostly the unstable package Or the packaging testing proposed updates So if you're sending us an unblocked request, it's nice if you include adaptive But we will always look at that output So even if there's already newer version in unstable will always look at the diff between testing What's really interesting now and the new version? There are sometimes some surprises Where people didn't actually realize that that package before wasn't in testing yet and that the diff is actually pretty huge so what that will Outputs is something like okay. They are already hints in place Somebody already took care of it like there's an unblocking for this package a CPI support And then it starts off with how much changed and then adaptive and then we go through it and say okay That's fine. Let it in It also helpfully generates the right hint for that There's the hint tool that does the Lifting for the hints like I do hint easy sauce package name and I get the version in the right syntax It does the cleanup of the hint files, etc Funny enough, there's also WB which people know from the Wanna build requests on the wanna build list. That's actually maintained by the release team for historical reasons And those tools can be found in the release tools get if somebody wants to look at them feel free to Feel free to submit patches If you find them useful for stable and old stable we have the cue viewer Again, I don't know how many people look at that. I think mainly the stable release team That's this page this page actually displays all the packages that will be present in the next Point release and Processed so what we have at the top is a reason or rationale for every package that will be included The architectures that are already built the architectures that are still missing because the security team to release the DSA and Didn't wait for the IE 64 build like my SQL because it fails to build so That we actually don't Introduce regressions architecture wise into stable. This also means that some things Currently not going to be fixed and stable without I mean on IE 64 because there's no support for that Yeah, it also does versioning checks like this package is actually has a higher version number than testing or has a higher version number than Unstable it does in solubility checking if it if the dependency still work of somebody build it on testing and push it into stable or stable security which doesn't happen Yeah, there's a lot of stuff that could actually be avoided if you had source only uploads, but okay That's this page which is It provides step diffs for review that I didn't show they would look pretty similar to D It's the same engine and we are looking at those again To see if that's suitable for stable and it also helps to generate the announcements So basically if you have any questions about what we are doing I just wanted to do some quick overview about where our code lives what we are doing and stuff Please ask them. I don't know How many people there are that are a bit interested in what we are doing or interesting doing that work By themselves for us Can you share an update about the idea of Transforming Brittany into into a set solver Solution producer What do you mean by update? Okay, so there was a project by Joachim Breitner To implement that and he has it running concurrently So he has his own instance running on another machine and pushes hints to the real Brittany So that if it finds a hint that the real Brittany doesn't find For transitions that this is actually applied however, the current Brittany to code has an auto hinder feature that Already figures out pretty much most of the hints So it's not currently that useful as it could have been if we didn't have the auto hinder if that makes sense Any further questions? I would like to ask about architecture qualifications You did announce or did start talking about these I think in April or May last year and then well It did nothing it happened for I think 14 or 15 months and I think That puts a lot of pressure or work on on well develop us not to know What is the target for the next release and I think that's very very unfortunate Yes, I agree we should have done it much sooner and we will do for Plus one and I'm very sorry if that caused any issues, but I Don't don't really have a excuse other than we let it slip and we shouldn't have done He did say that we don't really have a solid excuse except for us letting it slip because we Maybe didn't assign enough priority to it, but I think mainly it's an issue of actually taking the decision which takes somebody to take the decision and and Given the way we work It's hard just as a person come coming forward to say like this architecture won't be part and then the project not Accepting that or something. So it's also pretty tricky a politic voice. So Yeah, I know but I mean for her it was really tricky for us to justify That we will really not have it as a technology preview Given the effort they have put it and put in Particularly in the herd example There was a question of so so when do we announce that it's not going to be good enough or that it is good enough? and It's essentially the problem was we kept on thinking. Oh, well if we don't say anything Then maybe you'll get better and then it'll just get better and it'll be good enough But it kept on not doing that. So at some point you have to say right, okay this isn't going to happen and That's obviously a very Difficult male to write and it's something that you don't want to tell people So there is some optimism to say well, maybe it will be okay And yes, we should have done it sooner Trying to work out when is quite difficult and what criteria you can put in place to make that happen I mean in principle, we need to look at it pretty late in the cycle in the terms of Is there actually something really broken on it? I know it's bad from the toolchain point of view and To just shortly get back to her again There was also the thing that the FTP master said that hurt will be removed from the archive If they don't make the release and they did a tremendous effort to do more Months before we decided not to include it so and Then it's also the question what hardware we have for that part. I know that's also an issue and we have issues with built these Yeah, I don't know we will certainly lose architectures for We see plus one that's pretty sure Okay, do you have any ideas on which architectures are going to be at risk for we see plus one? Well, certainly as 390 That in any case Pretty sure also I a 64. That's the recurring theme of spark. That's true, but Maybe somebody steps up. I don't know that's the thing. I mean if you're a volunteer base, it's possible It's somebody picks up like an interest again, but yeah, it's tricky. It's also tricky that we have so Few potters actually who step up and say that they feel responsible for it And that there are a few persons that if something grave Arrives on any port step up and say, okay. I'm going to fix this So when we did drop HPPA and alpha John's last cycle That was a very bad experience. So it was announced as we are moving these architectures to ports but basically These two architectures were screwed up In the way they were moved to ports. So maybe it's better to To have the ports archive better supported and well, so That that potters are less scared about being moved to ports. I Mean we had that discussion with second-class citizen architectures, but I mean the ports archive guys are very few and They do a great job and that's an incubation thing for as 390 acts. It was great And alpha isn't actually I think from the last things I saw some months ago not looking bad Compared to the other architectures on ports. So It's really silly that we have to re-implement everything for ports It all is it also applies to want to build and build Well build the infrastructure also, I mean there are other things connected like DSA not wanting to have something That's not running on architecture that we really support and stuff I Think it's hard for a project to care about those architectures if they are not in the main distribution Even if they are very motivated there's H4 people are also very motivated and they take GCC takes a week to build on the fastest build they they have Yeah, so yeah, Doku argue argues that they at least work on toolchain issues, which is correct. Yeah Which might not be said of all architectures we have. Yeah Go on tell us the name of wheezy plus one. I think I Think the name is overrated, right? No, I don't feel like that, but I mean it was sad when It it will be announced when it's ready I'll see buggy sadly already taken by the FTP masters without consent of the release team. Yes So you're gonna have stole it for experimental. Yeah So don't argue that he should have stole Scott any further Questions discussions what we screwed up what we should do better. I mean we are open to critic I mean, it's not all solvable solvable with the manpower we have and The systems we have to a great job Adam. That's a really fantastic job as stable release manager as Testing release manager doing a lot of work our assistants do a lot of work So, okay, you're asking us but I'll ask you back. What do you think went really has gone really well? And what do you think has not gone well? I mentioned the the time-based freeze stuff earlier in my talk There's some stuff. We need to improve there. I Think project as a whole has to is will hopefully start to believe that say when we say we're going to be freezing Then then we actually are freezing then And I think if what's people start to actually think about that a bit more that may help There is an issue at the moment with Di packages and how they're being Handled because obviously there's people are busy. So So rule has to have sad step in a bit there and so that that's something that certainly if anyone has experience with Di and doing Di releases then that would be helpful. I think right show so with Di especially we had problems that There were no releases of any sort for ages and it was always a problem like that I mean always for as long as I was part. I'm pretty young but That's certainly an issue The other thing is that we would like to have to project fix bugs Which I don't see does it I don't say it doesn't work, but there are too few people working on that But that's not a release an issue the release team can really fix I mean unless we say like you fix a bark you get a Langlock free or something or freeze exception free or But I don't know if you want to go down that road Incentives bribery Any other question so let's oh Okay, so looking at Di a bit more I know it's long been a problem that Di releases and the rest of the releases haven't worked out and For a very long time Udebs would would never migrate automatically all that kind of thing Where exactly are we on that route? How far we are. Yeah, I Think yeah, I should probably be continuously integrated in the main archive That progress hasn't been made yet I'm not actually sure what's blocking more frequent uploads to unstable That we build the dailies from SVN and don't actually need to upload the changes Might not help in this regard because there are changes in the Di package that are lingering around for months or years Until they get uploaded to the archive. I don't think we're there. I think the Udebs thing in Britney's helpful Yeah, but That's really a question for the Di team to answer which isn't here, but I mean as a team I Mean on the room. I mean we discussed this over lunch one time I think you were present too, but there are several technical issues to solve with this I think I guess the problem biggest one is how to build and transition the Debian installer package Because we how it's currently Done as far as I know The daily builds take the Udebs either from unstable or testing depending on what phase of the release We are that used to be a switch you could make Probably it's nowadays from unstable Yeah, but it builds an installer that actually run it installs testing not unstable, which is same I think we will see if you upload it anyway, then but if you transition this installer and You have to have all the Udebs that are built into also to transition into testing at the same time or you Upload another installer to testing proposed updates and build this one with testing Udebs and just keep the installer from unstable out of Testing at all that's Some of the options. Yeah, it's a question what we want to do So Di is a pretty special package if you upload it to unstable It will fetch the Udebs from testing and included in itself in the unit RDS it builds etc No other package I know of in the archive actually does that so In theory if it would be possible to just do the normal thing like Your upload to unstable you have stuff from unstable and you migrate it that would be nice I don't know if that's possible, but that's really something. I mean there are proposals on the list on how to do it Yeah, it's not a releasing question But the di team can use manpower. They really can use manpower if you're I mean Working on the installer is not hard. They have their Checkout script. You have a really lot of packages, but working on it Is Documented and it's actually pretty easy if you have QEMU on your machine You can boot up an install and check if your changes worked Yeah Anything releases. Thank you