 c'est ce que le QA-team fait. Pour quelqu'un qui s'est jointé, c'est... C'est assez difficile pour lui de trouver quelque chose à faire et de trouver les bonnes personnes pour parler. Je pense aussi que le QA-team n'est pas dans une très bonne honte. On a essayé de faire un sprint en février 2000, en février dernier. Mais pas assez de personnes étaient intéressées en arrivant, donc on a décidé de le cancelner. C'est probablement quelque chose que nous pouvons discuter sur comment faire plus de personnes intéressées en faisant le QA. Il y a aussi des QA-teams qui s'occupe de l'outil. Nous avons une channel ISH, qui est d'Iblen QA. Vous pouvez juste aller là si vous voulez aller autour et discuter sur le QA. Nous avons une liste principale. La première question que j'aimerais discuter sur les deux est s'il devrait être plus organisé ou est-ce qu'on peut faire suffisamment? Peut-être qu'une des choses que nous pouvons travailler sur en faisant le sprint, c'est de maire les activités QA et les gens en charge des parts de QA parce que ça serait vraiment aidant de savoir qui le fait. Qu'est-ce que le QA-team fait? Il maintient plusieurs services dans l'infrastructure de Débian, comme le système de pakage et de tracking. Le système de pakage et de tracking est un page qui est un source-pakage centrique où vous savez tout ce qu'il y a dans le pakage. Le DDPO est un page qui maintient la centrale où vous savez tout ce qu'il y a dans le maintenance. Le UDD, qui gère le data de toutes les services dans le Débian à la base centrale. Il y a aussi des services qui sont construits sur le top de l'UDD, pour exemple, pour trouver des intérêts de RC-Bugs. MOL, qui est similaire à l'UDD mais différent, utilise le Berkeley DB plutôt que le PostgreSQL. MOL utilise le Berkeley DB et le UDD utilise le PostgreSQL. DHS, qui est un service qui s'occupe d'un nouvel upstream release et vous mêle quand vous trouvez un nouvel upstream release. Il y a aussi beaucoup d'autres outils qui sont dans le domaine qedaddebian.org. Ce qu'on a aussi fait, c'est d'organiser et d'enregistrer les tests d'archives et des filings de MOL. Donc, comme les rebuilds d'archives, les rebuilds de chaque source pakage, il y a des parts de puits qui testent l'installation de pakages et les rémovélations et les upgrades. Et l'intien, qui est l'analyse statistique des pakages d'archives. Et la troisième partie de l'archive c'est de détecter l'inactivité. Donc, pour prendre la take care of all funds or neglected pakages, il y a aussi des maintenance inactive, maintenance that are missing in action. Missing in action is the name of the team inside the QA team that does this. So, one popular topic of QA buffs at Deppconf is orphaned pakages. I don't think there's much to discuss about this year because we implemented a new process that was discussed like two years ago. So, basically we remove orphaned pakages with a low popcorn and which have been inactive for some time. So, we do a manual review of the package before deciding that it can be removed. But for example, packages that have popcorn below 50 and orphaned that are orphaned haven't seen an upload for the last two years. So, to avoid some users that just cannot install their favorite package anymore the bugs that for the removal of the package mentions snapshots.dbm.org So, users can still find all versions of the package if they really need it. So, the situation about orphaned packages is getting better because in 2009 we had 568 orphaned packages in the archive and now we only have 415 orphaned packages. So, that's progress. So, we get to zero because it's normal that there are some orphaned packages but the older ones are getting removed. So, that's a web page. Let's check if my network works. It might. Or not. Ok, let's say it doesn't work. So, there's a service based on UDDs at least interesting orphaned packages basically on those criteria. Yes, it worked. So, it's just a huge table with a list of orphaned packages and for example at build was orphaned for almost 2000 days. It's currently an ITA but you know it's a number of bugs. Popcorn is broken apparently. I should check that. Then with that you can easily find packages that are good candidates for removal. We also have another process to orphan packages that are no longer maintained but not yet orphaned which happens sometimes so that we can give the package to someone who is interested in maintaining it. The process mainly consists in the interested maintainer going to the BNQA saying oh, this package looks neglected, I'd like to adopt it and someone from the team looking at the package pinging the maintainer and offering it for him. And usually it's enough and people don't complain since they are already away from the BNQA. So, during the discussion I'd like to talk about to discuss QA goals for WIDZI at least what we would like Debian to achieve and then who is going to work on them so we know if this doesn't match that we have a problem and maybe discuss a team organization to see what we can improve about the organization of the QA team and I've prepared on Gobi a list of QA team activities and I'd like to put names in front of the various items so we know who is doing what because currently I don't even know who is doing most of it. Ok, so who wants to start? Should we start with that or should we start with QA goals for WIDZI? Ok, let's start with QA goals for WIDZI I decide. So the first goal I found was no package failing to build from source which is easy for me Can someone help take notes on Gobi maybe so I don't have to write Is someone interested in doing something regarding QA for WIDZI? Work with needs because I have to process build logs etc but I'm not sure the process is clear for everyone and what work it needs just to ensure that no packages are failing So for that what I do is that I just take all source package in Debian rebuild them in a clean route get the build log and if the log failed then file a bug about the failed build and so Didier proposed to help me he already filed about 50 bugs I think about 100 bugs so I continue the good work about this let's open so I can add your name there so your Debian login is audix For curiosity when you are launching the rebuild how many packages are failing the percentage you have an idea I can tell you so for example those are just during the last rebuild 755 and we have currently a bit of 16,000 packages I talk I chat with Didier about this and he told me that you have a web interface to do so no I just have a script because it would be maybe nice to have the access to it very easily and to see how it looks like to get people involved for me it's magical I just see bug reports coming from you on a weekly basis but I don't know how you are managing that and it's kind of blurry for me so I don't know if it is tricky or easy and so on so well maybe I have some yeah I have some logs so let's make a short quick demo so in this directory I have all the failed logs so for example I have a script that goes through logs and just displays a likely failure for example a beward is failing to build and the error message is that one the script just finds uses value statistics to find a likely error so when it's about build depends it's really easy to pass when it's about GCC errors it's really easy to pass when it's about for example it's really hard to pass and then I have to copy paste manually but then for example oh wait oh nah it won't work I'm trying to well cause all the bugs are filed I think in the last rebuild oh no there are some don't fight ok so let's file those I won't say in the mail because it's not really recent so when I file I need to set the date so when I file bugs I get I have a script that just goes through every bug matching a ragged so I can file all all GCC errors at the same time so I'm just filing the remaining bugs and then it extracts better log the interesting part of the log for example this package fails with that error with the java package that's why I didn't file it and my script can't extract the error message cause java is just really annoying to pass so in that case normally I get a list of bugs I ask the bugs already filed against the package so I can just press so I get the list and I can just press 2 to say that's bug number 2 my list of bugs get annotated with the bugs that are already filed for example by someone else or I can report a new bug and then I get a mut to open with the bug mail so in that case I would have to hmm I just have to find the right error message let's say it's that one but it's not that one well let's try to do it correctly hmm well I could copy that one ok and then send it for having done that once the problem I saw is that you have to do it fast because as the archive is changing you have to report the reports within a week at most well I would say within 2 days ok even so the problem is that 1 or 2 persons have to do this work manually to report bugs or semi manually to report bugs within 2 days so if we are 2 we have to process 700 build logs so it's much work and I'm wondering if the BTS is the good tool for this hmm how much work would it be for example to just publish the logs and detecting failing or not and sending automated mail to maintainers saying ok at the last rebuild it has failed and go take a look and then sending a section in the BTS something and this would avoid a lot of work for us but it would transmit the same information I think well usually people don't like automated emails and well at some well it happens that I just sent a DD list of packages failing to Debian Devil sometimes but the response is quite low actually most people don't fix their package and you just do that and also it's important to file the bug so that it gets blocked when migrating to testing and you know about it from those 750 logs how many of them are already filed bugs not that much hmm I don't have a way to know but I think that currently I'm almost the only one doing archive rebuild even partial at some point Daniel Schlepper was filing quite a lot of them but I don't think he has been doing it recently and from rebuild to rebuild so how many new bugs appear well it depends on the time between rebuilds when I'm not too busy I try to rebuild every two weeks because it's important to avoid getting too many big transitions too many big changes between two rebuilds so you know that what changes basically between the two rebuilds and when you have a rebuild when you wait one or two months then you get several things changes you can say oh it's likely to be GCC 4.6 problem because that's the thing that changes since my last rebuild so my scripts also work with something I've wrote which is similar to pure parts so I can do installation testing it's not really ready for well it could be a pure parts replacement but although it's not here yep but that's not the only thing you create in does ok so one of my could you go back to Gobi one of my personal goal is to have a streamline upgrade for default desktop installs which means like if people have installed default desktop for squeeze then just upgrades to with issues like be trivial to do and also work out the bugs we didn't have that for squeeze we have a few bugs that I'm still trying to fix in stable which plagued a few users and I think it make us really bad for desktop users there's no way to test that automatically I guess but it's QA because it involves the wall desktop and all environment stuff so yeah well for example like Wunderberg who is still in squeeze and not fixed that if you had upgraded from Leni with a studio base installation then once you have upgraded in squeeze there is no single tool graphical administration tool that works because there is a problem in system tools back end there's no way you can test that automatically it's like user I mean now that the release team I set it for freeze dates it's fairly easy to from that date try to do upgrades and see if the resulting system works now something else so I could add my own wish list but things that I won't work on but so that's probably Olga but it wasn't it was far from being fully covered for quiz and probably it needs some help so I have my own script for that but it's not as polished as a rebuild one so it needs more manual work but if Didier wants to do that as well my goal is really to stop doing the log analysis myself so I will continue to do it if nobody steps up but I'd like to get rid of that I've been doing it since 2007 so I'm a bit tired of that I was thinking in some automatic process to detect how awful the recommend part for packages because sometimes I found packages that pulled a lot of stuff from the comments that they don't show but the thing that I do is I just report manually but I think it's hard to write something to figure out if the recommends are too excessive for a package we could try to to detect packages that have well strange behavior well lots of packages instead they are recommends but there are some that have good reasons to do that like death scripts I'm not sure if it's a good reason but death scripts installs like 200 megs of recommends when you install it so something else so well if nobody else has ideas about that we can try to fill this so we will have a clean documentation of who is doing what in the QA team which will be a bit depressing but we will maintain the pts ok I never remember if your login is adzog or just adzog so ddpo that's me I don't know if it's adzog maul maul is a work of jero and van wolfflar but away from debian since quite a few years now well he has not left but he is not active anymore and well not many people know it it's not quite like UDD it's much more sort of way to organize archiv white either checks or data extraction or stuff like that 2 parts in maul there is data storage stuff that is based on berkeley db as a database that had actually in the start the same goal UDD came later so UDD had the same goals as maul it was to gather all the data about debian in a single place and there is a sort of scheduler that can that is is running archiv white stuff exactly there are basic database which well db like you say with keys representing all the source packages and you can easily schedule a task to be done on each source packages and every time there is a new source package that appears it will automatically schedule the work I used that at one point for the symbol stuff extraction but since nobody wanted to take it over it's no goal but you can use it for similar stuff and it's useful UDD is much more to find statistics and I would say that the main point of maul is really the scheduler site for organizing some archiv-wide checks for that extraction maybe it can be useful for other topics I know we will probably discuss this in the lintian buff because we are testing in doing archiv-wide checks and automatically extracting source packages maybe the stuff to consolidate with lintian here but we'll see so well the next item is DHS there are two versions now of DHS there is a alias one which is not really which used to be maintained by Raphael jeter and there is a QA one which has been written by Mayan Mayan for now yes the first version was only maintained by Raphael it disappeared for a few months and then someone had to rewrite it which is a bit lots of time lost so what are the other services that we maintain well there is not much on the website but I think probably one of the last today we did a commit I know how to commit something actually we could migrate it to wikidebian.org there is not much on the website but it could be useful to have more statistics on it probably generated with UDD I know that when I started work on QA I was keen on looking at packages with most bugs biggest number of bugs and I don't think we have any official place for that kind of statistics usually you get a response oh it's this UDD query I was about to say that and with yourself but it's not really the best answer we can give to someone who just wants to look at the bugs is it really useful to just send people to packages with the most bugs well it's probably not a good idea to send them over there but people are looking for it so those who want I don't see why we could not provide it in a practical way so maybe that's something we can add well it's easier to add as a CGI in UDD if we want to add other goals without people doing them I would like some way to ensure that all packages are maintained and not only in a corrective way because we detect problems but in a proactive way so ensuring that people are still active I don't know if it takes I don't know the precise means if it's a ping every year or anything else but it's something I'd like us to investigate but do you mean that by package or by persons well a combination of both because we have all the cases I mean there are packages with active maintainers but the maintainer doesn't care anymore about this package but did not take care to affirm it and we have maintainers who disappeared completely sorry yes exactly one of the limit she is asking what about teams because many packages are maintained by teams so how do we deal with teams effectively it's one of the problem sometimes we have teams but no people behind teams so that way it would be we should have a way to for maintainers to say ok I'm taking the responsibility for this package this is usually already down via uploaders but you don't have any yeah sometimes you add yourself to uploaders just because you want to upload and not generate a warning no way it's not any longer needed because you can put team upload in the changelog and it won't generate the warning so I tend to not put myself in uploaders of packages that I don't plan to maintain on a regular basis and I encourage everybody to do the same but actually we have many packages where uploaders is not really significant but the goal would be to ping those people and ask them to define their role do they consider themselves as a responsible or only as a backup or even forget that they were in these uploaders and they want absolutely no responsibility and so on I know it's a difficult topic but it's something I'd like to investigate if I have to do it myself I don't know when it will be probably in a few years when DPKG has no bugs anymore haha but it's something interesting for everybody and it's not difficult more of a social problem than a technical one so you don't need much experience even to be able to work on this idea just need some time and discuss with people yes I think it's a problem that I've seen also simple I reported a bug against the XPRA package and then the BDS says that it's maintained by the Python applications packaging team and then I'm like who should I talk to there's a new upstream version I'd like to ask about some questions and BDS is not very good for asking casual questions so something where the maintainer could say in the fate of this package but others in this team can also help would be useful I don't know how to do it but it's a good point right now currently if I were you I would look at that person who uploaded the package it's the best way but I agree it would be good to have a more structured information you asked about PAPT the way that generally handled in PAPT if PAPT is in the maintainer fields then any PAPT member is welcome to touch the package and if PAPT is only an uploader then preferably that loader should be asked but if you come into hash, Debbie and Python and ask around chances are someone will tell you that's the particular one yeah I think also about the GOALS for Wissing we need some system or reporting crappy maintainers in a way when a lot of people report a package like no well maintainer sending an email to the maintainer to tell him that this number of people thinks he's not doing a good job I would like it, it's your idea crappy sometimes somebody tells somebody else that he's not doing a good job but usually when only one person tells it doesn't work out very well and I think there is a system like I don't know four people have reported that in the last year that you are not doing a good job with this package and allow some system of inserting because you did this you did this it might help to some people adopting some packages I don't know, it might not work out it's something to consider well if you are interested in working on it I work on it personally when I think somebody is doing something well I'm in this person but usually a single email doesn't help I'm truly unsure if I actually shame because that kind of reporting that you've suggested is like a shaming people yeah but even privately I mean if I get a message like saying hey five people hate you then I'm not going to feel any better in doing more work actually or getting back to it because sometimes it's just a matter of your life just gets back to you and you're not active for a few months and then it's hard to get back to do actual work and I would rather have ways that would actually make it easier for people to get back to work or to accept others doing work than actually shaming them because I think given the volunteer nature of Zibyan it will be probably a more effective mechanism but I mean it's like I've had to hijack a package in the rest like in the last few months and I mean at some point I was really fed up with the package being old and maintain and having missed squeeze and so I just you know I asked Zibyan Duval and I had a positive answer like people told me hey good do that please hijack that package I got three mails doing that and I was happy that people tell me soon I hijacked the package and it went fine I mean what's strange I never get any answer from that particular maintenance never ever like even after the hijack I was like what? Like telling people there is five people who hate you they try to maintain a package and they are they are already conscious that they don't giving the package all the time they need but until somebody doesn't tell them that like some pushing that maybe the package is better to be orphan and somebody else takes over people doesn't realize because they think that they orphan the package no one is going to maintain it I don't know and right now I am talking about packages some people can be doing their own job with a set of packages and doing crap in a zip package doesn't mean that the person is doing crap all the time using certain packages we don't have a way of handling this as a project I don't think this is going to be the last solution but I don't know I think it will be an interesting experiment in my case when I think somebody is not doing a good job I try to send a nice email usually the email gets ignored or the answer is if I orphan the package nobody else is going to maintain it and is going to disappear from the email that maybe will be better that's my point so we have 5 minutes remaining so I think it's we could change the topic I think it's interesting but as far as I know the orphan packages are maintained by the QAT that is not defined that's not pretty true as well and in the end we want to remove these packages but I am certain that among these packages there are some that we cannot afford to remove and for which some people sometimes do an upload just to make sure it still works but still under the QAT umbrella so maybe one work that we should do is go through the list of packages that are orphaned and send well written mails to devin devil to build new teams around this because it's not sustainable to keep them in the QAT team and because the packages that are orphaned are deemed to either be adopted or removed and we cannot have packages that cannot either be adopted or removed and that end up maintained by the QAT team that's not sustainable so maybe pointing the packages that need special treatment and for which we need to build a team around could be a good thing to do for a reason I think well and I could help ok just do it I think it's a great idea the main problem is that it takes time and with 400 packages everything takes a lot of time so well just start with the list yeah it's true that if you look at maintainers that go away and send a summary mail to devin devil ok here's my package this one needs this kind of care it uses this language easy to maintain those packages tend to get adopted creatively quickly those who just file their orphaned bag and do not mail anybody will linger for months even if they show up in the automated listing people do not look at those or some people do but usually not those who are already busy or the packages only really new maintainers who have read the documentation oh I should find a package if I want to enter devin I last year I think oh no 2 years ago I suggested to go even further not only mailing devin devil but maybe upstream lists to say oh we used to have this package it's orphaned and maybe someone in your community would like to join devin but again that's more work so next topic someone edited the goby page so ddpo by email is a service that used to send emails to developers about the issues in their packages like a list of current open RC bugs current testing migration problems and stuff like that et c'est tout pour le reste et je l'ai arrêté parce que c'est un peu de temps je pense que c'est assez utile d'avoir une mail à la fois de la semaine qui vous reste sur toutes les issues dans votre package si quelqu'un veut prendre ça les scripts peuvent encore travailler ou bien travailler il faut juste quelqu'un prendre ça parce qu'il faut réveiller les emails pour vendre 500 emails pour réveiller quelques d'entre eux pour s'assurer que tout va bien pendant la génération je n'ai pas réveillé tous les emails mais j'ai pris 10 emails et tout a bien regardé donc vous voulez prendre ça ? donc c'est dacca c'est d'automater d'automater je pense que c'est maintenu par Raphael mais on peut dire le problème avec Raphael est que c'est très grand c'est souvent active depuis deux mois je ne veux pas parler pour lui mais je pense que Zac va travailler aussi pour ça mais peut-être je vais lui aider avec ça mais je n'ai pas pensé qu'il s'est réveillé depuis qu'il s'est réveillé il y a trois outils qui sont réveillés un outil pour vérifier le bâchisme et l'autre c'est le cpp-check et comment l'H.O.C. et dans le futur on peut ajouter un nouveau outil pour celui-ci si il veut faire ça c'est quelqu'un qui a fait Pet Pet n'est pas maintenu par la QI team Pet est cette page le status de la team par l'asvn repository c'est très utile il n'y a pas la QI team je ne sais pas pourquoi si Ansgar est ici non juste pour lui pour qu'il le maintienne dans l'infrastructure de la DB j'ai déjà essayé c'est le type d'outil dans l'infrastructure de la DB et pas l'outil le code est en alias en fait c'est pas trop mauvais mais c'est bon c'est une élection c'est une élection je ne sais pas qui va faire un MIA la plupart du monde l'a fait par J.E.H.R je n'ai pas oublié son nom maintenant j'ai presque répondu aux emails depuis 1 ou 2 ans 1 an je crois que nous avons besoin d'autres gens parce que parfois c'est assez difficile de garder le tract pour les gens qui ont été réportés et peut-être j'étais en train de demander à la DSA pour créer une spécifique RT pour qu'on puisse travailler mieux parce que l'infrastructure de la MIA c'est assez difficile de manipuler c'est horrible si tu es un newcomer et tu n'as pas le droit de rejoindre la MIA et aussi de travailler c'est le meilleur et maintenant tu ne fais pas MIA ou tu fais pas ok maintenant avec l'infrastructure de la MIA c'est exactement ce qu'il a dit que parfois les containers sont pinc ils répondent à la personne qui pique cette personne n'est pas pour les emails je veux dire le système n'a pas vraiment aidé donc tu peux ajouter dans les goals ou dans les choses que quelqu'un doit réduire l'infrastructure de la MIA et juste pour dire quelque chose maintenant RT n'est pas public anymore par la DSA je crois que c'est une bonne idée RT donc on peut commencer à bouger l'infrastructure de la MIA c'est justement public pour tous les développeurs de la MIA mais la MIA c'est très bien pour tous les développeurs de la MIA donc j'ai une question pour ceux qui n'ont pas été investis en QA pourquoi tu es venu et qu'est-ce que tu veux être investi dans la team de QA ou si c'est expérimentable je veux être involvementé mais ne prendre pas beaucoup de responsabilités j'aime avoir une façon dont je pouvais marcher en batch entre si mon currently marcher et aller dans la paix c'est moins possible d'avoir 2 ou 3 heures de fixation mais c'est plus facile d'avoir des choses comme ça quand les gens vous invitent Hey, on va faire un batch fixation à ce moment je ne sais pas que ça peut aider mais je ne vais pas faire des meetings c'est vrai que le problème que nous avons dans la team de QA c'est que des nouvelles personnes avec toutes les parts de la team il n'y a pas beaucoup à faire si tu veux juste aider pour 1 ou 2 heures dans la team de WN Games nous avons commencé à avoir des meetings et ça a augmenté l'activité de l'activité de la team peut-être que ça peut être appliqué à la team de QA oui on pourrait essayer ça vous voulez organiser ça ? ok, bien je pense que par rapport à la question pourquoi vous venez ici ? les gens de l'IRC disant qu'il est de l'Argentine et qu'il veut aussi rejoindre Lisandro et c'est assez le même pour moi c'est juste une curiosité et je pense qu'il y a je pense que nous sommes de temps non ? juste quelques questions qui est intéressé en faisant un UDD plus tard cette semaine parce que nous pouvons either run it officially or unofficially ok, so it seems unofficially is fine as some people interested in doing an archive rebuild archive testing both, why would demo the scripts to get you involved ok ok, ok so we'll try to schedule something something else ok, thank you for coming