 Hi everybody, this is Lucas Nussbaum and this is quality assurance of the continuing from last Tuesday Okay, thank you. So To start with I've listed things that we could discuss today. So some of the things were already discussed on Monday, I think So first thing is the handling of hand packages Then there's a problem of removing packages from unstable when it's for QA reasons We could discuss MIA We could discuss UDD We could discuss replacement or the improvement of the Debian developer package of a view We could make it we could discuss how to make it easier for new contributors to contribute to QA During when we prepared this both actually discovered that we don't have a wiki page on the wiki for QA, which we need to fix and Another point that was raised during the Mondays both is that pub can is not really relevant for some areas of Debian and What can we do to improve that? so the So with that we worked on a proposal for the handling for fun packages, which I'm going to Outline now and then we can discuss it and I meant it. It's only a proposal So first this proposal applies for Lenny plus one not for Lenny because if we start Well, the proposal is about removing packages from testing or fun packages from testing And if we start removing packages now, that's of users will miss some stuff because nobody noticed that it was removed So the first point of the proposal is to move the orphan the O, ATA and LFA bugs to the package they affect instead of assigning them to the WNPP package and then to set them serious and To tag them WNPP so we can easily find them all So those bugs are serious So this has to be this only a proposal. So maybe the release team will completely disagree. We'll see So those package Since the RC buggy they are removed from testing in the same way as the other package So that means that if a package is useful is a reverse Dependency for another package we might the release team might choose not to remove it but sometimes In the past it's a release team removed a buggy package and it's and the package that used it If it's only a small amount of small number of package Something else related to that is well the problem is that usually Developers and users don't know about The package that they use I mean severe if there are orphaned or if RC buggy So what we could simple thing that we could do Yeah, he's had a crown script to the death with package that sends a mail weekly with the newly orphaned Packages amongst those were installed. So it's mainly writing a small wrapper around RC alert and WNPP Yeah, oh Something else that users are usually not aware of is locally or obsolete Installed yeah, it's an obsolete package that package that were removed and are still installed or The package that were installed from outside sources. So the same script just warns the user about such packages It's important when a package is removed because you have to discover that it was removed so Pro and cons for this proposal So pro it's mostly an automated process. It would be really easy to implement We don't need to review each package. That's just a default default action for each package But this this proposal doesn't solve there we have a lot of negative package in Unstable problem. So it we would still keep all the orphaned packages in unstable, which is not really satisfying So we actually separated the two these two two aspects. So there's a second proposal for this So how to remove package from unstable for qa reasons? So these targets you will use less packages and Packages which are in bad shape the problem with that is if a package is useful to some users But it's it's in bad shape. Should we remove it or not? That's not easy to decide So the main well actually I maybe we can discuss after it or just go through all of it and then we can start so First well the problem is We need to make it easier to remove and to get back packages. Actually the problem that currently is quite hard So we could use a separate component on separate section of the archive for unsupported packages where we will put all the orphaned packages But the problem is then you have to modify a lot of tools to make let them know about this additional section and Actually, what happens? Well Ubuntu does that with main and universe and what happens that user just install packages without looking at Where they come from? So that they end up not knowing what is supported and what isn't so that's not really a nice solution. I think oh We have to develop tools to list packages that are supported and those aren't Supported that's not really good So we could remove them completely but make it easier to get them back So for example, we could try to keep the bind well when the removal is not for Licensing reason for example We could keep the binary package in some public place So users who really need this package even if it was removed and it's not of good quality Can still get it there and it's easy for developers to get them back So that basically boils down to something like a user friendly and official of course snapshot.debion.net Another problem that maybe we need to discuss with FTP masters is that it's currently quite difficult to know for which reason a package was removed There's a there's a big text file with the logs of all the removals, but you can't pass it easily and Well, you have to just to find the bug number to know why it was removed is not really It takes a lot of time So the rest of the document is just placeholders for ideas about the other things So, yeah, who wants to start? Okay, so yeah for the microphone if you only have a really short point to make You can make it without the microphones making loud and then the next one who talks try to repeat it because if it's just I don't think that we Can or should Make a bug series because they That's essentially there the use case. They are invented so that someone can offer a package without actually letting go of it and I think that's no reason to move them out of testing or out of stable releases. I mean At least not automated. I mean, of course, you can say to someone who has filed an FAA and Neglects the package that he probably should retitle it to an orphan But I don't think we should remove them automatically From testing for air FAA. Yeah for air FAA and For ITA's that were previously FAA's My problem is ITA bag bugs that often they stay ITA for a while then go back to all states So there's no no, I mean if an FAA bug is Retitled to an ITA bug it obviously should not This should obviously not increase its severity. So we can file FAA bugs at important and O bugs at serious and Retitling to them to ITA doesn't change the severity I would even say it's up to the maintainer which severity in our phase filed it So how desperately they wanted to have someone taking over so Well, then maybe it should be orphaned if the maintainer is really desperate about finding someone to maintain Yeah, but the package should if the package is still in the shape word Yeah, we're when I'm still maintaining it, but I really want someone else to take over that's no reason to remove it from testing Yeah, right, so the fun said the bugs are serious if you're You could want to find a new maintainer, but you're not going to commit to support for the whole stable release and the security that a year after the next step table release That's a long time and maybe when you file an RFA then want to commit to maintain it for the next Two years or more So it's up to the maintainer My view actually think that the problem look outside to address with this is that there are a lot of RFA Which just becomes the fact or orphaned packages, but which cannot be recognized as such so maybe the solution is at the Establishing a QA policy in which RFA after one month two months three months becomes automatically orphaned Or at least the process in which maintainers are asked about that Yeah Well, maybe the RFA is our heart. It's hard to find in people adapting Adopting packages using RFA. So I have some packages on RFA for month, which well, I'm keeping to maintain it, but yeah I'm not sure what one month We can't probably can't time that Accurately, but yeah, we should have a look at that Yeah, just beside timing it the point is having being sure that's at some point it will became an O Yeah, just to underline that the most important thing is to check that there's been activity on the package before automatically Retightening it and one of the things that would be useful is to try to encourage People who are coming in to contribute to Debbie and to pick up packages, which are RFA Instead of just packaging new stuff that nobody uses so I Had a package which was on RFA for to Debbie and releases. I wanted people to take it But I that did not mean that the package is going into disrepair. I kept maintaining it So I think automatically changing something that the maintainer has said that I'm requesting assistance They shouldn't go too often because if the maintainer wants to often it is they can always often it, you know So RFA just means I don't like this package anymore. I want somebody to take it, please But it doesn't mean that it is abandoned And so no automated process should overrule that Well, Manoj, but I think That only shows that you're a good maintainer Many people use the RFA just saying I Don't like or finding packages, but they don't care a bit about this one anymore and well maybe Automatically sending a mail to the after certain time without any action Could be a good option. Also, maybe if If a package has been RFA and has had no action for say no, no new upload for a certain amount of time then It could be promoted say to orphan or something like that because many people are not as responsible Well, we shouldn't treat we shouldn't by default Treats developers as bad developers. I mean, this is the thing that people say about my country or poison the United States That everybody treats people like criminals and that is a bad thing. I think it's also a bad thing to treat developers as bad developers by default So the thing about not having a new upload if they were The package that I had put on assistant hasn't had a upstream upload since 1996 People are still using it. It was useful. It was not in bad shape. I kept it compliant with policy I don't say why it would just slide into being orphan You you are penalizing a good developer by taking a package that they're maintaining and find useful and Think that oh you could be a bad developer. So I'm going to orphan it from you. I don't think that's the right Message we want to send So several comments first if you kept it compliant with policy You did uploads for it. So Yeah, okay. Okay. So, yeah, so so it was compliant with policy Just didn't state the new standard version, but we don't encourage uploads for that. Okay. Yeah, right. Okay, so I Agree with you. I think an RFA means that the package is still in the hand of the maintainer and There's should be no automated way to take it away from him We we should use tools like papasi that we have or that we develop to look at these packages, but it should not be in any way automated, but should require manual Interaction and often bark means I I I give up this package. So the maintainer gives up his rights and we can the QA group can decide what to do with it, but an RFA leaves the package in the hand of the maintainer and We should find the reason to take it away from him and not do it automated Just to even amplify though There's no reason why we can't find reasonable metrics for looking at a package if a maintainer is not responding for pings on an RFA bug If the RFA bug has no status if the maintainer doesn't respond if they're open bugs that have no change in status I mean these are all methods that can be used as stuff to feed into a Semi-automated process to automatically identify bugs that okay. These are bugs that are likely to be orphaned So it's not a case that we only have to have a manual process. We should have There's a point for some automation with human oversight Yes, the process should be automated, but the action they can't be manual, right exactly Indeed there's nothing specific to RFA, but this is a case where we know That there's a possibility that the package is going to become orphaned Just for detail on the proposal is everybody okay with the idea of moving the or ITA and RFA bugs to the package affected Yeah The only thing to wait on that is to make sure that I finished effects support in the BTS So do it for a couple of tests that make sure it works sanely and then you can move them all what affects Okay, so effects is a new feature which enables you to Modify To nominate a bug as affecting some other package. So there are lots of times where you have bugs that It's not a bug in your package But your package happens to be the package that users figure out that there's a bug For example, if libc6 is totally hideously busted and your package seg faults Well, it may not be the fault your package. It's libc6's fault for example So you could take this bug and say okay this bug that's actually filed against libc6 affects my package it'll show up in your package list and Hopefully users as they're checking to see why the crap is your package So buggy will see this bug and not file another bug that you have to reassign to libc6 and merge with the existing bug Why but in that case we were only thinking about reassigning to the package without marking Well, so the idea is for orphaned ITA and RFA bugs you would assign them to the package mark them as affecting the WMPP pseudo package and Because you've done that they will They show up still in WMPP So that if you're a QA person you can get the overview of all those bugs instantly And they show up in the original package so that they affect transition So you prefer it would prefer to have that instead of WMPP tag You can still use tags in addition, but well, then you get redundancy between Well, the tags have are much more than just WMPP because the tags you can use to sort you can use to do other things Besides just indicating that they affect a package So I mean I don't see a point for just tagging the bugs in PMPP because they're already going to be there But you're not doing that currently you're using tags like, you know, it's WMPP orphan WMPP Whatever I'm assuming right? Yeah, but it's the point of the WMPP tag That's then you can get all the bugs with that tag easily, but you can do the same if it's effective You just go effects equals WMPP and bam they all show up Well, sometimes I always start to reassign the box to both the main package and WMPP is I don't know What's the main difference between doing that and you see What affects? So the reason why you don't want to use comma deliminated Packages is because a comma deliminated bug is a bug that can be fixed by a change in either package It does not matter which package you fix it in either package can fix the bug correctly An effects bug can only be fixed by a change in the package, which it's actually assigned so We currently use comma assigned bugs, but it's not the right way The right way is to assign the bug to the package where the bug is in and affects everything else Yeah, but well we could also use a point of view where in Using it also in WMPP One can remove the package or find it and that's the other status and that's Sure possible way to fix in the time that you're going to remove a package You're going to then clone the bug and reassign the clone Orphan bug to fdp.devn.org at the point of removal. It's no longer a problem of WMPP. That's FTP master bug so Yeah, it would be appropriate to sign it to WMPP at that point Why do we have it done? What do you say about adding support? So, okay, let's let's assume we remove the back the bug to the affected packages and I Think that would solve the visibility problem of orphaned package would be to have a sorting in the BTS So that when you go to the BTS page for a given package You see first maybe with a big fat warning something like this package is orphan You'll see that. Sorry, you'll see that already because it'll have a serious bug that's open And so it'll be at the top and and serious it makes package unfit for release Etc. So it should be warning enough that your package has issues It'll show up in things like RC alert and etc Does someone else has something to say about this or should we move on? Move on. Do we all agree that orphaned bugs should be It's a very serious. I mean it's a lot of change, but yeah Just a quick comment on that for removal bugs. These could be tagged as affecting the very package that is being removed Though that's another point for visibility You mean using affects for that. Yeah, I I Guess that's something that we should probably work with that to be mastered to figure out how they want to work that because that's really an FTP master sort of decision, but it is an option Maybe that something a policy that needs to be Documented better because there's easier tax for FTP master that no one is using so Okay, so let's move on no one else Okay, so I literally read this yeah So again if yeah Okay For the bugs feel free to take them in whatever way you want retitles them effect whatever We always like it if someone is going through our buck list We never complain that one For the removes the more removal is the better Sorry, I didn't the more we move is the better we like to remove packages as much as we like to accept new ones in Well, the problem with removals is that when we move a package no longer available for sometimes it's a problem for some users So I think it was Use less packages sometimes are useful to a few users for good reasons Yeah, we regularly get complaints from a few users that want to package back in Usually it's easy if you just re-uploaded For one point that I read says is user-friendly offers a snapshot devian net says currently a snapshot devian org In the works we are currently talking to sponsors to get machines that can support it Will take a little while until that's officially available, but that would be one solution Do you have a timeline? Just an idea Within half a year or a year or something at latest the sooner the better We currently have the proposal for the hardware written and Send it to our sponsors and see what comes back Some of them already look for ways they can support it But then we need pretty big machines to really support the whole snapshot devian org So it's not something you can easily give out For the difficult to know for which reason a package was removed If someone approaches FTP master and wants a different kind of log file for removals We can easily create something comma separated or XML or whatever we are format something once That's no big problem. Are you finished? Okay? I Still have a problem with the whole term useless package. I mean package in bed shape. I can understand but What exactly for is for you a useless package that's not also in bed shape? Yeah, that's a problem Okay, let's not go down that road Yeah, but for example in currently in Bapaz We have like the list of Old orphan package we have the list of buggy packages and we have the list of often in you Packages and we have the list of useless packages on and currently I find the list of useless packages pretty useless I have to say If you go through it, there are many packages that are well maintained or where we come in I See no problem with that. I mean I have a package student has like nine Popcorn installations and I See no problem with that. I use it Pretty heavily and I will maintain it and so I see no fault in that Well with I think that basically the targets are often packages useless and bed shape Or what two or the three at least or maybe one of the three with a really bad state? Well Frank is right in that direction. It's pretty hard to define useless I agree with Manos and say vi is useless other people will say he makes this useless So that's a pretty Bad target to take packages in bed shape is much easier. You can look at the back Numbers they have you can look at the Standards version if it's something like one not zero. It's probably a bit old Yeah, but then sometimes you have packages that completely neglected for yours And still useful to some users And could be a lot really useful for to some users Yeah But if that's a point we we must not remove them from testing if they are often I Well, they might not even be our front. Yeah, I think we were we should just target often packages If there someone is maintaining a package, it's it's useful per definition or the maintainers we had but if it's maintained it will probably work Um, so I think the useless packages search If useless is often Pretty much resolves them itself by the previous discussion we had if it's removed from testing We can just wait sometime maybe after the next release or two months or whatever and then remove it from Unstable because no one will be hurt And if no one Does scream up at that point? Um They are out of luck Uh, I would like to say also about these packages which have low popcorn score for example we are seeing a problem of archive growing pretty much exponentially right and That's mostly due to the packages which have low popcorn scores. I bet Even the if they are well maintained Right people write something people write the utility which only they are using or maybe they are friends They push it into the debit into debian We end up with you know, three or five dvds. I don't know how many So the the the idea is that it is probably worth thinking maybe in not in this case, but In some larger sub project that we need a way to somehow you know Remove packages which We don't need like I don't I don't think we need 10 different dns servers in debian or something like that Well, okay dns server is a bad example But but but i'm sure there are other categories of packages where you have a couple of packages which I use Frequently and by a lot of people and then you have a long tail of packages which would have very low popcorn scores Sorry, if I could just one of the things that another set of packages, even if there's That's totally separate are packages which are not maintained And not used and because of those two things we have no clue that they're in bad shape because no one files bugs about anything Um That's far more important to me than packages that are maintained and not used by a lot of people Or packages that are maintained and only used by one person The thing that concerns me is packages that are doing nothing but loading the archive packages that no one uses And no one maintains and it's kind of hard to find those but you can sort of look at popcorn Maybe give you a clue. The other big thing is looking at Um number of uploads So I mean if you combine popcorn with recent uploads Then that would give you a set of packages that maybe you should ping the maintainer Um if the maintainer doesn't respond and say that oh, yeah, I use this package Or yeah users are using this package even though it doesn't show up on popcorn Then maybe those are some packages that should be removed. I don't know if you are familiar with bapas which I Briefly everyone I will just show you as soon as the browser starts Yeah, my laptop is slow So, uh, is that okay? Yeah Okay, so this list packages using different criterias. So we have the The the time Number of days since when it was orphaned won't be able to show it in the mouse Yeah, so this package, for example, was orphaned in 2002 Uh, this is the number of days since when it was last in testing and since It last migrated to testing And Up come Time of the last upload which is broken currently it shouldn't It's a number of nm use since the last maintainer upload. So with this kind of Thing and with ascending a score to each conon you can kind of get via an idea of Good targets for what you basically do. That's what you just said. That's pretty useful. Yeah Probably good to make a dda post about it or some things that people are aware that it exists I think that the only thing it's which is missing in bapasa which don't mention is the frequency of uploads So you already have the any number of nm use but you currently doesn't that don't have The number of uploads in the last year or something. Well, we have the last upload and see if the last upload is three years ago I'm not sure if we need to have the frequency because If it's if there was enough maintainer uploads in the last year anyway, it's maintained Versus Yeah, sure That's why you need several conons and you have to combine all the data Yeah, I just I think we have to be very careful that any one of these data points We have to be careful because if you see, you know regular uploads of a package that probably means somebody's actively maintaining it But not seeing uploads doesn't mean it's not being actively maintained It may just mean that it's nice stable robust software that doesn't break all the time Yeah, yeah, sure. That's why it works by ascending a score to which conon just to give An idea of which package should be investigated. It's not about removing them automatically I understand that I just want to make sure we don't lose sight of some of this in the talking about these details I wish there was some way of correlating this with how missing in action the maintainer is So if the maintainer is active The chances are that the packages that They're carrying along Are likely to be even looked after so that will take care of Badele's category so If there is something which is not been uploaded for a while, it doesn't have that many users I wish to also note that popcorn Is not universally reliable I have a whole bunch of machines that I use at work where we do not allow popcorn company policy. I know it's stupid, but That is reality people might not allow popcorn requests to go out So we can't just say that there is no popcorn. Therefore, it is not useful in a whole lot of situations So if we know that the maintainer is not MIA, maybe we don't need to Have a look at throwing these packages out I also have this problem with the useless package issue The thing is that no removal should be done automatically. There should always be a contact to the maintainer. So the maintainer even if it's a Package that needs low maintenance can always reply and tell the people This package is still used and works and has no bugs so No package even if it's as low maintained as your package Should get removed yeah it is true that The MIA status of the maintainer would be a useful metric to add It's probably a bit difficult because at the moment we it is not Openly available due to privacy concerns. So it might be Maybe it's possible to just Yeah, export A value a numeric value or something or a metric on its own from there without exposing all the the mails and Status reports that are in the MIA database So that would be the the technical solution would be have would be have to be decided But It is not true that if a maintainer is active and has Packages that are in very good shape and that he maintains actively that That's no reason to offer Other packages of him there are some there are maintainers that Care about only a subset of the packages that they maintain according to packages by and that Don't offer nor even RFA packages that they don't care anymore They just don't upload them anymore. So it's It's also one point of the metric, but You still need to have a look at the package level 2 Yeah, the other problem with using MIA is that if a maintainer has only two or three packages Is unlikely to have been reported to MIA So we won't know is MIA well is and his package Might be might be neglected But everybody is actually in the echelon part of the database Well, the problem is that the MIA status is Well, if you use a metric based on the last activity Then you will see it if you use just the status of the maintainer in the MIA database that is Busy pinged or I don't remember because I'm not really familiar with MIA, but The status of So the state in until which it was the maintainer was processed by the MIA team Then you want to see those maintainer if you use the last activity then it works Yeah So I would think that the MIA database would be a super set of Number of uploads the maintainer has done because every upload Would probably end up in the MIA database, right? I don't know. I've never seen what's in there I can show you your records A couple of comments from peter ronhotson on irc He's saying That maintainers active elsewhere in the debian project do not mean that their packages are cared for You know They can often be Inactive on one package and active on another And he's also saying He's seen several examples of people being active on the lists or other parts of the project But just ignoring several of their packages which are rotting in the archive I'm probably guilty of that myself And Yeah, that's That's Petters comments. Anyway, thanks Anyway, we have to take MIA into account, but it's not the same as for the last upload You can't use only that you have to use that together with the rest of the data Sorry Which problem are we discussing at the moment actually? I don't really see the point Yeah, I think that the problem is to find packages that Are in the archive and that shouldn't be there And to act on that Well, can't you just make often packages not being in testing the target and Well, and be done with discussion Well, it's a problem At the next point If that point doesn't interest you, you can always sleep or something But that's Anyway, the current topic of the discussion. Yeah, no, the problem is that A package is a tag in the archive and that clearly shouldn't be there Just add noise to a lot of things for example to All the qa tasks that run over all the archive Uh, after analyze those package To sort of file bugs and package package that are anyway not interesting Also currently the release team as a policy that is unstable. There shouldn't be anything which is not meant to to be released But okay in addition to that I was trying to move the discussion to the point of which I think is the most The most tricky one in in that part, which is where to put the packages which are removed so that we can Easily restock them When we say that there are a lot of packages in the archive, there's no controversy over that When we say that having a lot of packages in the archive causes Certain things to take more processing time than if there were fewer packages. There's no controversy over that The moment we start talking about, you know The relative value of the different packages. This is where we run into a controversy And I think the challenge that I've always felt around this particular topic is that It is a combination of a case where it's very difficult to come up with an objective criteria End a situation where we are in some sense sort of messing with one of the basic Really very fundamental social characteristics of the debian project for a very long time Which is if there's someone who cares enough to work on something and to contribute it that we would like to have it We would like to have them and their participation and to grow the debian community and its spirit and so forth And so I think it's very very important for us to to try and come up with some sort of objective criteria if we're going to You know change the generally inclusive model of debian For both, you know human participants and packages in the archive And I think we have to be very careful not to be too simplistic about what that objective criteria is because as we've all demonstrated In this conversation, there are you know for every rule that you try to write There's some counter example that says well, here's a case where that's not true So I I I'm not trying to discourage anyone from thinking about this But I would discourage anyone from trying to believe that this is a short term You know something that we can fix quickly with a couple of conversations because I think when we start talking about Changing the rules for sort of acceptance and inclusion of packages in the archive and adding Sort of non package structuring technical or or you know bug related criteria to it That this is this is a very fundamental and deep change in the in the project not a small policy change Sorry that was my way of thinking that I totally agree with what we did Basically Removing a package can be I mean difficult that's everybody agrees maybe just having something which is not really completely qa but I Advertising in some way that some package Debian likes and some package to be unconsidered at some stage he might remove I'll take an example. It's not maybe that's the best one. We have two tftp servers Which as far as I understand have the same code, but one of them have more patches And those patches have been in the BNC's ever and Maybe one of those two could be removed and In some way if some A group of people were just saying okay, we analyze those kind of thing and We just discuss about it and advertise somewhere that One of those two package could be removed at some stage or Traditionally the way this has been done is you go and talk to the guys who are maintaining it and Have them voluntarily say that okay, I'll withdraw mine or Or this one doesn't belong I think I would much rather have that where people themselves Realize that their contributions might not be as useful to the BN or detrimental to the BN rather than trying to impose By a bunch of guys, you know in power to say that your contribution should be thrown out I wasn't talking about being having someone and poor work to say just saying okay, we have those two package They have achieved the same functionality And just all together with the users especially Oh, it's also pretend to be those users and Just Yes, having really the users and their package maintenance And tracking this issue and Just to know if it's possible to remove those two and to Say okay, we prefer this one and this one seems less used And maybe keep it for one release and then just remove it Agree on is that we can't agree on a definition of useless packages because it's just too wide And we are running out of time and should probably go on with something more useless for this time Useful for this time Um, I wanted just to say um I mean debian had in the past defined the way for do for To uh Say for a package that is it that it is duplication because we have the extra Priority but It is not consistently used but something like Uh, I mean that would should should be something. Uh, someone who's interested in that might be looking into Um, so for example, uh reviving the extra priority or Yeah That might be an idea or adding even a lower priority in the archive But um as said before If you Yeah, no that was my point. Can you scroll up a little bit? Lucas scroll up a little bit Um The last word to those proposes you have there the separate section or component for unsupported packages I don't think that this will ever be supported at fdp master For reasons you already mentioned And does someone want to comment on something else? It was in this list We have five minutes left. So Does someone want to comment on anything? Um, so I was I was talking last time when we were During the first qa talk about new possibilities for udd And some ideas which I mentioned So just so they don't get lost It's keeping all the files Of every package the metadata in the udd. So for example, you can detect Cases when a file introduces when the file has a When the package has a file in it, which is already present in another package So that you don't upload the package and after that when the user tries to install it they get the famous error That it tries to override a file from another package That's you want the list of file for each package? I think I think it would be reasonable to like it's not it's not that a lot of information. Is it Well, it is Well, it's not gigabytes, right It is it is We are currently planning a redesign for the duck database and that includes keeping everything we need for packages and for contents in the database It's not that hard to keep it all so So other things where the detection of people building packages against Library versions, which are not currently an unstable for example So udd could contain the list of Libraries, which are currently unstable enough to you ran your After you generated dependencies for your package a lintian check could be made Which would warn if you for example link to a library, which is not currently present in unstable. No, it couldn't Why not? lintian doesn't support external dependencies in it checks Well, it should That's part I I mean the the whole idea of Using udd to introduce new methods is that lintian would optionally support queering udd for data and then using dynamic checks Yeah, it is correct that we need a tool to do that I'm not sure if lintian is the correct place to add it But yeah, we certainly need a tool that the maintainer can run on this local machine and that will fetch all the necessary information In the past we always Did reject the idea to add that to lintian so that lintian would be a static checker that would always result in this Almost always result in the same results if you run it on the same package and the same lintian version um I don't know if we should add that functionality to lintian or write a wrapper around lintian and some other thing like For example, these conflicts check Was mentioned in the mancosi presentation So they have a tool for that Because for example the conflicts check is not simple it needs to It needs to check It is simple in most cases because you can just say that there is no package that conflicts But if you have a probable Conflict you still need to actually download the other package and investigate it because Some things can't automatically Determine like the words Stuff I have a technical objection to doing that check For example when a new version of s c linux comes out The first thing that I built are four new libraries libx linux libxcpaul and so on at the same time if I upload these new libraries. I also need to upload Packages that will work with them check policy and policy loading tools. So what I do is I Set up the dependencies correctly. I have a local pool I build all my packages install it in my local building and then I send it out So at the point I do the upload For These libraries do not exist in the archive yet But what's the point in having a useless Report which is going to be ignored most of the time anyway. I mean lindia needs to be Producing warnings which are relevant so that we don't start just ignoring warnings And miss something which is real in the meanwhile and some of I mean some of these problems are probably better solved on the fdp master level anyway Like the plan to maybe in the future Just rebuild any everything anyway so that your So that only checks against the Build dependencies would make sense anyway. I mean, but Yeah, okay. So I'm sorry. We are Finished Um, is there someone that thinks that we should have a third q-wave off or are we done? You are allowed to say so Okay, cool