 Okay, welcome. This is the use pearl bath for deptconf 12 and We're online. I believe the IRC online which we had up earlier is a deptconf talk room, too And it's being this path is being led by Herman and Yeah, welcome Thank you Well, it's kind of administrative yeah, okay for everybody across the world Greg are and I are discussing which IRC channel we should direct people to I Think we should use one of them and not both. Okay, so I guess most people are in deviant Let let's use deviant pearl so that random people wandering by might actually be interested. I Will do that For those of you in Ulaanbaatar, this is me signing off good Bienvenidos No, there are no women at least in the room. Maybe it's home. Oh, there's a one camera woman. Oh Good so I'm confused Okay, so this is the pearl buff more like the annual Real-life meeting of the deviant pearl group For those following at home the deviant pearl group is one of the oldest and one of the largest teams in Debian Large both in membership, although we're not sure about how many members are really active But there are some 200 people Some 200 people in the alias project Large also a number of packages. I think at the moment we have something like two thousand and three hundred packages in Get repositories That's about I guess 200 more than last year something like that. They are They are just increasing Yeah What we should check in the beginning is who cares about IRC. I think that's David already and It would be very great if someone could take some notes and send them as minutes to the list afterwards Thank You Tim good and oh Is this about my volume why about the microphone volume? Oh, sorry. Yes I was just relaying from IRC that people cannot hear you here. Well, okay. I tried to speak a bit Louder, which is not so easy At 10 in the morning at the same volume He's saying that it's your volume. There's some there's some luck. Okay Okay Yeah, I'll be quiet now. Anyway, I think it would be nice for people watching at home to know our names so that they can Relate the names or the nicknames to the to the faces. So maybe we could start start with a very short introduction round Yeah Maybe if you want to start just say your name and what you're doing in Debian and Hi, everyone. I'm Jotun Junior Trejo. My nickname is JotunJR. I have been a member of the Perr Group since like 2010 maybe and I've been working since then Trying to Hi, my name is Salvatore. I'm a member of the Perr Group since 2009 Doing the regular work updating package bug fixes and so on I'm Daniel DKG. I don't remember what year it was that I officially put my name in the alley-off project and I haven't been particularly active, but I'm happy to do the little bit that I do and very happy that everybody's part of this project. I Am Tincho Martin Ferrari. It's my name. I've been not working in the Debian Perr Group since something like 2006 Hi, I'm Tim Darkly it's an IOC Yeah I'm not very busy I'm Ansgar and well recently I haven't been that active in the Perr Group because well I've been doing other things in Debian like running the F2P team and Yeah, I've also written the current version of P.T. I'm David Bremner, and I forget also, but I think 2008 No, none of us so Kusanagi asked on IRC does anybody do something in Perl and well Gregor does that that much is clear and And actually a bunch of people make packages For Gregor to upload which is really great, but not all of them are here unfortunately and I guess my Main contribution to the Perl group is Get troubleshooter these days So any kind of git problems people should feel free to bug me about them Well git problems in the Perl group anyway So I'll just comment on that as well in terms of it's not clear what the question was about doing something in Perl I know many of us are Packagers, but we also are users of Perl, which is why we're interested in packaging it So I think a lot of people do actually write stuff in Perl as well But this is more about packaging and maintaining Perl within Debian. So we don't need to go into much detail Well just Just let's finish the Yeah, but you have not It's gone, right Good Is Damian on IRC Okay, is he is he ready for the big thing might be it might be nice thing to finish I'm just asking Damian on IRC if he's ready to To delete SVN And he's welcome to interpret that as broadly as he likes So I made a small joke Because to delete SVN could be interpreted quite broadly especially with FTP assistant sitting beside me But no response from the seaside Okay, it might be a nice thing to finish off. Okay anyway We'll do it at the end of the bath, right? Okay as a kind of celebration So what we have here is this open tasks page which we have Cleaned up before that convent and Last week during an informal meeting We now have I think two sections we should look at one one is this policy discussion sections with three items we should decide upon and Well, then there's lots of stuff about transitions packages tools specific tools recurring tasks and whatever and The idea would be not to maybe Spend five minutes on each of them because we don't have this time but to find some priorities or to get to some kind of road map what we want to Do next year what are the important ones that we want to tackle next year and Which other ones are just nice if someone cares about it So if we start at the top the policy and discussion things Well, which one do we take let's start with the the last one. That's an easy one The the third one is the question about adding a paragraph about how we handle that being copyright in our packages In fact, we were using copyright format 1.0 since well We've used various iterations of that five before but it's nowhere written down So the idea came up to to write it down. So your daughter has proposed a wording for it and sent it to the list Yeah, maybe you could Clarify the state. Yeah, and they got some feedback from Gregor and Yeah, and then There was a one open point if the last sentence about the generic or Where else should be left out? But I think if all agree on the current text We can commit this this way and then adjust it later on if needed Since it's so short, maybe you can just read the current text so that everyone Here's it again. So the current text says Each packet should have the copyright file even copyright following the copyright format 1.0 or newer and copyright format 1.0 as we 1.0 is released together with even policy 3.9 trees documented at the URL pointing there All release copyright Specifications can be found under then the generic Which is a directory listing here Okay, so from the people here in the room are there any further comments on this Guess it's just documentation of what we are actually doing. It's just a higher Well, if I remember correctly the maintainers on the copyright are optional now So, I don't know if we are we will still have Containers on the copyright You mean maintainers that the copyright holders for Debian slash That's not optional. So it should complete include the full copyright information What I think was made optional is listing the maintainers who initially created the package. Oh You mean this the sentence this package was Debbie and nice, which is not a word anyway Yes by someone in 1900. That doesn't really matter for copyright information, right? I think it's not even in the in the specification anymore Like it's not valid. I think okay, so is there anything on IRC related to this question? I think So I guess we can consider this decided and Any what's the word in English for everyone agrees Consensus no, the other one Know that the adjective for everyone agrees and any Unanimity There appears to be unanimity right room. We are unanimous, right? That's the word. Thank you. Okay. Cool. So Salvatore can just Merchant push or whatever this commit good The one before Sounds also not so really difficult The question about which branch names to use in our get repositories For I guess it was for backboards or for testing proposed updates and well, so for Non-standard for everything else besides master prestige master prestige and and upstream it would be nice to use the same branch names I'm not sure. Do we have an proposal already What I have used so far for all packages is just the release code name So it usually squeeze except see life which interestingly has the branch named squeeze freeze Which is more like an error, but we kept it and Well for backpots it would then just be squeeze dash backpots Yes, the only problematic thing is I think using Experimental for uploads to experimental because it's more like a temporarily branch So basically you upload to experimental and do something else maybe or drop the entire line and Then something else and something experimental later, which is Should not be on the same branch probably So what would What would be a good way to handle uploads to experimental? I'm sure so for Actually see life was an experimental for a while Which is the 2.3 series and I just used the master branch because I intended to move it to a unstable it anyway, I Guess I don't see a problem with using the word experimental as a branch name even if a future Experimental doesn't come off the same line You can always just put a tag on the version that was uploaded and then Move the branch to be some totally different branch The branch itself is not fast-forward. Yes, that's right for experimental I don't particularly care that it's not fast-forward One thing is that right now most our tools and Automated to some automatic tools perhaps work on the master branch as the place where the most current version of the code and packaging are so One requirement, I don't know how it affects the proposals we have at hand at least we should Make this clear. We need to always need to we need to have the motion stuff in in the master branch at in time Not diverge from it in the experimental branch that would be more up to date that than master, I think Is this a PET requirement or what tools need? things on specific branches and Whose author should be punished That author PT doesn't really care though. It displays the current head by default, but you could tell it to display something else Well, another point is if we fork Experimental branch of master and do the work here there during the freeze. What's master branch for right now? It becomes useless the master branch could be used if there's RC bugs come up in the package That can't be dealt with in the newer that that when we can't upload the newer version Well, you can fix those bugs in the master So that would be for bugs we can fix for going through instable, right? Okay, and for bugs we cannot fix by going through instable the that would be a wheezy branch Okay, fine with me the only problem it sees that as much as I remember how pet is still working, which I'm not so sure but They have you always have a default branch your following. So these things like some proposal of the uploads branch will not be Properly reported in bed. So maybe we will need to To do some some extra support for them. It was also problems since the very beginning with that Well, it's a problem that we have mainly because we've successfully migrated to To get right I mean we didn't have the problem because we weren't Okay well It doesn't sound like there's any concern with just on sketch proposal of just using Just using the release names, right? Right? Using the code names and so for the proposed updates that's going to be squeeze dash proposed dash updates Just squeeze Squeeze proposed updates is anyway. Just an alias for squeeze No, actually the other way around but I usually use just squeeze and uploads sir And it ends up there anyway, sir Okay, so branch names Release names and this experimental versus master stuff I'm not sure but it seemed the consensus was that master was for unstable That we essentially had some mental map of branches to sweets Okay, just want to relay from IRC that Jonas is asking for short names, please Right shorter than squeeze Squire first letter of the release name. Okay, so That's it cool Yeah, and the first Point is about how do we Deal with the state with the state that we are frozen So shall we upload new stuff to unstable? Or not or experimental or whatever two years ago when we were sitting this huge auditorium in at Columbia University in New York We decided that we will in general go on and upload new upstream releases to unstable Just because we have something like between five or ten of them But per day and it doesn't scale to to stop our work for half a year and And then find a huge pile of I don't know how many hundred packages after six months With the exception that we tried to be well a bit careful meaning not uploading Yeah core packages which had many reverse dependencies which already Headbugs and needed to more care In the last years, so we did not upload something like live DVI pearl Stuff like that and I think it worked out quite quite well. I think we had to go through testing proposed updates for two packages and Well, the rest was was fine after the freeze when the migration was activated again There was something like between four and five hundred packages migrating at one day So, yeah, it's the question do we want to make it to do it the same this time or something different? But this is not in conflict with what the release team was saying yesterday Not allowed to unstable If it's going to go if it's not going to go into with I Guess it it might be and we could make our plan tentative on the release team Not telling us that that's a terrible plan We could also find someone from the release team and get there and get their permission to say this is We could I mean if we can we could just find somebody here and say hey This is our plan. This is how it works two years ago, and we would like to continue that way well what I Shortly told yesterday yesterday in formal informally with Adam And told him yeah, we would like to do that again this way, so it seems it's okay So okay assume as long we respect this rule not to update Critic Critical packages, which we know are Perfect, thank you the large problem with updating packages and unstable doing the freeze especially that it Can affect other packages, so the obvious case is the library where you change the so-name Then every dependency will not be able to be updated through Through unstable the same happens if you just add symbols in the library and they are actually used by other packages then This is a problem. We have not have that much with bullets Only when the API changes in incompatible ways and the suggestion was in a way to Not upload these changes if possible Okay, so I'm just going to ask IRC for comments Two people on IRC say it's great, so it must be great Okay, cool, then let's stick to it and thanks again Salvatore for asking Adam Makes it safer Good, so we have decided everything and we have well almost 20 minutes to go to the next step to all the ideas tasks whatever we want to Add a priority to in three would you like to take over do you want the headset? one two works, okay fine, so First of all, perhaps it's time to ask if any anyone here has Something that should be discussed In person that would be in that was not in the list we had in the wiki looks like It's not the case fine so well What I would love us to do right now is to pick one or a few action items from our huge to do list open tasks page in the wiki and And say okay this one we single it out and we would really like to to To be able to to erase it from our to do lists before next year's depth conf for example There are a few relatively Big tasks such I think mainly the ones that we have a hard time dealing with are the ones that require writing on our maintaining our own software tools such as DH make perl package check and bet and There has not much There has not been that much Work done in that specific topics last year, I think sorry if I'm Sorry if it's otherwise so my proposal would be to pick only one of these three ones and Say that's realistically we won't Work that much on all three at the same time so we could perhaps just pick one and say okay How do we make things happen and? package check or on the bet or whatever As you're feeling about that So you're asking for feedback about if people are okay with choosing one and trying to stick collectively to working on that one Yes Well, not to stick it doesn't prevent anyone from working in other bits, but We're prioritized one of our eyes And try together to to build some collective dynamics that May be useful to so that other people get motivated and start doing stuff, too Do you have in mind which of the three you'd like to propose as the priority personally? I don't feel I'm competent to to to know which one is the most Important one right now for us for the biennial Perhaps pets but so in our pre-buff buff We we wondered about if it would make sense to have pet as a Debian package and I even thought this was a good idea before I realized it was a web application What do you think Well, I'm sure because not many people will install it anyway and Yes, I don't know how to package web applications myself so I Think almost no one knows how to package web applications, but there's a couple good examples for packaging web applications that are in the archive I actually think that's a Man I can I can point to some It's not a trivial It's not a trivial task, but I do think that it's worth doing particularly if we can do it in a way that we think is good To demonstrate how to put a tool that we find useful into the archive Right, but one of the problems is that should we move PT to alliot like we planned last year But haven't done much about it Then we wouldn't be able to use the package ourselves Deck for example has a similar problem because well sometimes we are thinking about it would be nice to have a package for it But we probably wouldn't use it ourselves Why Because we cannot install packages on alliot ourselves we would always for every change need to go to the alert administrators so Who are the alley off administrators, and why would they be resistant if we if we demonstrate that we have decent packaging standards and we And we make sure to backport the package that we want to squeeze Why would that that seems like a good thing to do? On the other hand there's always the possibility to use the package dash X To extract it to a directory and use it from there So you are almost using the packages you are not using the maintainer scripts that come with it But you're using the stuff that is actually within the package and I think that would be a doable compromise Is that much different than not packaging it because you don't use the directional layout or a patchy configuration that the package would ship and Yes, going through the earlier that means well the main problem I see is that it's causing more work for them because we always have to back them to install things the work that we're asking of them is Can you app get update app get install pet slash squeeze backwards, right, which is not a big task Yeah, but you cannot fiddle with it The life systems and which people sometimes do Yeah It's supposed to be good, but I I think packaging it would slow down development. Okay, you can hear me If if the main reason for packaging it is to get a bug tracker is there any possibility we get a virtual package to file Bugs against pet anyway, or Well, technically, there's the alley art request tracker, but I don't really like it myself Okay, but that's that's awful. So But we could surely talk to the Debugs people and or whoever and and get a pet dot whatever virtual Probably yes, but I think don't would like to do so only for debian.org services So we would need to move to debian.org first and install it on earlier I was going to suggest exactly that I think it doesn't Make much sense that the effort of packaging and keeping it in the package Install in the machine, etc. Just for the bug reporting. I think if we if we want bug reporting So the bug is a lot better and Regarding the the thing about using it using as a package application It's good if you want to to not be developing all the time in life system, which is usually a good idea But also at the same time the current version of pet is not really is probably not really useful for anybody Who's not debian? I mean not not you're not going to install it in your personal machine product So maybe it doesn't make much sense to Spend the force on that At least maybe it shouldn't be a priority Which was where we started this discussion and I think if somebody Wants to package it and great, but Yeah, I also wanted to say I think the question about pet is more That we as a group heavily rely on it, but the fact though it's only Written maintained by Ansgar mostly because it's in python. So I think the question about pet is more hard Do we get more people? Involved to help out Ansgar About bug tracking There's not only the possibilities of using alias or Bugs do you know, but there are also some standalone things like simple defects We would blend in to the version control system it always depends on who you Think might be reporting back and who you want to report back so Maybe think about other possibilities, too Well, if you want to install or our own backtracking software would need to run on aligot And I'm not sure if installing web applications. There's a great idea because I have already seen some groups using totally outdated wikis Which had security issues and very basically full of spam Simple defects is not a web application. It blends directly into the version control system. So it's Directly with the code we have the bugs next to the code and it's distributed backtracking system Okay, that would be fine with me, but the problem is always well people need to use it so I Will say also in general having a nice System that's the BTS. I wonder if it makes any sense to start using new tool I'm I'm pretty sure it's not such a big deal to have another little package in in fact mentors dot DB and net is already an Example of a non-demian org service, which which is got a pseudo package and well Well sponsorship requests Okay, it's not about the service I don't know that this is the best that is the best we can we just need to go find on and talk to him about it Agree, so if we if we think that a pseudo package is the right. So should we pursue a pseudo package at least see if Don likes the idea. I will I volunteer to do that It's done then okay, so Oh bug tracking is sorted out cool and Well, we about pet on this page. We have packaging. So we have discussed this already We have some infrastructure issues about who has access to the pet that runs the box that runs pet and who is allowed to restart it when it needs some hand massaging and What could be done to solve this next year? Yeah, that's mostly moving to Elliot again Or people asking me to get access. I think that two members of the program who have access Surprised Well, and I think well, there's also the database alone if you want to access that you can also Ask me and I can well Allow connecting over the net from a static IP Just a bit from the past We used to have an automatic Post-commit hook that will export the files when there was a change and put it live immediately That can be done with a branch. So it's not immediate So you can have a development branch and a stable branch and they have automatic scripts that Avoid the need of having somebody to have permission in the machine, etc Where there's also a development version on the host which is actual pt-devil.devil.net Which currently runs the same code it's for testing out new things in the web interface So it's easier sometimes when you can just change things there and currently this issue that Scanning watch files sometimes hangs. So you need to kill the process by hand so to sum up to be two per two members of the group have The can do that actually to restart it by hand, right? Yes, I think so cool. Is it a big secret to tell who they are so that I have to look at myself Salvatore just raised his hand. So I suspect that he's one of them. Yeah, he's one of them So if we feel it's enough to solve the probably this was a non-issue then and we can just drop it from the list Looks like we're fine. And the last Parts of this about pets and this page was about adding new features so well One thing is probably to list new features we would need here in a way that they can be prioritized and Then that sounds like the BTS probably Yes, probably and then finding actual people to do the work. I have no idea How were How the very original pet developer feels about adding new features are acting as a maintainer who would review pull requests some people would send Or if for example, if we find someone from say the Haskell group and say hey, we use Pets to we need that feature What do I set them? Well, what the workflow? How How do they contribute? Well, I Don't have that much time for PT myself currently. So I'm working mostly on other things but I'm fine with merging changes and reviewing them and Well, and then handing off full permissions to other people as well. I think it's hosted on Elliot already so you can Comment there if you are a member of the PT group. Okay Mmm, do you think it would be a good idea to go reach the other groups? We use PT to Ask them. Hey, do you have there any bugs you suffer from or features you need? Do you want to help maintaining this piece of software and stuff? Anyone who wants to do that? I do We only have three minutes left. So if I think we can close their PT chapter Anything left to say should I prepare damn for his ceremonial role? Okay, one thing that isn't the least that might be need to be agreed is the the project member being I don't know if it's controversial or not. Yeah, thanks for reminding us when René also said we should talk about it he is not here The idea to ping inactive members, which you answer have done at one point Should we do it again, maybe some regular intervals? Well, I'm not sure the problem was that I actually did not finish that I Think I have somewhere file, but it's now totally outdated. So I did ping them and some people replied that they No longer have time or so as some people said they will do things in the future. I think some are also have But cleaning up their accounts. I have never done actually Yeah, so question one two we want to do this in the future and question two who does it? If if one equals yes So it's a bit difficult to coordinate Here cuz damn doesn't have video so he can't tell that we're not talking about His project right now. Oh, but maybe we should just Tell them to go ahead with the removal and and all of us who dearly love as VN will shed a tear If any such people exist Okay, so big celebration of one year after moving from as when to get them sitting at the beach in Bulgaria, I guess Will now remove as we I mean our Right Dak RM as VN is later today when nobody's looking Good so coming back to the membership ping what are the feelings in the room? Is this something that should be done Is it a burden? I mean it looks a bit funny, but does it cause any practical problems having lots of members in the group? the only practical problem is that membership in any alliot group gives shell access and Well, I don't think most people mean harm, but of course if somebody gets access to the account of somebody inactive it Means that they can log in on alliot if they want to Oh and times out so maybe we should discuss it on the mailing list later anyway or in the hack lab Okay, damn says it's running now. So thank you everyone and sorry talk myster