 Quarter past five. Everyone ready? Good, so yeah. Like each year, welcome. Thanks for coming. The annual package poll meeting. Maybe someone could close the door. I hope that there are also people following on the stream, at least that was the idea. So for those at home, we could do a usual introduction for those who want to say their name and wave into the camera. So that others also know who are here. I'm Gregor. I'm Sothore. I'm Dominic. I'm Lucas Canachiro. I'm Rhonda. I'm Christian. I'm David Bremner. I'm Climo Nardens. I'm Intrin. And I'm Nico. So this was the quickest introduction I've ever had, but I have a surprise, which is not in the agenda. So last year was the first time that Lucas was here in this box and he was in the group, like I don't know, six months or so. Already very active and you have been totally active across the whole year and since some days you are a deaf and developer. So I think that's a reason to congratulate you. And I have a small gift, which was donated by Medak. And I thought it might be nice to give this to the newest DD in the group. Thank you. Okay. So this agenda is mostly copied from last year. But I've listed here is the topic of sprints, which we had and which we might want to have again, the low hanging fruit sessions, the status of the team as a team, maybe Perl 524, which is an important topic for the group. And well, some other issues where I might have some ideas or others also might have some new things to bring up. Is this something we want to go with? Is there something important missing? Is the order okay, some? Yeah. Good. Go ahead. So yeah, I don't know, sprints. There was one sprint in Türich at the end of May. Does someone want to give a quick improvised summary? It was attended by six people in the end. Hands up if you're at the sprint. And missing from the room are Alex and Axel. Alex has, well, we've drafted a report which has now gone, I think, to the, somewhere, the sprint mailing list and the team mailing list. And I guess there's a little bit more to do is publicizing that. I think Alex is going to do a bit spent entry, but. So from my side, we worked on Perl 524 and QA rebuilds as a kind of parallel topic. So that was a good, good progress there. I just want to mention what they worked on. I guess read the report. Yeah. Fix some bugs and stuff. Yeah, maybe the new server is something to mention. Sorry, set up an instance of Debomatic. Well, with Nico's help to rebuild packages, mainly for the Perl 5.24 transition. Which is working pretty well. Although the web interface to it is not scaling the number of packages we're using it for now. So if we want to carry on using that, we need to address that. Yeah, but it's, sorry. It's rebuilding packages continuously for 524. So there's a repository of rebuild packages which was the main aim for the thing. So it should be easier to test 524 than it's been in the past. Yeah, because the packages were available before, but only not only processed when I remembered. So that's good. So I guess, well, that's moving into Perl 2524. Okay. So we can publicly thank the University of the Edgenössische Technische Hochschule Zürich and our sponsors. Yeah, thank you. It has worked out quite well. Okay, so during that camp, there was also a kind of a sprint. So there were four people already present, entry, David, Silvatore and me. I think we met four times for coordination meetings. And worked on, well, tools like DH McPearl, package Perl tools. Entry reduced the number of unreproducible builds to almost zero. And there's a draft report which I should probably send out at some point. I was waiting for feedback so far and then forgot about it. Yeah, I don't know, do you even want to add something about that camp? That's something about that camp. When Deb Cherry using repository, so it no longer made Gregor sad. That was my big accomplishment. Keeping Gregor happy is an important goal. Okay, so that was the second sprint of this year. I mean, kind of that camp. So I put here the question next year, question mark. Maybe we can get the quick round of feelings. Do we want to have a dedicated sprint again? I felt that generally the sprint was very productive. We didn't have any, well, we had some big topics. But also quite a lot of general collaboration on sort of smaller kind of ongoing tasks. So I definitely support having another one if my main concern, if there was one, would be getting more different people involved in that process. And I'm not sure the best way of doing that is, but. Yeah, very much agreed. So as long as there are people coming to the sprint, I think we should have one yearly or something like that. And the timing seems to be quite good in May or so because there's a new parallel upstream release is coming out in May. So it's good for preparations and all. Okay, so we might want to note down that we are targeting May 2017 for a sprint. The question of getting more people or the varsity of people is a good one, I think. Do we have ideas on how to involve more people? So Alison suggests having an event at YAPSY, which is where? Geographical? YAPSY, YAPSY and A just ended, but YAPSY EU should be coming up? I think if I remember correctly, we had this discussion before of having the sprint in parallel to some conference and we said that we'd rather have it separate because it's easier to focus to work. Like Debian packaging training session at YAPSY and a little bit of recruiting effort. Because you have pearl people who don't know anything at all about Debian that might be a good sort of place to pull people in more than Debian people who don't know anything about pearl, I think. Right, YAPSY is for recruiting new members. As far as I know, Alex Montata is giving a talk at this year's YAPSY EU about Pearl upstream and distributions. So you could also have a sprint around, I mean, not in parallel with the conference, but before or after, I mean, Debian camp style. Yeah. I mean, then it's not so distracting. Yeah, I guess we could keep that in mind and see when Debian Conf is next year and when YAPSY EU is next year. Or YAPSY in theory, but practice most of us in Europe. So YAPSY is normally three days, is that right? So three plus two is kind of weak. It's a manageable length. So knowledge junkie reports on IRC that YAPSY this year is in Cluj, Transylvania. So that's a cool place to go. Okay, anything else on sprint? I shall remove one. Okay, low hanging fruit sessions. So this was the second year where we had those monthly meetings on IRC with the idea that people meet at the same time to squash some simple but maybe tedious or boring issues together or at least in parallel. This year we were, so I looked a bit at the report. So this year it was at the 21st of each month at 18 UTC, eight of the 10 planned meetings actually happen. Two were canceled, one because most of us were at the sprint in Zurich. And the last one was just before that camp and I think there was nobody. Okay, so some statistics on average there were six and a quarter people which also includes people who said hi during this time. In total 14 unique persons over these eight meetings which attended between one and eight times. The only one with eight times is Nico. And each of those 14 persons participated well three and a half time on average. And the topics were well mostly packaging like getting new upstream releases packaged, fixing auto package test failures working on RC bugs. But we also had some discussions around 522 transition or the aftermath and cleaning up. Sprint planning, where do we sleep in Zurich? Yeah, about how to handle some bugs about hardening flags, we had one discussion. Okay, so that's my looking back. I don't know if others have some comments on the past year. Was this useful? Was it fun? Was it, I don't know, distracting or difficult? At first I found it useful to have a certain time for online discussions, real time discussions but I didn't really do much, much of actual work on those. But yeah, I guess it's sort of borderline whether it actually worked. I mean, there were very few people generally, people present generally, but yeah. I guess we could go on with those for the next year. Yeah, I kind of agree with the kind of varying amount of activity, but the cost of them is quite low and I think even if it's just talking to each other it's a useful time to do that and in a slightly more coordinated way. I support continuing them. Okay, so this summary, it's not clear if it's a huge success but also the costs are so low that it's worth going on and having this coordination meeting maybe. So it's not the only reason I didn't participate. I was also very busy and so on but the timing is not very good or was not very good for North American time zones. So I would say, I think we had this discussion before and I said you should do what works for the group who are really doing work but anyway, that's an excuse for me not to participate. So to come back to last year's discussions, in the year before we alternated between two different times on each second month and the result was that the European friendly time attracted way more people than the America's friendly time which didn't really work out. So this year we tried it with only having one time but of course that's the question if we continue then which time do we pick? If we stay with the 21st which is just arbitrary but why not? Then it's still, do we want this time? Do we want to have a different time or do we want to have some time changes or alternations again? I mean I'm not sure how much time we had today but I suggest we discuss that on a mailing list or something, the timing. I mean we could do voting here but not everybody's here anyway so. Yeah? I guess I just volunteered so. Yeah, I'll try. Okay, cool. Good, team status. Oh, cool, comparing to last year, who was that? Merci. Okay so we have this script committer stats and I ran it some hours ago and it, well it checks the amount of commits per person in the last 365 days in all our packages. Repos, which were 56 persons. Where's that 58 last year? Okay. And there were 14 people who had more than 100 commits in this time frame, where's that 11? Okay, so it's a rise in the more active people and more or less the same in the overall number of committers. I mean there were years when it was more like 70 people but at least it's constant compared to last year. Yeah, I guess there's not much more to say about this. The other thing is we have a to-do item on our open task page since I don't know 2011 or something that's about pinging members or pinging inactive members which Ansgar did once and I don't know how. And since then we are waiting for someone to provide some tooling and since when was it? Wednesday, something. We have a script. We as in the package Ruby Express team. Thanks to Christian and thanks to you for making it universally usable. So I wrote a very small wrapper to pass our team name and repository file path. So we can run this script now on Alioth which outputs a CSV file of the accounts of project members on Alioth who have not touched any file in the last two years I think is the cut-off where the outcome is something like 207 minus three lines headers or so. So 200 of the, I don't know, 270 or whatever members we have seem to have not touched any file in two years. Toby, that's an excellent idea. We are not so far yet to do anything with it but yeah, maybe we should. So next step which are possible is to send a mail with some mail merge thingy. David has already committed a Python script that does the mail merge. And I started to draft the text for the mail which we will at some point finish and write, put it into YAML so that the Python script can read the CSV. So it's worth pointing out that there's many reasons people are on this list. There's a lot of dash guest accounts where people now have DD accounts. Lucas for example, but many others. So it's not necessarily that there's 200 MIA people here. There's just Alioth accounting sloppiness basically. So that specific case should be filtered out, right? That's easy to filter out or not? People don't necessarily have the same account names. But it's not such a big list that you can't look for obvious duplicates if you've got their real names. I mean, the question is a bit about their objectives. I would also like to remove those guest accounts which are not used anymore. And it's a question of the wording of the mail. So I tried in my first draft to make it very clear that this is about this account has not been used for this purpose. And it's not about you are inactive or something. I mean, my first reaction when I saw the list was also a bit like, wow, really all these people and I know some of them. But I'm not sure it leads anywhere to go through the list manually and think, oh, does this person have a different account or do I know them and do I want to talk to them before sending them a mail? So that's a one year cut off. Is it? Two years. Okay, that's better. It makes more sense. But for the people who became DD stripping of the guest and checking that cross should be fairly easy and scriptable. Yeah, but the problem is that the black guest and blood don't necessarily match. Yeah, yeah, but you still can read out at least a few of them. Yes, but then I would still like to remove the guest account from the project. Yeah. I think the idea there is that you do that before sending the mail. So you send less males. And just remove the guest account. Well, some people might still be using that guest account because they are too lazy to update their.ssh config. Well, after two years. Okay, another thing to consider. Yeah, right. Okay, we're getting into bike shedding. Since somehow it took me three days so far not to do this, probably we shouldn't complicate it any further. Okay, so I mean the general question is, is it okay to do this? Does it make sense? Is it a good idea? And is it okay for you if David and me try to get this finished before leaving Cape Town? Okay. Okay, so thanks again, Christian. And you get back a mail template in perfect English. Good. So maybe something more technical. 12.5.24, is there something we need to know to do? Well, it was announced that we're transitioning for stretch, so that's good. So, I think we're in reasonably good shape for the transition at this point. The wiki page that's on Gobi has a status. Do you wanna talk about the specific? Yeah, well, this, we piled, I'm not sure how many there are, less than a hundred bucks, but 5.24 transition probably on the other 50 or something. And I think there are no, well, the best blocker I think is data alias, which I yesterday mailed the upstream authors, Jeff from about, and then there's net SNMP, but that should be trivial to fix. And so, yeah, I think it's, as long as we can do something about data alias, I think we should be fine. So, right now there are eight bugs, eight fail to build bugs, which is actually pretty good compared to last year in terms of... Are you counting all the forwarded ones as well? Those are all forwarded. Yeah, there should be something like eight important bugs. So, data alias algorithm permute, net SNMP, develop begin, lift, let's go underscore net SNPP, parse, HTTP user agent, text, sprint, FN. So, basically I think we should probably file a transition bug for the release team this week and then look at the blockers and look at what we can do about those. And I guess that would make it for naming August or something like that. Yeah, I mean, on the packaging side, I don't think there's anything outstanding to do with, I mean, the upload is the packages in experimental, it's working as far as we know. So, it's really, so it's just, as you say, dealing with those two widely used packages. Well, okay, sounds like a nice transition. So, you're going to file the transition bug and then, yeah, maybe announce a timeframe or whatever help is needed. Okay, so, this is now a collection of other miscellaneous topics. Starting at the bottom, this was something that Salvatore mentioned today in the release team talk. How do we go along with uploads during the upcoming freeze? So, in the past, there have been different strategies from going ahead with uploads except for very important packages. During the last freeze, we really didn't upload anything, I think, except for some mistakes, maybe. So, I guess, basically, we haven't doubled, we don't have uploaded much during the last freeze and then, we had a huge pile of new upstream version and it was, I guess, quite hard to bring that down again. So, I just put the question, what we do, maybe upload to experimental or go on with uploading modules without C code or, yes, I don't know what. Can someone articulate the downsides of uploading to experimental? So, if we upload a thousand packages to experimental? Well, it's basically useless because then, someone has to manually upload all of them to unstable data. Could be scripted. Yeah, and also, the packages are not going to get tested against each other that way. So, it's just an overlay for unstable. So, they're all sort of individual there. Yeah, I guess I don't have a good answer to that either, but I'd rather air on the side of not uploading them than making trouble for the release because we've created something in unstable that can't transition to testing, blocking something. I mean, we don't have to decide on a fixed policy. I mean, I can think, we can rely on uploaders to exercise their judgment about what's appropriate to upload to unstable during the freeze just as they would for other packages. So, there might be a higher bar to uploading some types of changes, but I think in general it's, you can kind of judge that on a case-by-case basis. Leap packages in general are fine, right? Yeah. And lots of our packages, not all of them, obviously, but lots are leap packages. So, it's use your judgment, be careful and air on the safe side as rough guidelines. Good. Yeah, the other two points here were, well ideas that Christian and me had at some pub meetings. So, the second one, language packaging skills exchange, we found that we were sitting besides each other and talking like, do you have a tool in the Ruby group and a Perl group for doing this and that and thought maybe we should do it during the day instead of at the pub. So, the idea is that to have a buff, probably, it's called, where the purpose is not to come up with some big guidelines and grants, teams that all teams must change and follow and whatever, but just to sit down and show tools to each other. I think it's a good idea. I wanted to mention that Sean Whitten has basically forked DH make Perl to work on Emacs packages. So, there's a direct connection there. So, this kind of cross-pollimation is interesting, I think. Okay, so, no one thinks that's completely insane. So, I guess we too can file the, can request the buff with the content team. Yeah, maybe then you can also spread the word or if you have ideas who to invite from other language packaging teams. Like, I don't know, fighting guys maybe would also be interesting. Okay, another issue which I titled now self-watching, the Perl packages. Well, that's a bit me becoming grumpy sometimes. So, last week I NMU'd two or three Perl packages which are not maintained by us for using that help for something and I realized that I didn't even have to download the source package because the last upload was also an NMU done by me last year for 522 and I think it's a bit silly to do it this way and I think either we or I, whoever wants to participate should just move those packages into the team, keeping the maintainers upload and inviting them and whatever, but just maintain them properly instead of doing this continuous NMU dance. And if there's some broader consensus we maybe should as well announce this somewhere be that the lightning talk, I don't know. We have a process for dealing with inactive maintainers already, I'm not sure that we need a separate process, we might need to invoke it more aggressively but adopting packages if they're inactive can happen but I wouldn't want to try and sidestep the existing I'd say policy or for that. Yeah, my thoughts also. So we should rather go for getting the packages offered first or something like that I think or at least do the MIA process in parallel or something. So that it doesn't happen that they're being MIA goes unnoticed because we took over their packages or something. Yeah, doing this in parallel sounds good. Waiting for the MIA team to really orphan the package is something I'd like to avoid because then I'm waiting again. With the current MIA process, my understanding is if even if you start to process by mailing the MIA team you will not get a reply. So you will not know what the status is. The first part of the process is to contact the maintainer and we haven't think we haven't proactively been doing that before. So the first thing to do be identify the set of packages that we think we're talking about and then contact those people, right? You can always contact the MIA team. So I'm in the MIA team since maybe a few weeks. And so feel free to contact us. We have more streamlined process now. I think has been also a result of earlier depth comp and we are lately following up a lots of people which were not triggered and just give us a note forward write a mail to MIA at qa.divian.org and we take a look at this. You can also log on on qa.divian.org and take a look in the database if that one is already recorded and sometimes the list in that one is quite long so it's quite evident that you can just NMU that one and but in parallel we should to avoid pissing off people follow the process here. And I think in total from reports to forced retirement let's say that way it's not more than nine months and until you get the packages all formed I think it's two or three months maximum. So and in that time you can just NMU that one and if that maintainer did an upload maybe five years ago yeah go for NMU zero day. You won't care probably. So I just wanted to remark that you said we weren't really contacting people proactively but NMUing somebody's package counts as contacting them. If they don't notice that that's not really our fault. I mean if you don't notice your package being NMUed that's not that somebody's not trying to communicate with you. I mean it's that you're not interested in the pie or you know you have other things you're not able to respond or whatever but. Sorry but for the record that's something that's changed in the past 10 years in Debbie and so it's now considered perfectly acceptable to make your NMU submission the means by which you communicate with someone who seems to be MIA. Yeah that's fine. Yeah sure that's not the part I'm having issues with. I don't hesitate to do any NMUs. So I'm more taking it to the next level and lowering these boundaries of maintainership actually. I mean of records maybe but. So okay so we just need a sense of what the scale of this is and do you have any, do you have a list of packages at this stage or maintainers that this would apply to? Not really I can look in my NMUs directory. So it sounds like we should write some scripts and then write some scripts to email those nice people in the MIA team or maybe semi-manually but yeah. That's just a task that should happen. Well I have a fine Python script that I can let you use. Maybe we can write a Ruby script to get the CSV to feed into the Python script. I think we should really try to work Node.js in to show that we're hip. We've done that with the debumatic web interface. Okay so it seems we have to look into this a bit more before having a clear group consensus as a group policy and we have to think about this, getting to MIA earlier, finding these people who we should. Okay. I think there's consensus of aggressively mailing MIA of parole related packages, am I wrong? Okay so that's a start. I would just say let's avoid having a policy that's team specific if we can in general actually but particularly in this case where. I'd like to join there and say on the Ruby extra stream we see similar issues obviously. So your policy would not be team specific but maybe it works for larger teams. It's more practice than policy but yeah. Okay good. So and now we have two minutes left and we are more or less at the end. I mean there's this link to our standing open tasks page which is a placeholder for we can now use the last two minutes to discuss any other issues, topics which someone might have in mind. We don't need to talk about this here but I could use some advice and it's not a package that you maintain but it's somewhat loosely related and that is I'm notionally the maintainer for the parrot package which I built up a team who took over maintainer ship but they were mostly interested in Rikudo so when they shifted to the more VM from parrot they stopped maintaining the parrot package it hasn't been updated in two years. There have been continuing releases of parrot. I don't know how valuable they are to anybody. I don't know that anybody's actually using it. I'm wondering whether I should remove it or update it but it doesn't have to be discussed here just if anyone's interested I would appreciate advice. Good. Anything else? Nothing on IOC? Ah, Christian. I have a small interest in the actual pearl package in the sense that I'm one of the commenters of the Ruby package and it appears that our teams work a bit similar in that the interpreter itself is not part or is not managed by the same team where that manages the libraries and I was wondering why that is in the pearl team. Because we're very happy with the job that Domenico are doing with pearl I think. Yeah I guess it's mainly any help is welcome so so if somebody's interested yeah we'll happily accept contributors and team members and all. So I have one comment from IRC. Knowledge Junkie wants to relay his thanks to the team for help, advice and tips over the last year. Yeah and thanks to Nick for all his work. And thanks right back at you. Good. Shall we wrap up? Call it a session. Okay then thanks for coming, for relaying, for typing. Thank you for cherry. Thanks to the video team and to the Mia team. Yeah well trust me. And UTC and... It's just a Tornoska's thing. UCT or UCT? UCT yeah. Oh the time zone is here. And see you at lunch and dinner. Dinner, the other one right. What dinner? It's just you and UTC.