 Okay, so as everybody says, I should just start. I will do so first. Let me please introduce myself My name is Andy Bart. I'm one of the debut in the least matches and I'm giving today I talk about etch linear and more so of course we assume that there will be more after Lenny as well first of all Just a few introduction words about what we have we have different sweets and in Debian Basically, that's something everybody should know who managed to pass so nm, but experience shows it's better to want the other ones too often So packages I just need to move a bit of the things here Okay, no, sir. Yeah, so yeah packages are normally just uploaded into unstable Then say enter testing after some rough testing in unstable and one day Our other testing is then released a stable and For packages which are not meant to go to stable one day. We have experimental which is the proper place for them So and what does the lease management basically mean it means we need to ensure the testing really meets the lease targets We need to ensure the testing is not broken and does not get broken We need to keep all those things together that also means speaking with other teams maintainer people there's lots of people Yeah, and finally collect and distribute information So doesn't look as it would be too much, but actually it's still quite a lot of work And now if we look at the lease team Now for Lenny there will be two release managers that beside me that would be look less who's also at debcon Then we have two of the least assistance mark block Schmidt and adiato simo Oc and Martin sobel-helas Martin started as stable release manager. We just cooperate him into the Lenny release team last weekend because we have just seen that he he helped us already quite much So yeah, he was at it and then Steve said he doesn't want to be again on the hot seat for Lenny So we removed him from the hot seat called the lease manager and invented a new title called the least wizard Yeah, then what we definitely want to have we want to have more the least assistance So we are going to look for new people into the coming to the lease team again Anybody who is interested should just yeah Starts sending us a mail We will also send out a mail to deputy in the well announced soon and basically it will work like we did last time When we found mark and adiato We will just give a few tasks as in see who is able to survive us We have of course in roll account. So if you have any question Please feel free to always contact us at deputy in the lease at least they've been org Please don't write personal mails to me or to anybody else in one of the roles because it isn't usually as useful as said Unless of course you need to hide information because there are security bugs or something like that But mostly please use the roll account and we have a web page the least they've been orc We try to collect information there as well So now what are our tools For testing my for testing migration. We have a script called Brittany that takes packages from unstable if they are roughly, okay If they fit into testing without breaking anything if they don't have the least category bugs And then it's on since it's a testing we can change how that name works with usage of hints We have the least category bugs for us that is also a tool because it really helps us to say which package are okay on which not so Say our basically the least category bugs are our friends not our enemies Of course you want to have known none of them, but not because we want but not by Defining them away, but just by resolving them. That's the goal of it Then there's a security status and we have lots of small script and tools that we just use very intensive like duck LS Or grab the control or whatever ever else is there Yeah, and then how packages go into testing basically We prefer really to go them via unstable if possible at all because they will get some more testing there That was and that's even so when it says are deep for these because it's really second proper testing there. It's easier for us Britney's yeah Why does the testing will post updates works as well, but then only very minimal fixes because we can't test them as well As good as in unstable So Brittany runs every day or twice a day now shortly after the install Testing output and excuses are published output and excuses basically means what did Britney do you do? excuses are Checking does is this package okay for testing transition at all or does it have a seat box is it too young and Testing output is then which packages did it make finally in and of the packages which failed Why did say fail? Why didn't they make a testing and we can leave them Britney during the day or better to say We can ask me FTP must if you don't let me do it today We don't do that too often currently, but there are times where we do it quite often So what was basically the Yeah, so border of edge where they really started we more or less had a kick of meeting in Vancouver As you probably all still remember very well at least the discussions afterwards We originally planned it for December 2006. We Delated a bit to Easter Sunday That was of course in a delay. We didn't want to so yeah We would have liked to really meet our goal in December But on the other hand comparing it with Sarge. It wasn't too bad. I saw Sarge was also planned for December If I remember correct that was about the time I joined Debbie in December 2003 So I really think we did it way better So now in edge what worked well in in our opinion One thing that worked really very very well for us was all that test version tracking in the bug tracking system So there's really a great help for us to find out which package are actually buggy in testing not only an unstable And to see sometimes maintainers tend to drop NMU's just they just forget about or just to upload the package and So back in NMU and this version checking now version they can we'll just go and say oh, yeah unstable is no buggy again. So yeah That's really great thing Another thing that worked far fairly well is we said it's the beginning of the of the actually cycle We said we want to have only very few release block blockers and most things should be only and release goal Of course, there are always some blockers, but we try to Not allow too many stuff into that and that worked fairly well for us because We didn't we didn't had so many large issues up to the last moment open Another thing that of course connected to that is then we invented the so-called release goals during last step Confirm a set well if you have certain issues, we can approve them and then you can upload them Or you can file important bugs on them. You can NMU them and also work very well for example I didn't think we would have been able to get a lip as elinox in in as we did now With the same amount of support, but we're saying it's a release goal and I said who's interested can work on it This basically Mano stated can do it or not. Yeah, it arrived there without making any double for us as a release team So another thing that's really very very well is there's a build demons Of course, there's still a lot of room for improvement But when looking back at such and Steve reminded me on that in our Yeah, in our discussion how edge worked in such we asked people say please don't upload anything that you don't really need to have Intestine because our build demons are totally overloaded But we did so I think three times for such we never did that for edge. So it's really a great improvement Also relates to sets architecture status. We did a table say what does each architecture need to have for example? We need to have porters and that motivated people to work on the architecture again So it wasn't the release teams this time who had drives architectures But for such we we as the least team direct and build demon in Europe Toys someone please go to your car grabs that build demon and drive another place That's not the part of the release team And I'm really happy that it architecture status worked very well Of course, I still think I'm not so happy with but I think in the end it worked fairly well Also our release updates where deputy in the well announced at least I think they worked well I'm of course not bit beers position on them Then it's a time planning at large It's even so we didn't really manage to reach to December the larger time planning worked well We managed to get our seabags Mostly a very in time. So yes, I'm I'm quite satisfied as that as well Experimental was used very much a staging area for example the gnome transition for the XOR transition for the KDE transitions So we really had broken unstable only relatively short of course more bucks up I found an unstable but the first hard bucks are mostly fixed an experimental already So very well done. I can only say assist Most of these are little things we didn't do but where they've been at large trusted things were in a very great fashion So then of course the enemy you policy Worked fairly well We had a box quashing party marathon which also helped us to fix more a seabag than we actually expected We that use the time zone the time we have frozen unstable or also the base and we also reduce the amount of Packages we have frozen which help but also we adjusted in a few parts for example We started to freeze also the all the build tools that we have And the helpers like that helper and so on so that we don't get by an upload of a random package like CDBS another 90 RC bucks So yeah, I hope so what worked well was also managed with the release enlarge What went fairly well as a release notes except that we really started too late again We wanted to do it better But I'm really amazed of the especially of the translators how fast they were able to catch up with us I really need to say a large. Thank you to the translators It's really well, we've also these notes. I think up to something like 3 in the morning on on On Saturday before Easter and something like that now you have 12 hours of time to fix it and they managed it Really tough thing and said did it well Yeah, and what what was very helpful are is our ability now to use binary NM use Which basically means that one of our release team members is able to schedule them and they were just automatically built That helps a lot of in transitions where you just say well we need to build the package and all architectures and that's it Oh, yeah, we can just do it in unstable It's out asking anyone to do an source full upload So of course we also learn a lot of things from it So for example QA checks are really helpful We need some and we need more of them But if they start to late as a release cycle, they can be very very painful to us as well For example, we got a couple of bucks. We're just some files like Depping copyright. We're weren't existing at all Something that should never happen But if you detect something like said just a week before the freeze It's it isn't helping the timeline as well So we want to have more QA checks for Lenny, but we want to start some early in the cycle Yes, what we also learned is we need to use the least goals even better than we did for edge We need to check with the kernel team more often and the other teams also It couldn't wouldn't really disturb, but it was most teams that worked fairly well, but with the kernel team We really need to check more often Not necessarily the fault of the kernel team, but that is just that so that visa release team know what what the issues are what they are Needing from us perhaps where we could help or where we could yeah, how it could work better And we need to coordinate with the media archive people earlier that media archive people basically means the people who are operating CD CD images Debbie and org Because we just put them something like two weeks prior to for the Prior to the release in the loop and I said well you want to push out the lease at this date Are you available which was especially an Easter and very unfortunate date? It worked still very well, but perhaps it should be a bit earlier next time At least I hope to remember myself and when I'm at that position Time so Yeah, so for Lenny now the big picture you want to release in the second half of 2008 Which is fairly soon you want to send out more release updates I know that we said the same after after such so I really hope we do it this time We want to do even more quality assurance We might get new architectures sets an open question for me currently I hope to get some more feedback from the porters during depth comp. I already got some and I hope to get even more And yeah, it might be that we have to retire another architecture or not. We will have to see But that's about the big picture now looking into details a timeline We will start our first bucksquashing party marathon now in August from up from August to November so try to get the number of for the least category bucks down to an How should I say all of you able scale perhaps we have far too many We want to For these are the least blockers latest in September. Actually, I think we have some We all that they have all of the blockers that we have but the might be some discussions now We want to start the binding maintainers said they shouldn't That they should avoid making breaking changes to unstable in March Of course, there's some packages. We really don't care so much because they are leaf packages But for core packages, that's the time we need to be very careful. That's of course a tool chain Colonel X and what else I can see David here So then we will have from March on a second but a bucksquashing party marathon And also call a permanent bucksquashing party again up to the release Which is an hope will be in September and between that and September. We will have the usual We will start freezing the essential tool chain. It's a non-essential tool chain base You will have a debit installer release candidate and so on. Yes And then we will hopefully release in September, but September is only an internal date for us now We want to say we hope to release in the second half of 2008 and but of course we need to plan for a certain months to Somehow start planning when we will freeze what? Yes, and then the lease goes. What are they by the way? They help in a better overall quality of the lease But they are not blockers for the release so and Advantage is that people who want to promote something with the lease goals could basically handle them similar to our C bucks Of course, they are not a C bucks, but they can file them as with an important severity They can and am you it if they are not worked on so it's Very near, but we are not waiting on them That's all. Yes, and of course most of our tools should support them We started now to include support for them in our RC buck tracker so that you can say a C buck Plus the lease goal trackers. How somehow we need to find a better word for it And we will also make a canonical list of what are the least goals by the way So that anybody could look them up Any open issue that is not in a C buck by some other matrix is that least an important bug now and we want to have some Bucks that are from the lease goals We want to have some tech within go with goal minus whatever something like goal minus as a Linux or goal minus NFS 4.0 So that we can easily find them out with the user that be in the lease at least them in orc And if you have something what you would like to see as a lease goal, please send a mail to step in the lease saying Okay, how many issues are about there? Have and have you already identified all of them? We need to have one or two responsible persons who trust follow that up. So that we can also ask where are you now? We want to have a long-term strategy So the bugs don't they appear again, of course There are cases where we don't mind too much for long-term strategy like well It should work it should build with the next version of moves to see because a long-term strategy is that will be uploaded So that's okay And then you could of course propose a short name for taking the box. Otherwise we will invite one invent one And yes, then mail it to deputy on the lease and we will hopefully one day set it Send an answer back to say yes, that's okay. Oh, no, we have still this open issues questions or whatever So what are our current release goals is he not all of them are package related you want build the redundancy even more than we have now We want to have full youtube support in britney also not really package related but now we go to packages You want to have full IP version 6 support? We want to have a LFS support We want to have NFS for for support all of that is now inherited from the edge release goals we want to have a Double compilation means you can compile and source package twice and the second version is still working You don't need to laugh about that. We have a lot. We have a lot of packages which fail that Which is really a shame actually so yes, it definitely belongs on this list But it's not an AC buck because you can you can upload the package Build demons work. So but yes, I think it's a typical release goal We want to avoid having unmet recommends in my in main Unmet dependencies are of course RC unmet recommends are now a release goal We have the t-tech to tech live transition We want to get rid of that make The maintainer agreed to that we just have something like 17 packages to NMU And we want to use PO for a for the release notes Which will make translating the release notes way easier But we need also starts this early in the cycle because it's a bad thing to do that twice two weeks prior to the release So there's other things that we want to do for example. We want to URL Yada as well but actually We didn't really find Yes way how to describe it was to maintain up to now so we couldn't set it to in the conform to the least goal But that's my my pet project so to say So our release policy is technically spoken. We have most things the least policy are just okay They are so there are some things that are not so good For example, the third version of the Python policy sets outdated that has never been really in use And we say any violation against that isn't it isn't is an AC buck We have the We added in parenthesis to say actually sets somehow not so anymore, but we should work on that But mostly it's technically okay The style is just how should I say it's grown up at least it's the same as it used to be in charge and just Things has been added and removed and I suspect I haven't been around at that time, but it's probably still the same as potato So we might perhaps just See work it and Be a concisely to make one document that describes just the full release process including Yeah, what's our timeline? Where do we want to go to what do we want for have as architectures? For example last time we said well, it's in the least blogger that we get AMD 64 in but we never said we won't release This is without easy 86 So it just has a lot of things that we just assumed that are natural. We don't say so And that might be we might try to make that a bit better Yes, of course, we have even more plans for Lenny's and official confirmed release goals release blockers We want to have lesser dependencies between SSL bumps. Something that's actually currently been worked on We want to make less dependencies in transitions. That's something we want to have in Brittany That's already part of our Vancouver the size by the way So we want to have even more QA, of course better you depending Yeah, you want to take better care of our website and we want to use version checking for Brittany At least the version checking for Brittany is something we really need to start working on now because if you do something wrong It's not so bad now as it would be shortly before the release, but a Shortly before the release. It's really very useful to and to have Brittany understand what versions are So now however the developer could help because releasing Debian is something we all do together It's not something that just a four or five people in the least team do so the first is of course keep your own package It's a good shape if everybody would do that we could just release tomorrow So that would be very helpful Then help with squashing other a C bucks. It's so easy to just squash a C box. They're easy bucks They are a bit harder bucks a hard buck. So for every level there are bucks up there currently for example, there are a lot of bucks like there are C documents which are non-free in the source package That's an easy thing to do. Everybody should be able to do it. Just start doing it. That will help a lot Yes, and before you upload changes And you have suspects that you might break something please talk to people before So the least team is always available in IRC. We are often fast responding on mails Other teams are also good available and asking isn't so pain and I prefer to be asked 10 or 20 times When it's not necessary then to have one upload is that breaks of all of our large transition Yes, then of course something you should always do you should always see Debian develop announce But even if you don't do it, please read at least our mails before you upload something Well, then of course mention your libraries in a good way. Don't let simbless this up here Don't make as htl bumps. Oh, if they're not necessary, especially don't the names as own name But it's not necessary or even worse Don't the name it when it's necessary So the realistic things they could make our life hard and make the life of our users hard as well yeah, and then also some Minor things, please don't upload packages that are meant not meant for stable to unstable not just because you can't do it, of course, but Just it's a it's really a pain for us and a pain also for the other maintainers if packages appear Which are just meant to stay in unstable up to Lenny plus two And please don't upload a package if you break a transition So please take a look what's currently trying to get into testing first and they're currently a few larger transitions Ongoing so please be careful that you don't break something that should go to testing Basically if your own packages and sink in between testing and unstable and also not only the source package was also binary packages It's mostly safe In other case, please just take one look more why it's not going in if that's a transition if you go on the package tracking system There's something like it's trying to be included into Brittany if you follow them into test Testing if it follows the limb the link there you'll be set It's not going in because it's waiting on that in that other package If there's a large number of packages of conflicting with each other, it's probably a large transition. You're better. Don't disturb Yeah, so there are of course a few more ideas what we could do in the release and what we might want to try One thing that you want to do for edge already is you want to add another kernel version half way between edge and Lenny So that we can support newer hardware There's still a few things that need to be sorted out for that We know that but we are very optimistic to be able to and the great thing would then be that we can support Even more hard to without a new release of all of Debian But yes, that will be an interesting experiment to to the next idea that was very hard I didn't need to say that Would be that we said that we upload an additional set of KDE And so on The idea is to try that out by a back porch ox this time and see how it works So the problematic part is not to upload the packages It's even not to make security updates for the packages even though that's a bit hard That's really hard part is make sure that the transition from what comes in there to Lenny is really smooth That's the hard part in it. So It's very easy to underestimate the amount of effort we have to do for a smooth transition And also what we want to do is we want to get the points of these spots as a bit more streamlined So that it works better It already works a lot of better than it used to do but there is still room for improvement the other ideas I didn't put on the slide and That you really need to say I don't think they do any good all of these are things I I think it would help Debian The other things they have been ideas floating around Debian lists like oh what's about dropping testing Which I basically think it's a very bad idea because our current scenario Works fairly well. Of course, we have some issues. We know about We want to improve it, but it mostly works very well And I don't see any reason to slow good working things away because some minor bits are not working well So that's definitely from my opinion to stay basically the way we are and make improvements in detail And try to evolve the things and not to just improve something new and it's always easy to start to say I have a great idea I just divide down are easy the heart with the hard parts comes at the end and Trust me the release team and some of the core package maintainer know how tough the tough end is So now then let's release again One of the things we learned really is Debian can release We can even console our release cycles at least in the large amount of time We can go down from five years to two years Yes, but of course also releasing Debian is a common task that we all do together and so yes, let's just do it again Okay, so thank you for your attention so far and now questions Don't be shy So one of the things that was most noticeable when we had Sarge Was that it was a big difficulty if you're running a sarge system when you wanted something The odd package you'd have to compile it yourself or use back ports and often the version skew was really bad Are you considering adding now that we've got shorter release cycles and it's maybe more practical any requirements that? packages in testing or in unstable must be Buildable using some set of things from current stable maybe some restriction on what the build dependencies are actually Okay, I will repeat first the question the question is if you if you were in charge it was problematic if you wanted to use a package from unstable because you had to often not all tools that were available for the compiling was there and So you had issues to yeah locates up away tools and and whether you want to enforce now that you can Recompile everything with a package in the current stable Actually, I think that's not feasible to do it because there are often cases where I do a transition They have the chance to either break stable or break testing And then of course, I prefer if the package can compile be compiled in testing Of course, I agree. So sometimes cases the maintainers make unnecessary burdens. They say well the movements other burdens would be a good thing. So I definitely Appreciate any bug report to say well maintainer if you do this little change for your console script It would also build easily on the current stable separate be a good thing But I don't think that we can manage to say everything needs to build in stable But of course if you can get near to that I would appreciate it Okay, next question Yeah, you mentioned you wanted to eliminate recommends in Maine for the two packages that are not in Maine The one question I had about that is what about a package that require in order to operate requires you have a kernel package installed Not all of the external kernel modules can be auto built or are auto built I mean they all can be but it's a big hassle occasionally And I have a package for example that has a recommends for that reason to try to document the fact But you really need to have the kernel module installed or it won't work Can you please have at least the parts of the pizza last part of your question? I'm actually I'm not a native speaker as you might hear So when eliminating recommends that Recommends in Maine for packages that are not in Maine One of the places where that pattern is used is for kernel modules If you have a package that's in Maine that requires a kernel module an external kernel module be installed That the kernel module itself is not auto built for each different version of the Linux packages You end up with that pattern. I'm wondering if that how that affects the goal of removing those recommends Well, okay, first of all the advantage of goals is that even if you can't really 100% reach it It will still be helpful to make it for the rest So first of all, I don't think that is it affects the least goal negatively at all But what we should do now is get the kernel module is a bit better into shape if I look at the kernel package how it evolved during the last Let's say a three to four years. It's again a lot of in the kernel package we now get into our ability and I'm not too sure I need to ask that's the actual to the kernel team where I see some water from the kernel team sitting there Which which are the kernel teams plans on that? But yes, I would appreciate if we could get more kernel packages out to build in the same fashion and Perhaps we will have some leftovers for Lenny that we have some recommends that we can't fulfill in Maine technically spoken Which we just ignore because they are kernel packages easily be built, but we will see that Okay, next question There's one You have two questions if I can what one's about the bin and emu's and the other ones about the bug tracking system I find when I'm working with my packages sometimes I Just increment my package and upload it rather than requesting a bin MNU Which should probably be more appropriate because maintainers can't can't auto-schedule bin MNUs So from my first question is have you thought about opening up who can actually schedule bin MNUs and and allowing maintainers to do it and My second question is with the the BTS some of the other teams in Debian have pseudo packages in the BTS like FTP masters and Occasionally I find myself wanting to put a request into the release team Which would be much better suited logged in in the BTS because then it's recorded and then we can track What's happening to it and and sometimes issues do do sort of go on over days or weeks or months Have you thought about setting up a pseudo package in the BTS for the release team? Okay First the first question actually it's not the release team who decides who can schedule bin and emu's for example I can't So it's a wanna build maintainers who or build demon maintenance who makes decision was the architect or say well for my architecture I don't mind if this person has the ability to schedule them So a great advantage has been in use is that mostly if you notice as a transition ongoing It's mostly than Steve food has Because he's also able to schedule them who goes to the well all of these packages this list are now necessary So we just get one of all of them So this makes it easy if you have a large list of packages Of course, we say well if I upload this package one package needs to be rebuilt It's always the same time you need for an up a source full upload But if you have oh for this package I have these 20 packages it makes a difference So yes, but I think that bin and emu's are not Or I said it might be that we want to have some changes there But actually for us it worked very well so far and now we can see how we can further improve it But it's already working very well at least from my perspective But I'm only someone but for me it's just easier because if I see something needing bin and emu such as Steve Please look at this in that package for bin and emu So perhaps Steve wants to add something to that You should have power Okay, I actually have several comments if I may first I'll go ahead and respond to that one regarding the bin and emu's Ryan Murray is principally the person responsible for deciding who it has access in general for bin and emu's and I Have talked with him some about whether bin and emu's are something that individual developers should be able to schedule and You know, it's it's something that we do need to figure out how we're going to address the various Potential downsides of that in it. It's easier to schedule a bin and emu than it is to schedule an upload And we want to make sure that as a result of that people don't Casually schedule a lot of bin and emu's that shouldn't be scheduled that will as a result hammer the buildies and Cost problems of various kinds They also do tend to need to be coordinated to some degree in terms of transitions that are going on in unstable at any given time So I mean as it the benefit for the release team of having bin and emu's as an option has been that We know a transition needs to happen. We know all these packages need to be rebuilt It's way easier for us rather than coordinating with 20 different maintainers or doing nm use our by ourselves Going through the nm you process for those to just be able to get the binaries scheduled and have the buildy maintainers upload those binaries in a case where you're talking about you've got a handful of packages that you know about and Uploading a sourceful build to trigger a rebuild It's it's not really anything that that we mind I hope it's not too much enough of a burden for you that Yeah, so if it's not something that's a burden for the maintainer sure do it If you if you find that it's something that you would prefer to not have to do the sourceful uploads Ask the release team and we'll take care of that as well So that's all my comments on bin and emu's I had a couple of other comments I have I could go ahead. I have another question first to answer Steve Okay So the second the second question was whether we consigned using a pseudo package for the release team Actually, I don't think we ever discussed about that That might be the nature of the fact that nobody asked us up to now So yes, I Think we should consider that We didn't do so up to now so I don't have any answer to it Perhaps it might also end up using a T or something else. We will just see Yeah, okay now Steve Okay, my other comments were You mentioned in your slides reasons why packages don't transition drunk don't transition to testing and you mentioned RC bugs and you mentioned Them being too young one thing you didn't mention was not being built on all all architectures and how that is a requirement Set has been brought it sucked out in some between some version of my slides, right? And so there are various reasons why packages will not build Are not built some some are related to the build bees some are going to be architecture specific bugs in your source packages so one thing I would encourage all maintainers to do is They can use the pts to find information about where their packages have not yet been built and and what's holding their packages out of testing There's also a great script in the dev scripts package called grep-excuses Which hits the web page from Brittany that explains why a package is or is not being considered for testing propagation Please use the use one of those tools to see what the status of your packages are as far as transitioning into testing So that you know, you don't have to wait for the release team to let you know There's a problem so that you can participate in making sure that that your packages are ready to go into testing as soon as possible and so that The version that you want to get into the release guts gets there because we won't unless there's a release critical bug or a Related transition we won't necessarily tell you that your package is stuck in unstable that information is out there Please use it and and also if you notice an issue like this package fails to build from source on Uncertain architecture, please file a bug even for on your own package because if you find a seabuck first of all The least thing we'll see oh the package is not just waiting for some obscure reason because it's not staying long in the building queue But it's really failing to build so that we can take a look supporters can take a look at and all actions that are happening on the package I actually like the exact same in the bug so that we can see oh, yeah This person has commented set part on the bug or that set part on the bug It makes our life easier to see why a package isn't going so really a seabuck's are something to help So if you find one, please file it Okay, next question don't be afraid to shy here Another issue I've come across and Steve will Steve will recognize this because he's he's done a lot of work in this area You said keep keep your libraries in a reasonable state What I'm seeing is an explosion in upstream immature libraries things like version symbols and and and stuff like that which a lot of upstream library Maintainers don't realize are of beneficial to to buy new distributions such as our self I find myself constantly trying to educate upstreams as to as to as to good library practice and good library packaging And and I think that's something we could possibly coordinate a bit better and have some really good Source documentation that we could that we could refer upstream Immature library Writers as to how they should be doing that the libraries I'm seeing some particular issues with a whole bunch of KDE libraries at the moment Yes, definitely a very good point and I would appreciate anybody who starts writing such a improving our existing documents I'm Well, I'm also not so I wouldn't say I'm the main expert on libraries in Debian I know who who whom I can ask which is among Steve are some other people like team who is also here and other people who know How libraries work? I learned a lot about libraries when I fix a little PNG mess last year But that's not the way I prefer it So yes, if you have some more input on the documents that we have also Please say so and if there's anything that I could or we the least team could reasonably do for you I'm definitely interested in doing this Actually, sir. Yes, that's one a part is there. Good. This is good. Good hidden is always in Debian one document is Some bits are in the developer's reference some bits are in this library packaging guide where which is not How should I say there's a different opinion on the guide? So we should perhaps try to get some from the different opinions to have a common opinion of the project how a library should be maintained So there are two good documents By Ulrich Zepper Package library so anybody who passed the new to the new maintainer process about 2003 or later should have read these document as part of the new maintainer process. I did Not use guys, but Ulrich Zepper's document But I basically learned how elf works as part of a new maintainer process and I learned how libraries work as part of the PNG mess So, yeah, but it would be good to really have one document That's a common opinion of the Debian project and not how is it on some private websites of developers or even non-developers. I Guess you have a plans for when to release Lenny But do you have plans when to release the edge with new kernels because currently does already have lots of hardware sold Which is not supported by the edge kernel You mean when we want to lease the next version of the edge kernels that we have an actual release plan for that Oh, somebody working on that Now this is Dennis assume then Fraser. Yeah, okay Make microphone, please Yeah, so last I talked to Martin Zobel about this we were talking about doing a year after edge would be about April So probably around January or so we'd want to start getting everything frozen So people can start testing this kernel before we put it into an update. Well, I'm just I'll tell my head I would say about January we would when I started Freezing it down so that we'd have something ready Actually, of course if we put a new kernel in we need to really test it so Properly, it's not possible as if I say we do a new kernel and find bugs Then when the first user installs those data systems. So, yeah But that's really a part of an experiment for us as well So we need to see how it works out and I'm definitely sure we will make lots of mistakes, but which we can do better in Lenny's in Yeah, and in the meantime We're also doing trying to do more regular stable updates of the two six 18 kernel on edge Well, we'll take certain types of driver updates like PCID updates and stuff like that So you can certainly bring that up on the kernel list and we'll talk about that Okay Next question, please Okay If then if there are no more questions, I think I can just say thank you you all for coming And if you have more questions that you didn't want to speak about I think you will know where to find us on depth conf Okay, so thank you very much