 Welcome, everybody. I'm very happy to have yet another pearl buff at the depth convent. I'm happy to see so many faces here, some of which I know for quite some time, some of which I know for only some days. Yeah, I'm Klego as you probably know or have guessed from the description or something. We have prepared over the last days some kind of agenda which is now projected on the screen. As usual I would like to start with a very short introduction round so that we all know each other and that also the people who are following along over the video stream can match the faces to the names so everyone who feels like it might want to say the name and half a sentence where they are here or something like that. Salvadori, can you begin please if you want to? Yes, you have that already my name, my name is Salvadori and I'm in the package pearl group So I'm used to the packaging helping out with things in the last year with less but still active. My name is Dominic Cargreaves or Dom and I maintain some pearl modules inside and outside the group and I also can maintain the pearl interpreter package. Yeah, I'm Nico Tuni and I used to do a bit more work with the package pearl but nowadays I mostly maintain pearl itself. I'm Jonas and I'm part of the pearl scene and a bunch of other things. Nowadays mainly I package the RDF related pearl packages and some move things but anything that is dependent to that. So I'm David, I'm also on the team although I think the amount of packaging I do these days is quite small. I guess I have a standing offer as team Git consultant so that's my excuse. I think we have a noise back coupling group. I'm Axel Beckert, I'm in the pearl team for I don't know four years maybe, not that very active but usually present in the IRC channel. Yeah, well occasional bug fixing and reporting. Hi, I'm Florian my IRC nick is FSFS. I joined the pearl team like two years ago and it was also my entrance to Debian development and half a year ago I was lucky to become a developer and that I'm very happy about so this is my first step to say hello to everybody and get to know you. Hello, I'm Intergeri, I'm a team member for a while and I mainly maintain GTK and GNOME packages and try to do some more generic team work sometimes too. I'm Tamas, I'm quite new to the team. I became interested when I saw that one of the packages, the module resource package which I'm interested in was a bit out of date. I went to the newer one. Okay, thank you. So before we really start the technical aspect, who's writing to take notes and send nice minutes afterwards and who is monitoring IRC? Okay, cool. I'd be happy to take notes along with someone else and Gobi. Okay, so someone else helping out in, okay, thanks. Bienvenidos. Okay, so the first point we have here, I'm just going from the top down if someone wants to change the order please just say so. There has been this Lancaster consensus paper written, I'm not sure, some months ago by Pearl upstream tool chain gang as they call themselves where they tried to, well, write down some current and future ideas for Pearl distributions and I thought it would be interesting to have a short look at it to see if there's something relevant in it for us as a group, as a downstream and Intree has already taken a look at it and added it to Gobi. So I guess it's the quickest thing if you just run us through it quickly. Looks fancy. Okay, Intree, would you mind walking us through the Lancaster consensus quickly? Okay. Yeah, point one and let's try to improvise. Part one was the minimum supported Pearl version which is 581 according to them now so we don't have to care for it since even old stable has 5101. Then there was some ideas about specifying pure Pearl builds without compiled XS stuff which we probably also don't care about since we can compile stuff on all architectures. The next one is probably the most interesting for us. It was about clarifying some of those environment variables which are used in the test suites, the meaning and who should use which one. My understanding is that the results are quite similar to what we already have in our team policy where we, I don't know, two years ago wrote down that we want to set this automated testing variable because this is supposed to be used for tests which run automatically and that we don't want to use the variables that are meant to be run only by the author at release time which is either release testing or author testing or something like that. What's new in this Lancaster consensus is a variable called extended testing which as far as I understood it is supposed to be used for tests that may take extra time or extra resources and where we might want to discuss if we want to set this always most of the time or not whatever. It sounds to me that this is better bounced off to as you're also mentioned here in parenthesis bounced off to CDPS and DEPAPO since we always use either CDPS or DEPAPO in the Pearl team. So it's just telling informing these teams one of them being me that what it is, what makes sense, these groupings that Lancaster has done, it sounds very sensible and it sounds actually more well structured than most of the other areas in Debian is doing. So this could be a perfect invitation for more tools to hook on to this. I know from the JavaScript team that it would be lovely to, if we had a hook, if we had a way to express, this takes a long time to do regression testing of then we could include, wrap it inside a hint so that it's only done for these testers, test machines instead of the standard builds. And I know that Doku is interested in exactly the same about when he's compiling for slow architectures then he wants to skip some parts and if we couldn't tell DEPAPO and CDPS this is the kind of grouping that makes sense to do in Pearl. It might very well make sense to the whole of Debian. Do you mean that DEPAPO and CDPS should just set the variable or something more sophisticated because I said hook in? I mean that the thing that we, but extended testing sounds to me like this is something we shouldn't set always in Debian because it's the kind of thing that will kill smaller architectures. So it's the kind of thing that we actively try to avoid in other places. So if there is something that is extreme testing in the Pearl modules we shouldn't set this flag here as I see it. But maybe I'm just assuming that there are things that are obvious here that isn't so obvious after all. Well I think all three variables should be set by both tools by default and then there should be a way for the maintainer to override this and say no for this package I don't want the extended tests after experience. I'm thinking of even pushing it further out to the build options or something like that because I don't think DEPAPO or CDPS is the place for that kind of heuristics. I would actually expect even build team maintainers to set it globally for their abilities. Jonas? I think I'm lousy at expressing myself. I don't disagree with you. I just see it as the Pearl upstream has formulated some very distinct variables for these things. And in other areas of other kinds of code it is more up in the air how to express is this very extensive testing or is it simple testing or is it whatever it is for what purpose testing is it. And these groupings is very sensible in Debian. We cannot just say that the build these should set these flags because then build these should set flags for Pearl specific things and for JavaScript specific things and a hell of a lot of different things. The point of these Debian specific flags is that it is then up to each team or to each area to then tie the build specific flags to the package specific flags. That also didn't make any sense I think. So if I can try and interpret for Jonas. So you seem to propose some kind of project wide standard ish like thing for these testing environment variables. So maybe we can just try and follow up with that with a few of the people who are interested in the testing like the auto testing and so forth. I don't know who he is Jonas maybe you. Me Joey whoever is working on auto testing could be Holger and then Doko or someone whatever someone who is into the build the stuff some few people sit down. I just don't see a it seems very nicely wrapped together in Pearl area. We don't even need to discuss that I think and then we just bounce it off to this higher level Debian high level and then we go back here when the high level Debian folks have figured out something that is cool for all of Debian and link those two together. Does that make sense. Okay that means we don't do anything specific now besides what we have been doing you try to get some people together and then tell us if this affects the Pearl group in some way. Cool. Thank you. Okay trying to quickly go to the other things something about the build PLL spec which should not affect us. This install distributions database I have to admit that I don't really understand it completely what this is about. Has someone else read the proposal or whoever added this purple comment seemed to have read it. It's two comments actually known. The second one is by me but I was wondering what this is actually for and how this should interface with what we're doing anyway. I was thinking of pack lists which we're currently deleting from the power package I believe and well because of duplicating information which we usually manage with the DPKG and because it's putting stuff in locations where we don't want to have it I think. So I think we should wait and see how this is going to be implemented and and yeah how we perhaps can make our tools work with this but unless we know more exactly what's happening I don't think we can do anything. Yeah it reads inventory of install distributions uninstalled tools and tracking of dependency graphs I mean actually we have the package and app and whatever. Well the way this could be used is when a power module isn't packaged and I use C plan plus or something to install it locally in my own home and want to manage those locally user installed modules but then the tool would need to know that there's some distributions it can uninstall and others which it can't even though they're there and stuff so I'm not sure it depends a lot on how this turns out to work. Right in the last sentences implementations details are left to the one implementing it so we probably have to wait anyway. There are some ideas about post installation testing which are interesting because there's also discussion about this auto package test and depth aid and there was just this talk about the Ubuntu testing and someone already wrote here if this existed would be useful to use it but I guess if I remember correctly it also says the implementations are details are left to the one implementing it so we probably have to wait for it and keep our eyes open and then try to make use of it. Does this sound? The pink stuff there's again me and I wanted to ask if I've understood this correctly that it's really just about running the usual package tests again the build time tests again after a separate module another module was installed to make sure my package keeps working so the result would be the same as the archive white rebuilds. Is that correct? Is that everybody's understanding? Yes I suppose it would be the same yes but it's kind of a more continuous process where you can keep on testing that maybe a bit more easily. I was thinking that it would be kind of easy probably for most bare modules anyway to implement this test installed target or whatever because well it's basically just running proven on the test suite without the dash B option something like that. So it might be quite easy for us to implement auto package tests for just about all of our packages I'm not sure somebody should look into that. Yeah I also thought about this that might be a nice mass commit just dropping this devian tests control somewhere. Relate to this auto rebuilding the whole archive still only tests with the least possible build dependencies satisfied and what we I seem to see as being the goal of this is covering the situation where they all have too much so bloated systems and that is a kind of test that is not done with the devian at the moment. But is that really an issue for us because on the belties you also have the least. I don't see this as being an issue for us I see this as being what I what I as I read this this suggestion is a mechanism so that people who are using devian people who are using different kind of distributions can is can hook into this and do these tests on a system. So it's somehow making the test available after you have installed and then those testing it could then do bloated systems in different ways. So it's a different kind of testing vector that we would allow for others to do and for ourselves. Those others could be our testers those doing these system tests runtime tests. It could be a valid way to do runtime tests also in devian doing bloated tests something we don't do it now. So I guess there are there are two things that this could be useful. One is hooking directly into the auto package test which is designed for well mainly automated testing within devian and then they're separately is giving users the ability to run those tests. I mean they're related but I'd like to see if we did enable auto package tests in per modules that they'd be that it be done in harmony with this. So I mean it would be probably better to again unfortunately wait and see what or even you know help contribute. I had a side note are we somebody or are we planning to respond in some way to or get involved in a discussion general discussions about the consensus the Lancaster consensus. Do we know who do we have contacts with the people that wrote it at the moment. Anybody involved there anybody in contact. Okay so conclusion again is yes makes sense but let's wait so that we can fit it together and not invent something on the thread. Okay yeah I think that was more or less okay for the meta file specification there are some ideas about improving the conflict field which we might then use in DH make Pearl maybe sounds reasonable. Yeah and the rest is about about the C-Pen and pause about permissions names for distributions and stuff like that which should not affect us except as users who may maybe profit by some improvements. Okay so is this enough the Lancaster consensus. Want to say something? Good luckily we have our Git expert here so maybe he can start with the next point. The idea was just we switched from SWN to Git two years ago two years is a nice time span so we might want to use some minutes for just sharing exchanges exchanging how we feel about it if there are some some problems we have or if there are some corners where we could improve our workflows or we can also just say we are everybody happy and go to the next point it's an offer. Yeah I think I didn't have much to do with the actual workflow which is mainly MR right so whoever set up the MR rules and and so on but I think it's worth just maybe anybody who has a particular pet peeve that that they want to ask about it depends whether you think it's a let's just say anybody who has a something that's annoying them about the team workflow I'll pass the mic to them Jonas. I hope it's also okay if I'm not annoyed I was more the opposite asking is anybody annoyed that I have started adding the upstream GITs into the things I find it pretty cool to have synchronization with upstream GITs and but I it it bloated the RIC channel but some cool people then fix the these hooks so other than that is anybody okay you're in favor I usually do that with my own packages outside the although I don't automatically sync it I don't find that too useful but I do often keep upstream history as a branch in the packaging repo so I think as a general principle it's a good thing. What I do is is that every time they have a release and they have a corresponding release tag then I link the release tag so that in practice that will build packets our current general structure that means that it's all getting pulled in but it's tied together these two threads every time there's a release and I contact upstream and remind them if they forgot to tag their upstream releases and they thank me for that a couple of times. So um go ahead another thing uh generally I don't like the system where the where the master branch doesn't have the patches applied so that's kind of a pet peeve of mine but I always forget to actually apply them when I'm testing something or so but I don't really have a good solution we're using GIT DPM for Perl itself there was a presentation on that this morning but it might be a bit too complex for this group I mean there's lots of newcomers every now and then I think was it to us all very who said that it's kind of a dangerously sharp instrument or something like that so yeah. Yeah um so maybe I'm happy to sit down and and play a bit with patches applied versus patches not applied in our current workflow maybe while I'm at Deppconf and it might not be such a big change for us so that's something we can think about it's something I've been thinking about in other contexts as well so shall we move on then? Yeah okay so the summary is maybe someone has a more concrete idea can around patches and then we can discuss it again right? Yeah I think I volunteered to at least try and examine the current situation and what it would mean for us to change to have patches applied in our current workflow. That's great to me and Jonas could you please document how you pull in the upstream GIT revisions on our website in the GIT workflow? Yeah please. Even better send down a script to include in our tools to do this. Okay I guess at least I what experience I have with Mojolicious the upstream GIT repository is there needs some work to make the release actually happen and that's what they do when they produce the tarbols so maybe something more really that I'm not sure I understand the question so are you saying you don't know how to work with upstream history or it doesn't build right away or no but I'm saying that in the release process when they produce the tarbols there is some kind of extra steps involved which need to be included when building the per package for the beyond or producing the package. I think what you're wondering is if we might lose some information by syncing with upstream instead of using tarbols is that what you're talking about that we are missing something that upstream is doing that we're so for the people watching and didn't see into Jerry's laptop he points out an option to GIT import a ridge which is in the GIT build package suite. Intriguery just took over the job because you already answered the thing that there should be passed on to them. There's no more this is the thing I do I don't do anything more. One more thing I do is I do both you both tag the upstream GIT tag and the upstream tarbol both of them at the same time that's very important. Okay maybe we just one addition actually the same discussion came up on DEPCON discuss on the mailing list in the GIT build package thread and I explained how that works in a little bit more detail just without the actual command because I didn't had that in mind so there's also GIT build package workshop or boss somewhere sometime. Which wiki page? Which wiki page? Yeah okay well I actually I have some thing which I think is missing in the on the GIT GIT how to because MR is only mentioned in the working with existing packages but not in the starting a new package and the addition of the new package to our global MR config it seems missing there. It's run but it is alias script. Oh okay so I don't have to do anything there. Ah then maybe that should be maybe that's the missing piece here. Um yeah okay so the next comment would have been that DH make perl may be need to do that but that's never not needed anymore. Okay it's one minute past four so let's continue. Debian maintainers there is this nice category of Debian maintainers the people who have upload rights for specific packages when this was introduced some I don't know six years ago whatever some sharp mind realized that this does not work for teams because at this time there was no relationship between there's no one-to-one relationship between person and package just some general allowing and allowing everyone. So we said at this time no we we're not using this concept in the Debian Perl group. Now Ansgar has fixed this Debian maintainers thing Ansgar in his capacity of FTP team member so in theory it might be possible to use it now. I just thought we should take a short look at it if this change in the implementation changes anything for us if we want to revisit our decision from back then or if we are still fine with not using DM at all. So can I ask if there's any Debian maintainers here who would like to have upload rights on some packages and that this would somehow make life better for you or for the team? Right I guess I volunteered to forward those remarks too didn't I? Ansgar says there are some packages that have DM set and my addition to that is that that's a bug currently I mean we could change the team policy then it would stop being a bug but I guess I'm not sure what problem we're would be trying to solve by by starting to use DM permissions on individual packages but I guess it doesn't seem like it would create a crisis either. Yeah correct from the people who are attending this meeting but maybe just say that the next step to do in that area is drop a mail to the Perl team mailing list and say if anybody responds to that and if no one knows then that's the answer to the question. Well we could also say we wait for people who think they might profit from it to just raise their hand. Could someone just summarize what the change is and what the proposal is that we would would happen for the package Perl group? So the change is that the Debian maintainer permissions are now managed in a more or less same way in the sense that there's a database which keeps pairs of maintainer package in it. Previously any package in which you were in the uploaders and had the DM upload okay set you could upload but we generally have been using the uploaders field more as a way of tracking who is interested in a package so it would have required changing that. That's my, that seemed like a fair summary? Yeah. Do we care about this database as a group? Because if Debian developer decides that this package can be maintained but this person that's something that the Debian developer decides anyway so he can allow this and we are done with the thing. What's here the group to decide? It seems a little bit uncollaborative for individuals to decide who can upload the team's packages without any consensus in the team or I mean I don't know it's necessarily like I say it's not a big crisis but it's odd for somebody say who's not in the team and doesn't interact to say well you know this package you can upload it. So maybe just drop a mail are you fine with me giving this permission? Yeah sure we could develop the mechanism if we think we want to somehow support it. Yeah let's wait until it's a problem we're spending already a lot of time and we have no one raising the issue as being a problem so let's kill it here. Okay so let's keep the sentence in policy we don't use it as a group which is still true and if the question arises yeah fine okay low hanging fruits meetings was an idea in three. So this proposal results from quite interesting experience in other projects about having low hanging fruit sessions as a way mainly to get newcomers feel welcome and find ways to help and also to well clean up our plates by getting ready together of easy things that we can kill in a lot at a time in a small amount of time which helps getting the backlog short and so I propose we well we could try to have this like every two months or something like that or at least try it once and see how it goes I'm happy to organize some some appointment and suggested tasks. Um real life meetings or IRC meetings? IRC okay. Yeah I mean it already happens on IRC every day but well for those who are not on IRC so much it makes sense to have some agreed upon time when we can meet and and publicly welcome new contributors say hey at this specific time we'll be available to help you. I think there's a consensus to do that. Okay so great idea. Next action you propose the first meeting or something like this? I will. Cool thanks. Okay then well actually I'd like to change the order a bit so that we don't skip the Pearl 518 migration which is kind of important. I thought it might be nice if you could just in some sentences summarize the status so that everyone knows where we are and what everyone can contribute. Okay so we Nick Cohen and I met with Julian the day before yesterday and it seems there's no particular barrier to completing or kicking off the migration by uploading 518 to unstable in the next couple of weeks. The main blocker as far as the rebuild rebuilds go is the subversion package which is not a package PKG pill package and it's not clear how that could be resolved because it fails to build on some architectures at the moment. Apart from that there's a handful of other blockers which are mostly being worked on by various people around the room and another 30 or so RC bugs which aren't blockers but which will cause breakage once the upload happens and that list there and really it's just a question of picking things up as we can but quite a few of the issues are unsolved upstream so it's from scratch working out what to do for each one. Okay so I could add the URLs to the copy file so that everyone has a starting point. This is the transition bug with the blocking bugs. These are the user tag bugs and there's also somewhere this page and in Florian calculated the reverse dependencies of the packages which have bugs to show the priority on yeah and which packages can be removed because they have no reverse dependencies so it's maybe not worth spending time on them. The only other thing I would say is that I'm currently rebuilding all the packages which build depend on Perl or Perl libraries which may throw out some more it's we've never done quite this test before but it's just getting things in a good state in advance of the transition. Okay cool five more minutes oh cool yeah package Perl tools package Damian one sentence yeah I started compiling all the tools that the group uses in its day-to-day work in a separate data package which would make them available without some git checkouts and something and we hope that this would make it easier for newcomers to get started. I really like that idea and I want to join you in the effort all right cool yeah I think currently we are waiting for one license statement but besides that besides that the package should be fine soon okay jumping around in our agenda Damaj is there something you wanted to add from your personal list to the meeting? Yeah I will try to be fast some of them are my ideas because I'm not that really involved yet but some of them which might be interesting for others. What I want to do is know the Perl tools better which are used in the Damian infrastructure because many parts of the Damian infrastructure heavily depends on Perl and its needs that there are places when some help is needed. I want to keep modules in Damian as up to date as possible and promote I want to promote its use in Damian maybe even replacing older or maybe not that better suited tools because this is some kind of part of the modern Perl revolution of kind of that yeah my idea I had an idea of making a list where and collecting best practices and things like that and Damian encouraged me to just do it make the changes so that I think that's that's the thing what I will do there are some work going on with packages Debianorg and it goes in the right direction I hope in maybe a few days or weeks it depends when I get access the most Perl infrastructure will be replaced with fast CGI which is better suited for the DSA team okay cool and yeah you know that you can always ask and get help even if it's your project I just wanted to get a quick summary because we are kind of out of time but I'm welcoming suggestions and comments on things like that and I will be an IRC student so cool so we have a half a half minute left something like that okay so Linzian profile is just the idea Linzian supports specific additional checks and it might be useful to have some in a group to point to specific group policy thing is Jenkins Holger is running Jenkins instances everywhere and he also told us if we have some Perl Jenkins jobs then we should ask him well there's Jenkins Debian glue from Mikha Prokop I think it's not that in Debian but will likely be at some time I guess I hope that tool makes it very easy to automatically build Debian packages out of Git of Git repositories upon commit or push and it can even export the build packages into a repriro repository so you can up get install and test the just build package very easy and I would be really happy to see something like that for our infrastructure we use it in a satchel team and it's very convenient just push your changes and half an hour later well satchel takes a while you can up get install these packages on two architectures and just play around with them and see if you broke anything that's very comfortable and I really would like to see that for the Debian Perl group too despite I think it's a resource issue maybe can you help with the implementation I can try okay so we can take a note that Axel knows more about Jenkins than everyone else in the room right seems so okay I'm afraid we're running out of time so I think we have to finish the official part I think we should thank Gregor again for running the buff and also lots of other things that he did for the team last year and before