 We're ready to start. OK, we are going to start with the Puppet Pearl annual booth. As always, the booth coordinator will be Gregor Herman, who's been a part of the Pearl team for many, many years. And the stage is yours. Thank you, Gunnar. Maybe to start with, Gunnar is also the person who brought me to the package Pearl Group. It was quite difficult. I asked if someone would like to upload a Pearl package, and Gunnar was, ah, why don't you join the group? Come in, it's so nice. And that's why I'm still here. Unfortunately, Gunnar is not any more in the Pearl Group. Anyway, welcome. Thanks for coming. This is really supposed to be a buff. That's why I'm not on the stage. So it's about discussing topics related to the package Pearl team. I'd like to start with a small kind of introduction round. I guess there are some other people from the group following at home looking at the streams and on the IRC. So maybe we can have a very short round where those who feel like it say their name and wave into the camera so that the ones following at home get a face to the nick. Yes, I'm Ansgar. And well, I'm in the Pearl Group for, I think, two years now, or so, or three, I don't know. Well, and I wrote the new PET. So if you have any problems with it or questions about it, you can talk to me. Tell us what line would you like it in. Well, it's not written in Python, actually. Hello, my name is Damian. What about me? I was some driving force in the past for the package Pearl Group. But well, that function is now very nicely taken from Gregor. Thank you. And well, that's it. I'm David Remner. I'm somehow mostly just lurking in package Pearl these days. But at the moment, I'm more involved than before, because I'm working on the Git migration, which we'll talk about a bit later. Hi, my name is Ausdorre. And I'm two involved in Pearl Group, mainly packaging. Hello, I'm Tim Douglas. Yeah. Well, I'm not involved with it anymore. I used to be really active. But my name is Renema Jörga, so. I'm Chris Butler, or Chris B. I do some packages occasionally. Hi, I'm Axel Beckert. I accidentally jumped into this buff two years ago. And that's the way I joined here. And yeah, I think I'm not very active, except maybe in IRC. I'm Zlatan Todoric. I'm a Debian new maintainer for a few days. And I'm just lurking with which packages should I work. OK. Definitely Pearl. It's definitely the nicest group. My name is Gavrilo. I'm a beginner in the Pearl, and I want in the future to make packages of modules for Pearl. Cool. Greetings, everyone. My name is Philip. I have programmed some software with Pearl, so I'm not a developer nor a maintainer. So I'm just here to listen. Thank you. Hi, my name is Maria. I'm also lurking kind of a newbie in Pearl, so. Seems we have a nice mixture of people. Hello, my name is Marcelo. And I don't know Pearl, so that's it. Well, my name is Magnus, and I like Pearl. I think that should be enough to qualify to be here. Right. Hello, I'm Tincho. I used to be active in the Pearl group a few years ago. And now I'm trying to get back. OK, thanks so far. Do we know from IRC who is watching? No, we don't. If somebody can't relate from IRC. Yeah, I've asked them already. OK, some details. Well, kind of agenda is on this wiki page here on the top. It's a page where we collect things to discuss and things to work on during the year. And then, well, either someone works on it or we discuss it here. On IRC, there's this step conf round room. But I guess the Pearl people will still hang out in Debian Pearl. OK, the video is for the people watching at home. And I hope that a few people have already found this copy instance in order to take notes. Good, switching to the agenda. I'd like to start with this second point. Those of you who follow the mailing list already know about it. It is the idea to write in our internal group policy which of the tests that are shipped with the package should actually be run during build time. That was sometimes not really clear, which of the maintainer, release, something test should be run. So I've written a proposal and sent it to the list, I think, twice. I guess the people following the list already know it. And it's probably a bit too long to read it in detail now. The general idea is, yes, we want to run as many tests as possible, except the tests that are explicitly marked by upstream as release tests or author tests. And of course, we cannot run the tested internet access during package build. And is there something else essential? I think that's the general idea. So this is the last chance to say something against this proposal, otherwise I will commit it now. And we can take it off. So some packages have pod coverage tests which aren't marked as release tests, so we run those ones. Do we run pod coverage tests that aren't marked as release testing? Yeah, I think the idea is run what is being run automatically, but don't explicitly enable release tests. OK. And have we compared how this matches up with the quality the C-Pen testing service? Yeah, I think the newer approach in C-Pen modules is to use this environment variables release testing, which is not supposed to be run during the smoke tests or the C-Pen install tests, so that's the same. I've also compared it with Fedora Perl packaging policy, and it's the same too. Not that it matters, but it was interesting to compare it and to get some ideas. With my packages, which at least one of them is quite Perl related, WML. I tried to enable the tests, and noticed that because of embedded code copies, the tests basically failed because I don't build them and I removed them from the table. So do we have any packages which have embedded code copies in there? Hardly any. There are some few packages that have some test modules. I mean, if it's easy, we try to use the version in Debian, but it's not a real problem in my experience. There was some years ago a big integer number library, which had a lot of, well, mathematics extensions which did embed some libraries with minor changes. I think we got it out in the end because it was too problematic. Yeah, but that was not related to the test. That's the general question. Can we use this? How do we deal with it? OK. So I guess this means? Yeah, I know. But I have no idea how to change this in UX with you. It's just a comma. Yeah, yeah, sure. No? For readers following the stream, it says SVN commit message policy amendment for test suits. Thank you, Gunnar. The people on ISE will see the commit message at some time. I don't know what it's waiting for. Maybe. Yeah, but then. Right. Exactly. Good. Yeah, maybe we change the order a bit to get it more into the order of importance. So yeah, one interesting thing is the migration from subversion to Git, which when the discussion started in, I think, 2008 in winter. So that was in August in Madelbladda. Since then, several people said they would work on it. And well, finally, there is quite a lot of work happening thanks to a few people in the room. And I think we're almost there. And I would like to ask David to give a summary of the status quo as of one minute ago. Well, not much has changed in the last 10 minutes. Because I'm paying attention to the buff instead of hacking. So progress stops. So it's going OK. I guess you can see in the Gobi instance, you are well, it's an SSH style pseudo URL for some test. You can look at some repositories, which I converted using this SVN All Fast Export tool that the KDE people originally developed. It's a C++ tool. So I can, even worse than Python, maybe. But it's much, much faster than Git SVN. It takes about an hour to convert our entire six gigabyte SVN repo. And it makes a total of, I think, 1.3 gigabytes worth of Git repositories. So that part is, I think, working quite nicely. We have a few issues that, I mean, essentially, it's quite usable in the current state. But we want to make it nice. And there are some packages. For example, DHmakePurl, Gunnar, and you probably forgot, but in 2006, Gunnar created this in the slash tools directory. And so the initial conversion missed the first few commits of that. And similarly, we had a few packages renamed. It's something that happens from time to time. And just this morning, this sort of dawned on us that maybe we should. So currently, what we have, if you look at those packages, you'll see the history since the rename. And that's not ideal. So it shouldn't be too hard to fix, not to put any pressure on Savatory. But Savatory is going to give me a list of renames. And then we have more or less the technology. So I mean, I'm happy to go into more details of how this is working. But I think that the high level of you is that we're pretty close. And I think we're quite confident that Gregor's confident will have this done by the end of the day. And I'm confident we'll have it done by the end of DevCon. So you can find out which one of us is less wrong. Yeah, excellent. Thanks, David. Just one question, because I know that big git repositories can be an issue. Do we will use submodules for that? As far as I understood, it's all separate repositories for the packages. So every package is a one small git repo. And typically, they have maybe 30 revisions in them. They're very tidy. But as far as having something cohesive to manage our entire set of packages, which is something we do as a team, I know that Gregor and Dam and Ansgar have been working on nice configurations using Joey Hesse's MR tool to check out all the packages and do your commit and take them all. And I think that's, Dam, you have mostly documented that? How to use MR at this point? Is it pushed yet or not? It's in your head or? It's OK. It's in Dam's head, but it's also on the website. So very good. There is some problem with the workflow, which is described on the website. Blame me and, well, tell me about it so I can fix it probably. So the documentation for using Git is on our website in Git HTML. Well, yes, it's probably not really complete, not really finished. But I know there are quite a few people who actually know how to use Git, not like me. So Tim was a mewness. So please improve it. The page actually is still in SVN. I hope you don't mind editing it there. Yeah, that's the next step. But as SVN commit and Git commit, it feels very, very similar. OK. One blocker for quite some time was Pet, the package entropy tracker, because the first version was, did it want to say something, Garnt? So we are also using MR. And what we did, we have the MR config still in SVN. So you can actually check out or have, you already have your checkout. And then if you do the conversion, just everything vanished without except the MR config. And you do MR update, and you're fine. Yeah, we have it now in a Git repository called Meta. And there's even a script to skip the packages which are not updated. But I've looked at the installer stuff to get some ideas. OK, one of the blockers was Pet, the original Pet version mostly written by Tincher was for SVN, basically. And now we have Pet instances with many numbers. Maybe Ansgar, you can give a very short summary. There will be a dedicated PET buff tomorrow. But as far as the Debian, I think tomorrow. But as far as the Perl group is concerned. It's actually a Vivo PET, because it was not very easy to add support for different version control back ends to the original PET. And well, I actually rewrote it two times. So the current version is now called PET3. And it's now mostly working. There are only minor things which need to be changed now. Well, the templates were actually taken from the very first PET version. So it looks almost the same. The information is also more or less the same. So no need to get used to something totally different. And the new page is now PET, Debian, net. And then slash package minus Perl slash PET.cgi. I think it's not yet linked on our web page. But I can add a link later today. And it's not completely up to date, I think. Yeah. And it's still called .cgi, although it is no CGI anymore. Good. I think that's tomorrow at 12. OK. I think that's it for the overview of the conversion to Git. So I don't know if people have some questions about details, some resentments, objections, proposals offered to help with the few remaining pieces. Hello. I've been trying out a few packages in Git. Have we decided how to manage quilt patches with Git yet? That's a question for David. The short answer is no, because I think it's enough for this step con to get the things working in Git and to stay with our most, essentially not to change our patch management. But I think that we can talk about it. One thing that I'm waiting on is I believe that Guido is going to provide in the next short time a similar functionality in Git build package as exists in Git package to generate patches on the fly. And then we can consider whether that's the nice way to do things or not without forcing people to use a particular tool. Right now, we would have to tell people to use Git package, and many people are already comfortable with using Git build package. So I think the high level view is that we want to be as tool agnostic as possible and to adopt conventions about the structure of the repository, but not about what tools you need to use to work with it other than Git. The documentation at the moment says we can continue to use Quilt, which everyone knows, or this Git build package patch queue might also be helpful for those who can pronounce it unlike me. Right. Actually, that's a good point that no one needs to know that you use Git build package patch queue as a local Quilt, essentially. So if anybody wants to discuss that further, I'm happy. OK. Any other remarks, questions? Is there something on the IRC? No one around? OK. Well, so yeah, it seems that the old guys like me or Tincho have to now really adapt to Git. It's imminent. Maybe it will happen today, but tomorrow, yeah. After seeing the state of the Git transition, I'm rethinking about coming back. It's even possible, believe me. Well, I'm doing that in that other place. Yeah, I guess we'll have quite a few questions after the transition, but I know that there are enough people around to answer them, so we'll manage. OK, so far for Git. Then let's look on our agenda again. In the discussion section, we had one question, I think, that was from Ansgar. Ansgar and me discussed it on IRC at some point. I don't know if it's still relevant after the transition that the handling of the removed packages, yeah. I'm just repeating the mic. OK. The question was sometimes packages are removed from the archive and we also removed them from SVN, also from Git, and we are not really consistent in how we do these removals. So maybe we can fix it. The problem was I would have liked to keep text and branches in SVN, even when we remove a package. But when we move to Git, I don't think this is relevant because we just moved the entire repository to a storage area where we keep removed packages. So it shouldn't apply anymore. But the idea would be to have some ethical, whatever. Also in Git, where we just moved the whole directory. Yes, for Git, I would just suggest to when we remove a package to move it to some different directory and keep it there forever. Yeah, the difference with MR is that each package only tracks its own state. So if you create a directory for archival for long term, no longer active, well, it will still be there the same as it is in the subversion history. Just wanted to say that for consistency, it will be good that you can still access it with MR and all the tools like we used to have in SVN, no? OK, so we create some ethic or whatever directory and package removal means moving the foo.git directory there. Is this the consensus? Good. OK, the next thing here is I don't know if this is really something where we have to go into great length to discuss it. Came up some days ago, Perl 6, they are now Rakudo and Perl, whatever an unstable. Is Perl 6 in general or Perl 6 libraries a concern for us as the package Perl group? Or are we only the package Perl 5 group? Should be a separate team. I don't think we have to decide anything complicated but just to get the feeling about it where we should go in this direction. Hello, this might be sounds kind of stupid, but what are the main differences between the stable and the unstable version of Perl? What do you mean by stable and unstable? Team is already answering good. Perl 6 isn't really an unstable version of Perl. It's almost a completely different language from what I understand. So I haven't learned Perl 6 yet. I don't have any plans to. So as for packaging, I don't know whether CPAN modules can be used with Perl 6 in the same way. I imagine there's some compatibility thing going on. So it might even be that we should wait and see what CPAN does. I mean, I feel like we're the CPAN packaging team and there will be some solution upstream. If I understand you correctly, then I agree with you that we'll just take a relaxed thing of not make decisions now like we did with applications, like see what happens and see what we can find out and we can always adjust it again later. I mean, when it starts emerging, anybody wants to package some Perl 6 libraries and try to do it and we'll see how that works out. Check it as it comes. I haven't seen the stages of Perl 6 in the last times. So I don't know about that too. But I think that we have been pretty good on having a good communication with upstream. And upstream has been listening to us. I think that maybe it's a good idea to try to be an early adopter to try to start the analyst with some packages to see how we integrate with CPAN, try to see what are the new conventions and trying to give early feedback. Because I think that's good for them and for us. Quick note from RC. Dominic thinks that there is no need of separate team for Perl 6. There's no need to? Of separate team for managing Perl 6 models. Yeah, I guess he wants to have 175 co-maintainers. I see the point. That's a nice thing to hear. Yeah. Yeah, it's actually Dominic and Alessandro are the ones who have been working on the code and Perl lately. They are also both members of the Perl group. So I guess it will be connected anyway. But yeah, Jonas, I share what you said. I think we can be relaxed and try and see what happens. And if it's a mess to have everything together, then we can always split it or something. OK. Yeah, it's so easy with Git. Everything will be fine with Git. It will be no problem. Right. And we have the full support of all governments of the world. I know. OK, so Perl 6, so far, so good. Another thing which I have not written here and there's not really anything to discuss. But still, it's Perl 5.14. And Dominic has sent a mail to the list yesterday about the state of 5.14. If I remember correctly, well, it is an experimental. They are tracking some bugs that are still around, which I think are not really many. And if I remember correctly, they would like to throw it into unstable in some weeks. Was it some weeks, his words? I think so. Yeah, I guess that the last transition to 5.12 went quite fine. Yeah, but in general, there was not much. It was not like 5.10. Yeah. Question of IRC. Well, OK, I'll just ask it. And the question is, are there any plans to move to a more recent build from testing to stable? That's a more recent build of the Perl package, I think. Well, upgrading Perl and stable is basically not possible, even uploading to squeeze backpots, because there are many packages that will break. And this includes quite a lot of packages in the base system. And even to get it installable, it would need rebuilds of almost every XS module for Perl. So this is not feasible to do for either a stable update, which, well, or even for just squeeze backpots. OK. Yeah, so time is flying a bit. We have 11 more minutes left. So we can either take a quick look at those items that are still on the page, which are in the category things to do, tasks. Maybe there's something that someone wants to claim and to work on. Or we can also use the time if there are some other things which are not mentioned anywhere, which someone would like to discuss, which would be important, and I'm not aware of. Is there anything we need to discuss instead of looking at these tasks? Maybe it's a non-issue. I hope it is a non-issue. But let me just try to raise it anyway. I use CDPS and I hope that no one is really feeling that it's a big problem. It was there was one discussion on IRC relatively recently that someone was reluctant to touch any of it. And I was trying to say, hey, it should be designed so that you don't break anything by working on normal methods. So people are welcome to work on the packages that are using CDPS for updating things. Even if there's a control.in file, you could still automate across many packages to touch the control files. When I then later come around to do the updates, I double-check if there's inconsistency between the two files, things like that. I'm just asking around if anybody feels more than it's fine that you just avoid the packages and poke me every time you stumble on CDPS. It's fine with me. But it's also fine if you try mess with my packages with these CDPS packages. It's fine with me, too. So if anybody is feeling like this is too awkward, this is slowing people too much down, that I'm working on CDPS, then I'm just raising it here then we can talk about that. But I was just saying ahead that I'm not going to switch to using another packaging system at the moment. So the issue is not do you want to convince me to do something else. The issue is, is it too hurtful for the team work that these packages are lying there, so maybe I should move them out of there? Or should I pass them on to you, some of them? Things like that? Or is it a problem? Can it be a problem? Do you feel anything like that? So one of my favorite hobbies is teasing Jonas about CDPS. But actually, I'm using it in some other places. I'm using it for a racket right now because I inherited it and so I'm getting a little bit familiar with CDPS. So if you can't find Jonas, then you can try me and maybe I can. I won't answer questions about CDPS, but probably I can try. So before you despair, so first you can try Jonas, then you can also try me. I don't mind giving you a little bit of effort towards these kind of things. At this tincture. First of all, a comment about CDPS is not so bad as it seems. I've been using it too. And then I switched to the age back, but it's not so bad. Anyway, what I wanted to say is a related topic is that it used to be when I was around all the time that it was a good place to refer newbies to the per group. And I think it's probably still the same thing. And I think it could be a nice thing to do since there is other groups trying to make life easier for newbies and trying to guide them a little, maybe to make a little more noticeable the group as a good place for beginners because I think it's still probably a good idea. Yeah, I totally agree. And luckily we get newbies quite often still. But yeah, advertising it a bit more wouldn't hurt. But are there any more answers to Jonas' question? Well, my answer is still the same. I'm fine with it. I know these are special packages, but I'm totally okay with having them there. I think it's a good reminder to have it this as an inofficial group policy. There are packages which have Jonas and CDBS and they are supposed to stay as CDBS. And everyone is happy. Yeah, but with this addition that, well, that does not mean don't touch. Yeah, yeah, right. That's what I wanted to emphasize. Please do touch, please do mess. Also, if you don't want to learn a lot of CDBS, it doesn't mean that if you touch it, then I'm gonna hunt you down and teach you CDBS, something like that. You're welcome to not be infected by CDBS, okay? Thank you. Good, any other spontaneous topics, Tim? How do we, I don't know if we have a policy about how we interact with Debian developers who aren't in the group, because sometimes I find bugs which are in other per modules in Debian, which I need to depend on. And do we have something, do we have some guidelines we could perhaps document about doing NMUs of other developers' packages or? NMUs of packages which are not maintained by us? Yes. But which we need, yeah, that's a good question. I'm not aware of any specific policy we have, so I think it's the general Debian NMU policies. Do we need a special policy? Is that what you're feeling? I don't know, I think it's just a documentation thing just for that I've run into this once or twice and I don't know what other people are doing whether we just wait for the maintainer to fix their bugs before we do our work or do we actually go ahead and? Maybe that's what also, but Greg also was saying that Debian in general has patterns and styles of how you deal with NMUs, you call it an NMU yourself. And as I feel, the recent years, it's been tightening more up that it's become more okay to do more and more aggressive NMUs. And I'm just thinking that I feel personally that we need no special documentation for that in the Perl group. I mean, we are all involved in Debian and as a larger thing, if you think of newbies, for instance, just one line in the Perl documentation referring to whatever is the proper place in general Debian as I see it. Yeah, I also think we need, we don't need something special but it might be a good reminder to say we can do this. Also, I know it from myself that I've been waiting for six months for some one to update this package and which is a bit useless. I just wanted to remind people that we can do NMUs even for new upstream versions. So there's no reason to not NMU even if it's just a wish list bug like a new upstream version which we need for some other package. But of course you should follow the usual policies. So it's just an NMU if the maintainer does not react. Yeah, as a reminder often it helps to invite people either to join the group or to hand over the package. I know sometimes it doesn't work and that's when we have to decide, yeah. Okay. One last question maybe from Dominik. He seeks feedback for using his config edit tool when maintaining packages, is it good, bad, whatever. I can't. Dominik, the author of config edit tool, seeks feedback about using that tool for maintaining packages. What's missing, what's useful. So config edit the script which is in the config model has really grown some great features in the last month for updating Debian Control, updating Debian Copyright file. And yes, I think we should really use it more. I still hope that we can somehow hook it up into either DHmake pearls refresh command or into this package, into this ugly package check script so I don't have to remember to run it separately and type the long command or grab it from the shell history. Yeah, that's actually what I don't like about it. The command line is too long. The command line is too long. Yeah, you have to write config edit and then specify the model itself which is a couple of words and I don't know. Yeah, yeah. The fingers resist to that. I know what you mean. Okay, that was not interesting. So we have one more minute left. Ha ha ha ha ha ha ha. I'm ready. Yes. Okay, so I guess we won't go through all of the items on the task page. Maybe we can put it in the minutes that people are invited to take a look at them and grab some, some are already claimed. Well, the last thing I'd like to stress is forwarding patches upstream. I know I'm not the only one who's not really good at this. So I will try to improve my own behavior but I also invite others to forward more patches. Right. Use the DAP3 headers for the patches and we now have tools that make it rather easy. There's this patch edit script from Joseph. I think it's already a year old or something but it's probably not well known. Makes it very easy to edit the patch headers. And this forward patch and forward bug scripts written by Alessandro are not perfect but the forward patch is doing its job. So I've spent an afternoon last week forwarding patches. It's really just a few keystrokes and then paste the URL and committed and it's done and I've received quite a few responses from C-Pen authors who said, yeah, thanks and I've already committed it and great. It was just that I got bored after some time because it's always the same and it's so easy but yeah, maybe we can take a common effort and get those patches out. Good. Yeah. Yeah, yeah, some ideas. We should do it, we should work on it. But I think we're running out of time is there's some famous last words someone wants to say to conclude the buff. Well, otherwise I would just like to say thanks for coming but long live SVN. For us boring old fads. Okay, and thanks for being such a great team. I really enjoyed it and yeah.