 So the annual package Perl buff at that conf first we should check the usual things like who is monitoring IOC Joe good package Perl Debbie and Perl and Yeah, and then there's this copy document where I try to put a few things as a rough agenda for the buff and And where I would like to ask someone to take notes as we go along Is there someone who feels dedicated? Yeah. Oh good So for those following at home, it might be nice to be able to put Faces to names or nicknames So as each year I would like to ask for a short introduction for those who feel like Doing this in the unlikely case. There's someone following on the stream who doesn't know me yet. I'm Gregor Hermann Gregor and yeah, please top top I'm entering mostly working these days on reprehensible bills and hardening of our packages. That's all and Removing the crappy ones. Hello. I'm as kinds Simon, and I'm Trying to get my feet wet into the package party by Yeah Trying to fix minor pucks. Maybe sometime more Dom I'm mostly working on the Perl package itself together with Nico and Get in some of my remaining very old packages into the team repositories I'm Martin Berens Being a Perl community member for several years Always a Debian user, but not so far a contributor, but I'm very interested to learn that and I find the learning curve Quite steep So I'm here for some help to receive help I'm David Bremner, and you can't see me because I'm also running the camera But I'm sometimes helping with toolchain issues with git mainly these days And I have a few packages that I still take care of in the in the team Guess that's a far for the introductions. Then I have to scroll down a bit So one thing we usually usually look at the sprints We've had Well, depending on how you count it one or two sprints This year the first one was in May in Liorat de Mar embedded in the Debian Suncam So close to Barcelona in Catalonia We were for people there I Think Yeah, there's a there's a report. So the four people were Christof Nico Alex and me There's a detailed report and there's There are not so many people here now who can talk about it So I'm not sure do you want to know something more from my from my memory from my memories I think the highlights was that Nico uploaded 526 to Experimental Then looking at security issues with the various yammer serializers Then well one interesting point is that for our auto package tests where we run the smoke tests We added dash recurs to prove Which caused failures and I don't know 50 packages or something Which are fixed fixed by now that was part of that camp well and some Routine work I Guess I don't know if Alex or Nico want to add something from from IOC Yeah, so thanks to the Suncam organizers Okay, well and during that camp We labeled our work as a sprint as well since this was proposed by that conf organizers So I will write the report that sometimes currently they're only copy notes I Think we had three coordination Meetings in the morning on Tuesday Wednesday and Thursday And we were like I don't know three or four people working on on different aspects of of pearl stuff So Alex did a lot of work Into did a lot of work besides doing lots of other work as well. I Looked at this regressions from from proof and I tried to upload some of the new upstream releases Yeah Right Could I just could I just ask about the the proof recursion failures? Was that always the same kind of bug that occurred in each of those packages or were they quite diverse in how they they failed? Well, there was several groups of Problems so running proof that requires blindly over the t director is not such a good idea because there's stuff in it Which is not meant to be Yeah, run this as a test Which is only meant to be run at release time or something so I mean what we did now are two things that That we're excluding More of the test files, so there's some typical patterns like t slash author slash and And well some others needed some fixes So the problem with auto package test with smoke test and auto package tests are that that the test director is copied to a Temporary a director in then the test to run against the install packages and sometimes tests need something from the source That's a typical failure mode good So next year another sprint What's your opinion? Do we want to have a sprint when where how long about which topics? Dom has a microphone Say something Well, I Like the idea of sprints in general. I'll definitely try and make one next year if I can Same sort of time may April May maybe how many people would come It may depend on the location So I was sort of assuming somewhere in Europe and the idea is that yes, we're going to have a buff with people who are interested in Doing some camp or similar things in our place in Europe, but It's definitely going to be something next year around the same time So if you guys want to join Yeah, I think carrying the sprint in sprint in spring That's makes sense, especially when it's close to to the release of Well 528 in this case It was really good to kind of kickstart the development at the sprint Niko is reminding me that I Suggested Oxford as a location last year and that's still a Theoretical option if we don't if it doesn't work to have it at SunCamp Okay, so I guess the resolution is there is interested in a sprint and in spring and which We check if we join some other event Or not which has advantages and disadvantages. I think that yeah Good so much for sprints What's next low hanging fruit sessions? So we've been doing this monthly meetings on IRC since I think three years now Once a month where the idea is Maybe was I think it has shifted a bit that there's lots of routine tedious Work which is actually simple but needs to be done and that it's more motivating to Well do it together and together in the sense of at the same time and be together on IRC and exchange About the work I think it shifted a bit since we've also used the meeting sometimes for for discussions for like organizing sprint or something Well I'm not sure how much people like this to add meeting Points to the to the sessions or not That would be something I'd be interested in I mean in general I thought it was useful to be able to have a chance of talking about items like the sprint or the transition each time But that doesn't necessarily have to be a I mean I guess it's useful to have something fixed in the calendar that could be used For that even if it's not always Yeah, not not completely dated but still the low-hanging Session related to the low-hanging fruit session is that Yeah Nowadays for me. It's mostly like I just like randomly pop up and if there is something like this is obvious Like oh, I can just do it. I do it and There were like one occasion when I was like there and it's like Oh, what should I do and it was something written down, but it was not completely obvious to me Someone helped like oh, this is what it means and I was a I tried to kind of get involved, but yeah For me like personally if there is something like oh, this is like this is what needs to be done like look Here is here on this list just refresh some package or just do this and I have the background knowledge Then it's fine. I can probably just do it, but sometimes it's just I Just like busy during the week, etc. Etc. And it's just oh, oh the session. Oh, I forgot and I just like out of the random I just like popping in Yeah Yeah, I mean this also ties in with Usage of the agenda which is on the wiki which is not so much maintained actually Sometimes it's usable. It's it's a good starting point because sometimes it's refreshed, but Sometimes not yet much Would it work to fall back and unless there's something you want to do or can do in the agenda You can just fall back to pet that has plenty of low-hanger fruits generally like new abnormalities stuff like that I just did that that like Here in the book But there were some time ago like months ago when it was not that obvious when I looked at the pet so Times changes. Yeah Nico says Yeah, they often seem more like just general ISE get togethers Which is fine? having the calendar in advance helps a lot and Yeah, we could decide that they're cool. There are two meetings instead But I guess People want to use them for both things The timing and general cadence seemed to work well this year at least for me Yeah, that's that's the next question. So I So this year we had The first two at 18 UTC because we had not changed the calendar yet And then we were switching between 17 UTC 19 UTC From the participation There's not really a difference between the those times So, yeah, I don't know if we want to go on we can just keep the timing because Damian has already extended the calendar until I don't know 2038 probably Something like this Okay, so we just go on with the existing calendar scheduling and We acknowledge that it's not only working but sometimes also a bit Discussing if there's a need for it, right? Cannot be heard in the stream Okay, so yeah, I need to to run soon. So that's a topic. I like to address now last year maybe all the year before I Probably proposed to that we subscribe to email notifications from repossible builds tests and After in retrospect, it seems to me that the amount of false positive notifications is so huge that nobody read this mail or And so there are mostly noise and useless and generally I so Yeah, I mean here by proposing we disable this And he won See some value in this email notifications and I would like to keep them. Okay, burn it. Yeah, I will ask Holger to try to find out how he subscribes us in the first place because then and to unsubscribe us Thanks Somehow There's something messed up here. Did I do this? So it should it should read teams that's just here Oh, okay Yeah, collaborative editing So the the annual look at how our team does with some numbers I checked again the numbers of committers in the last 35 days like before so This time there were 54 persons with it at least one commit on the Debian repository and the Debian director in one of our repositories Which is quite similar to the years before I mean you could say we're in constant decline from 58 to 56 to 54 Oh, but basically it's the same number and also if you look at people with at least 100 commits it's now 13 and it was 11 and 14 in the years before so it's The same ballpark Figures So I think yeah, I think the pearl team is is stable Yeah, well sounds a bit negative Okay, another thing about membership is last year we Discussed and then did for the first time this pinging of inactive Members so everyone who Haven't made a commit in the last two years got a Mail hey, you seem to be inactive in the team. Do you want to continue to stay or can we remove you on alias from the project? Which went very fine in my experience so that the replies were well positive or Neutral and we cleaned up quite a lot of Inactive accounts So this year Alex agreed to to do this run again. We just decided this the both of us during that camp. I hope that's That's okay. Alex already sent out the mails last week and It seems he already got Quite some replies the deadline is I think in mid September And well, yeah, I guess this time there won't there will be less removal since we have cleaned up already last year Yeah Okay, then I I put two Two topics here, which just came to my mind. I don't don't know how much there is to discuss but Looking back at the last year there were two Kind of major events one was the release of pearl 526 I Don't know Dominic had What's your summary? I wasn't as involved in it this year as I was in previous years But it seemed to be all the more rapid for that At least it was very smooth from what I observed and the work I did So thanks to Nico for doing most of the work there and to Gregor and everyone else for Fixing all the bugs that needed fixing in the packages. We had more Failures reported subsequently than in previous years, which were from packages where we hadn't run QA Because we only run test rebuilds on packages depending on build depending on pearl So if packages only use pearl base We don't test them And I think we should probably extend that at least for one run to do a full archive rebuild next next year Because it's always nice to avoid problems before they rise and as far as I know the schedule remains constant upstream Yeah To be already know something about 528 so like to be already knows if there are some big issues coming up with 528 Um, not that I know of I don't think there's been any Yeah, I can't remember anything specific, but yeah Okay, so anything else to 526 Okay, then we also had a release of stretch and the freeze Before it yeah, yeah, that was something So I don't went so fast The freeze was quite short compared to previous years Again the same question is there something to discuss about it to learn from it from our side so you mentioned the other day that Whether we should avoid uploading time stable during the freeze next time and I'm not so involved in uploading lots of packages within the team, but Would it be helpful to allow leave package uploads within the team more freely or I Think that's already action policy in theory too We can upload to seed unless it's something that has like lots of reverse depths or is critical or risky No, I thought that's already what we said in the past. Maybe we just Were a bit too shy and didn't need to implement it to its full extent in practice What what I what I was thinking recently was There's if there's no strong need for us to to upload to our stable there I have felt that there's a change in the Attitude to what from the release team in in how this should be used or without the automated real mobiles So testing and these things so there's also the the angle looking at this from that we are It's a it's a large number of packages and we are sending a message to in support of the release team saying that Well, we are keeping clear of unstable even if we don't need to keep clear We we could make that extra effort just as a Assign to others. That's for me. It is not personally for me I have not felt this time around that I really needed to put it on steep put it into Unstable is just a convenience that I don't need to go and maintain and track things in experimental So I don't personally need to I'm not burdened by us deciding that we go through experimental during the Yes, there were comments from Nico same first Thanks, Alex for the inactive contribute of pings Regarding 526 we should have tests rebuilt the whole archive Not just source pearl bill reverse dependencies Otherwise it was great and infrastructure is much better than what is thanks to them dumb. Sorry Then carneal said the producer will know Regarding freeze. I have loaded partial a packages to an Experimental instead so that we don't like too much behind and then after the release move them from experimental to see it Also, Nico adds just now that we should mostly refrain from a necessary blows to unstable that in freezes Yeah, so why I brought this up in it is discussion with with Dominic is that So historically this was the second freeze where we didn't upload to unstable that I don't know how many Before where I was involved. We just kept on going except for some important packages And yeah, and we got a bit shy and cautious Which Is okay and has has of course good reasons, but what worries me a bit is that Well, first of all, we have a huge backlog now, which was like 400 packages with new upstream releases And it's not really shrinking But what worries me more is that I have this this feeling which might be wrong It's just a gut feeling that we as a is a team lose lose momentum during during the freeze So the people who were active before With updating packages Fixing a bug a week or wherever who were around then well set back and waited during the freeze and I'm not really Coming back at the same speed as before I mean maybe also because it's July and August and summer and there are better things to do then sitting at the laptop and updating pearl packages but I'm also wondering if this is somehow related to the freeze and if this is Well a good development so I'd rather tend to consider to Be a bit less shy and to at least keep on uploading this fringe packages, which Don't really matter for the release My thinking there is that this is not a pearl problem This is this is a general Debian problem And we are sort of subverting the general project by saying that well We do differently from what we what the whole project generally is being told by the release managers Well, hey, this is a freeze. We should all focus on the sort of the boring stuff and getting getting the freeze Getting the release out and if we if we are concerned about our contributors Being bored then that's exactly the same situation all over the board So so so I think it is the wrong Solution for this wrong approach to then ignore the release managers in this We should then raise the question more generally and seeing a fringe packages in Debian Could those be exempt from some more aggressively or postpone to later in the freeze things like that having the dialogue In the whole project. I think it's better So unless I've missed something the release team has never said I mean that the release team has always said it's fine at least in the early stages of the freeze to work on leaf packages and upload them to unstable and A lot of our packages are leaf by some definition so I Think I'm agreeing with you in a way that we shouldn't have anything special for the pearl team And since you mentioned numbers if you say for 400 packages backlog Maybe a fifth of those are mine or the ones that is has my name on it. Yeah, I'm just saying I have been slow to Get up to speed again lately. So like everyone else Does anyone have any idea how many? Unblocked requests we had to submit during the stretch freeze because Unblocked requests because that's essentially what matters about uploading to seed It will become a problem if and only if you need to Send an upload unblocked request later on if in practice we submitted very few of them and Maybe it's always same packages every release that needs some a block request for some reason Then maybe it's not such a big of a blocker. I Don't remember if we had it Any unblocked request during this freeze, but if we had it was a very low single digit number Yeah, I'm not sure if that would make sense to like update the packages just in jit without like actually uploading I just Would it make sense like someone could just like keep going and in in the package and package tracker It would just the pet it would just show up like in another category, which is like Not the like completely stalled or or Needs work to be done, but it's like the in progress kind of state Yeah Karen drug from IRC he says He was one of the people who joined the team during the freeze He didn't care that they weren't part of the release They're now an unstable and testing But I guess that's a that's a specific bit of feedback about new packages. Whereas, yeah The more general questions about just existing ones as well and Alex Says that your nurse has a point in focusing on the release during the freeze and help fix in other issues So that so that the release happens sooner Having Nico says having testing unstable not in sync during the latest age of the stretch freeze Excluded getting priority important fixes through together through through all together Now he left but but this this question of how many how many Unblocking requests we require we asked for So has the risk that we don't notice what is the damage for Packages depending on Pearl libraries, I'm just thinking that maybe we miss some of the the collateral damage that we cause I don't know Just saying that that could be also a risk just an interesting point here because Especially during the freeze I was looking at things and I just realized that I just sometimes do not have the background the Expertise and or the time to actually do it so for me like during the like the simple like I Don't know maybe to We are saying this about the brain that stuff like just uploading new packages. That is some updating That works for me. I Might find something in the flight of freeze like really critical bugs where I can jump in but usually not it's just It probably need would need more time investment from me. However, the simple easiest up I can prove Well, and in general since we have these auto removals from from testing the the list of our c-parks is quite small and contains difficult Bugs so that the time is when you could just pick any Random our c-bug in any silly packages are gone, which is great, but Yeah But so so I I would just here repeat my point that this is a general Debian situation that that The the days of a simple box helping our feeling that you help out the freeze We have we have passed that on to the robots. So, sorry you are We're hoping replace by script Which is good, hopefully Okay, so I don't know if anyone has been taking notes, but what I have in mind is this is a general problem in Debian, that's true That the freeze policy doesn't explicitly forbid to upload leaf packages in at least in the early stage of the freeze if you are aware that it might be removed from testing and So that means that maybe we should try the next time to be a bit less shy If someone feels like Uploading some random packages that is So play play play by the right play by the Debian in the general Debian rules, which is both Be more bold when we are allowed when we are permitted, but then also respected more clearly and if we disagree then Throw it to the whole day There is a couple of comments on IRC. Yeah, I'm at least can and draw Is browse Says I get that my moves were a bit unseen with the release purpose But I have if I had been rejected because I was doing it and told to wait for the release I might have not come back. I hope that my new package releases did not have an effect on delay in the release and Are we in the end because there is more packages later? Well, yeah, as you said in new packages are just fine and I'm not the not an issue in So, yeah, it was helpful for Debian not the problem Good so much for the phrase until next next year. Oh Yeah, okay, so random other points actually I didn't look at the open tasks page this year But some one thing I'd like to mention is get that cherry and then someone has been adding another point at the bottom So get that cherry is everyone familiar with this funny thing So like three years ago four years ago, whatever we've been discussing the handling of patches in our packages Where there are several? tools to have patches applied Which is the preferred way of working for Some people so when you put in your upstream release you Yeah, I'd get rid of the Commits because they are merged upstream or you can just fix merge conflicts in your editor, which seems to be more appealing to some people in contrast to working with quilting Debian patches afterwards So in 2015, I think at this printer before this print in Barcelona Nico added some wrapper scripts around get depth cherry, which is a tool to export Commits from master branch, which are not in the upstream branch as files in Debian patches and At Debian 15 in Heidelberg We said we would Experiment with this thing. So it's not only get depth cherry, but also taking good notes to have to meet the data for the patches There's a bit of machinery Okay in practice this in practice we had four Packages one is lip log log for pearl pearl Which my notch has maintained with git dpm originally and then it somehow went to get depth cherry but it used it doesn't use any notes and Florian has in Heidelberg converted Three packages to use this git depth cherry machinery One doesn't have any patches anymore. So there are two left one is the module build pearl and the other I don't remember Yeah, and the practice is so it's Three packages left, which is not much in our 3000 some hundred packages and it seems like like no one is really using it You can practice it's that Salvatore or me look at new upstream release of lip module build pearl and then we have to try to remember how this Get depth cherry wrapper machinery actually works and This lip log for pearl pearl git repository is for various reason messed up each year so Each summer I have to ask David to fix this this git repo Okay, so some my summary is this git depth cherry Experiment did not really work out and we should Well stop it and convert that we remaining packages to Normal and the quotation packages Opinions comments experiences Well, like like all all other packages except those three so patches unapplied and quilt Manually, I mean is there somewhere who would like to continue get depth cherry or other experiments or Can we just call it a finished experiment? Well one one detail worries me a bit is that when you're saying that everybody forgot is like Was it not written down and read me source? What was the supposed? procedure, so I was just curious if also the The doom the judgment of this experiment was if that could be thrown into a wiki page somewhere to the people who were curious about Deptiary other places so that they couldn't at least know these people tried it and ran away screaming or Maybe some more details of why is this not interesting? It's just a detail of three out of three thousand packages were got Exciting about it this and that's the reason Pearl team decided not to do whatever it is so that other can learn from I can gain from our experiment. Okay. I was not part of the experiment So I don't even know if I agree or disagree. I just let others decide Yeah, I mean that's that's the main point that no one was actually really Taking part in the experiment Okay Okay, and then someone added a point. I don't know who this dark blue Okay Pearl packages not part of Pearl team Yeah Pearl packages not part of the pearl team is a topic we discuss each year. I think I'm pretty sure we did some UDD work to identify these packages and then I failed to do anything with the list so I think that's at least from the point of view of identifying packages which we could Add some value to by adopting them. There's still work to be done. So and how would we proceed if we had the list? We just need to email the maintainers and say hey, I Think I don't remember what the exact criteria were now did we? Look at packages that were looked like pearl packages that hadn't been uploaded within a certain amount of time and weren't per team maintained Yeah It's maintained the enemy use it's hundreds. I think I think it's probably at least a hundred. Yeah, I Guess we could try and kick that off effort off again. It would seem to make sense to See if there are to try and head off problems before they occur because it's there's quite a big overhead When it comes to enemy wing packages that aren't been actively maintained by people who are Who know about the current pull stuff? But at the same time we shouldn't We should allow people to maintain packages if they want How about a friendly Note through a whistlest bark so we both we can track that we can track the whole Bounce and the whole bunch of it and it's signaled as this is a whistlest thing It's not that we want to push you out It will well very welcome to continue if you like we just want to know where are you around this and Because it's about what we can elevate it when we get no response for two weeks when it relates to To mine off and then we can elevate hang there for half a year or whatever long we want and through all this time We have an easy way of having a status report just To make sure that it's it's an offer It's not about taking away the package but bringing bringing in you a little but giving you a hundred Commentainers and user tag it somehow. Yeah. Yeah, sounds good. So who is going to well? I guess I volunteered last time so I should probably make good on that Okay, cool, and I was just also going to say this is very much the same tone as the messages that Lucas has been sending out about packages which haven't built for years. It's it starts off as a wish list or Not sure what severity bug is on the package and then Well, it's a bit different, but he you know, he will eventually propose rms for that. Yeah, but Anyway, it's it's the same tone. It's just Offering oh Ask him for clarification and offering help. Yeah cool and Just to catch up on I'll see on the same conversation So if the bugs if the packages are a buggy we should just make sure that we file bugs on them, which I think we do so Maybe the so So Karen drug says I didn't mean adopting or fixing the packages I think it would just be useful to inform them that the package doesn't work properly The package had no idea it wasn't working so Maybe there's more QA that we could do even on packages. We don't maintain So we could add them to pet says Alex M We could we could try and make sure that we run auto package test on them but in that case we're sort of Getting closer to maintaining them and it seems like a Yeah, I mean we are catching the ones which are a seat buggy in each year when there's a new pearl release I have some old friends in that list. Yeah. I mean I also have locally some packages where the last three uploads were animus for 520 something Start with the tracking of what is the whole pool we're talking about and then obviously File box when we stumble upon them, but us proactively going out and hunting down around Sure, if anybody has this the excess time, there's nothing wrong with that That is generally what we do in Debian That's I mean, but but but organizing that this is what we must do Well, then we're talking about our responsibility and that is what we are offering to do if they want us to do Right, so let's let's take it from the end Sorry, I'm the director completely forgot about the time, but it's a real quarter to one. Yeah, I know Okay, so we are we should close soon. Yeah, so yeah, just run the idea Maybe if there is a package which was an emude by someone from the per team It could It could appear in the pet list Unless someone like the original maintainers makes a later update it could like appear in the list and it's just like Someone just after a bike and take a look at it like, okay, this have been an emude and it's like an emude for like a year It's like Maybe maybe do something about it like it's not Not not owned by the per team. Yeah, I mean pet takes information from our kid repositories. So We need to import something and then it gets fuzzy Okay, so since we're out of time any last comments thoughts Last words Last words well, let's keep up. Let's keep up the good work together Shall we