 So this is the use pearl buff or whatever. It's called annual meeting of the Debian pearl group. I think it's the third time we are having this we started it in Argentina last year we even had two meetings in cathedrals and Well, I Submitted the talk to penta so that it's there and that we get the get it scheduled and that we get it video teamed For all the people who are at home and hopefully are awake Apart from that there's not much I want to Say now and I will leave this position here because it feels rather awkward for a team meeting to stand on the stage What I have prepared is this this Copy document so that we have some kind of Structure I would like to ask you to Help me in taking notes or to maybe actually do the notes taking Is someone familiar with copy? Jeremiah. Yeah Cool, thank you Okay, someone should probably also follow Hashtabion pearl on IRC That's where the pearl folks Hang out Damien was just asking if there's something going on David. Ah Right. Thank you Okay, and on the wiki page there is this Debian pearl group open tasks Page which is well there since three years or something just for collecting ideas Which we can talk about now I've copied some of them out and I can well I can offer to lead a bit to the Through this session. I can also offer to to take this copy thing afterwards and write it Into or bring it into some readable form and send it to the mailing list Yeah, and I think now we can just Start what I would like to start with is what's called introduction here. Okay. Oh That was not my plan Okay, I go away Yeah, let's let's move together a bit Thank you perfect. I think it might be nice for the people following along along at home to Connect faces to nicknames. So maybe we can just Say our names and wave into the camera It's a short start. So I'm Gregor I'm Chris Bay. I'm Jonathan or noodles. I'm David Bremner. I'm John lights. Hi. I'm Jeremiah Foster I am Roberto Sanchez. I'm Bertos Sanchez. I go by El Cubano and IRC To this book. Oh, yeah, I'm Tim I am Jonas I go by Jonas and I see when I'm seldom do they're My name is Matt Zagrabel me. I'm Jelder or Jelder on the IRC. I am not part of the team, but I'm Peter De Camillo Some people are hiding in the back good Well, we could maybe start with the first issue It's also an annual question about we see s use usually it goes like this that some of the Younger enthusiastic good fan boys I'm totally objective, you know That some of them more progressive guys come up and say hey why we're still using SVN and then some of the older guys are asking well Has anyone figured out how good works for one house? 1700 packages and Then there are some people who say they will look into this issue and try to Try to See if it could work. So I think the question is has there been some research in the last year Can someone say something about it? Yeah, I don't know if anyone else has looked at it recently, but I looked at it last year and actually I've given up on Getting good to work for the moment. I mean I just trying to put scripts together that clone 1700 capabilities or whatever is quite difficult to get it as quick as SVN That's what I found anyway. I Think It's I'm not I'm not saying it's impossible, but you know someone has to actually care about it enough so as far as Get with multiple packages, I know I maintain shore wall which has about a half a dozen Different products that upstream releases and I had to hack together a shell script Probably should have done in Pearl, but I picked shell that was what was what just made sense at the moment to do it and it I Mean I make it work, but that's a half a dozen packages So I don't know I mean I'm If you would have asked me last year, I would have been completely opposed to using it But sure while upstream has gone to it, so I had to move with it and and several of my clients use it And so I've had to learn it So I'm not opposed to it, but you know, we need to figure out what the technical challenge is I don't know does this get allow you to like, you know with SVN you can check out Like just a directory So if you want just the one packages or something similar we get or do you have to clone the whole repository? Yeah, you can check out single items you can say get check out foo and check out a file So the thing is that it's it's quite tricky to do that Yeah, I mean the way we work at the moment is we have one big SVN repository and I Think ideally if we are going to get then it would be I Mean I'd assume the bit the way we do it would be one repository per package Do you reckon? Get get check out foo and change the branch Would it not? No, I think you have to explicitly say you change a branch How big is the SVN repo the just the check out checked out copy? Trunk has about two gigabyte at the moment What I'm one of the fanboys just to reveal that I I thought that there was someone more clever than me that was also already working on these kinds of things But but but if the ones I don't know if you were with the one of those working on it earlier on like last year I heard that oh some people were actually hacking on this problem Maybe I'm actually then stepping up or something to look at it because I really want to continue working on it But one of the things that if you're measuring speeds is that when you're when you're doing a check out of get Packaging in packages 1700 packages Then you are checking out all of the history when you're checking out subversion You are not checking out all of the history and one of the things I would try What would be to there is a trick to say check out and don't Pull out the whole history only check out the latest ten revisions or whatever layer you want What depth you want and I believe that means that you cannot then later on edit on something that wasn't checked out yet I don't think it's something you can then Roll work further on that's one of the flaws of that But you can you can certainly build a part on top of it You cannot do all the juggling anymore you lose something and you need to then check out at deeper depth But that was one of the things I would work be working on but but if you there's some clever guys that have See me clever that has some experience or some tried out some scripts and something I would be happy to have those to start out from instead of starting from scratch But now to to clarify the issue really isn't get itself, right? It's get built package So I have a question from Ansgar on IRC and he asked do we need checkouts of the whole tree and I Guess that's sometimes we do we have the the habit of doing global changes occasionally But when we need them, it's quite important. We do need this, right? I agree that we need we need to be able to check out the whole tree and work on things across the packages Not the thing kind of things. I have been working on but I certainly know that others need that and But but normally we would need the logic of get is Fundamentally that it it has just it has don't have a work in revisions It works in in in deltas. So you need to have the roots To have all deltas. So I calculate all possible deltas So that's the reason that when you check is when you when you clone like it when you pull it down You cannot say I only want to have the latest revision You can you can do that, but that's like a heck. It's not really how the guitar is working fundamentally Okay, so that's one of the it's not a bug in kids But it's just one of the fundamental differences in the approaches to version control that is in suppression again I don't think we should go into the deep depth of what is the difference is here because it's not it's not a competition I think it's just that if anybody if the fanboys is want to want to try have solved this issue of Do something that that the old guys can approve that it's working for them, too Then we could try that out and if the fanboys cannot solve this issue then we should just stick to subversion It's not it's not obsolete subversion is only we're only discussing this because us fanboys want to switch, right? That's the only reason we're so I I'd like to Reiterate a comment damnate, but he didn't sign his name and gobbie, but I can tell from the color Is that really this discussion is premature because we can't work Seriously with get until we have the entropy tracker running for get and so I think the first step for us get fanboys is If we want to devote effort to this, that's where we should focus is getting the PET working for get repos because We already have some Things in get and it there for non c-pan modules and that works fine except that It gets left out of our usual Workflow and so I guess that's not fine really. I mean I was just gonna say that too In my opinion non fanboys reasons to move to get are nowadays. It seems that more and more Upstream Pearl development is happening on places like github, you know, and that kind of makes it easier to Hook into that and second Get seems to be a lot more compact I mean I tried to do a full SV and check out once and it's just a huge amount of this space It takes up while an equivalent get repository seems to be a lot more You know just friendly So for what that's where? Github it seems to be the place where all the development is going on lately. I think I forgot what I want to say Well, I'd like to sum up this point a bit because it's already 20 minutes into the talk I guess we are we are the similar status like last year or the year before So if If there's a path to switch then we can consider switching it which would mean we need the tools and we would need a migration plan so the question is still is there someone Interested in working on it Actually, yeah, I agree with this point from down that Maybe the first step is actually just to get we do have a few things and get a wordy if you can actually integrate those Then that's much easier Just a short comment Ansgar has been working on Pet to or something with multi Where's the source code for a path that CGI located? It's an Elliott. It says separate project pet or pet you will I would look at the stuff Ansgar's been doing. I got it running on git and It looks good actually and the code is a lot cleaner But obviously we've got to we've got to finish that off and actually get that deployed first We if we can actually get the stuff we've already got working then Scaling it up to everything is the next challenge. I think we could also do it gradually right and and Move packages. I mean if it's seamless whether packages in git or SVN, which I think is our goal Then well, we'll move things over and by the time we have everything moved over We'll have the scalability problem figured out Or we'll really be in trouble I really don't use IRC as so and the pet is tied to IRC as I understand it so You don't need HTTP interfaces with git, okay, but I Would I would like to step up? Hopefully not alone to work on the The speedy of the speediness of the handling the packaging itself, but I don't think I will not step up I'm not capable of hacking the tool. I don't use it myself and I would need to get used to that first So I would be need to be dragged into the pet Development, you know my email you can get all of me if you want to convince me But I would like to step up and take over the the try on speeding up the packaging handling itself So put my name on that but not the pets Actually, he didn't volunteer for pet hacking He volunteered for git not pet hacking. Yes Okay, so I guess if this working If there's some progress we will get the report on the mailing list and then Then we'll see Thanks for your offer. I'll look Yeah, put me down for some half-hearted commitment as well Cool, thank you, David. Okay, so this next Issue I'm not really sure if this is an issue. It's also something we've been Discussing since at least Argentina Someone asked in the mailing list today what this was all about There was a time when some of us were not really happy about Module install because it's copy itself copies itself into each and every Module which is could copy on the one hand and which also carries around buggy versions for Months that are fixed in in module install itself, but not in the modules using it So two years ago over a beer. We had the idea of maybe Making Unhappiness public It has never really happened. I'm has already written here that Well, maybe talking to the author would be more useful. I Don't know if this is an issue for anybody anymore My my impression is that module install use is going down that this tiller is going up and well Do we have any measurements of the actual use or possible easy ways to Directly measure who's using it? I know my CDBS packages, but I can count them by hand, but other than that I don't know if I'm up to speed. What's the problem with module install? and It's old. I know our people using build I Was I was just making a derogatory comment about module and so on now I think it is actually relatively new and there were some upstream purposes to quite like that, but the problem with it is Co-copying really that's the duplication and the old bugs and all of that stuff. I think I Think DH7 handles it especially I forget how we how this actually works In generally This is about module out to install that depth help us in 7 to 13 sets the correct flexor Module out to install doesn't try to download anything I mean if someone so if are we because so the question is are we still going to write this letter or is it? worth just Leaving it. I'm happy to help with them drafting that But we have to agree whether to do it and what to put in there So Pearl has I think a complicated set of build tools make maker make install and make build and I don't know if they're evenly divided in the pearl community Between those three, but I do think make install and module build are more widely used Adam Kennedy is a very prolific and hard-working developer who has strong opinions naturally and works a great deal on The windows platform, but I suspect that he might not be so keen to have some kind of public broadside Against him, so I think I definitely think talking with him first would help How about how about actually turning it into a positive kind of spin and Writing letters supporting module build or something like that If I remember correctly some of the Toolchain guys, I'm not not sure if it was Adam or someone else was in the Debian Pearl I see channel at some some point and he said well, yes, please tell me what's wrong with it and please let's work together, so Something like this open letter we had in mind two years ago is probably really The way not to go so if someone has some strong issues then Contacting the authors Well seems reasonable well, perhaps one way of doing it is to you know in order to keep it positive is to have some kind of Article or something in some widely read Pearl forum of like how you can help get your module packet for Debian and Like the kind of things that would help us along so that they get promoted as best practices Things I module install just fall away because Yeah, so the the package Ruby team has on on their page they have a Like open letter to upstream. I don't know if you've seen it But you know it's basically if you are an upstream developer of a Ruby module Here are things you can do to make it easier for us to package for Debian and we should probably do something similar for Pearl Right, so do we get we know if we can as a grouping come to a consensus as to what we think best practices are You know capture that all in a web page and then start Spamming you know for lack of a better term that the URL to that you know out into the pearl community where people are developing modules And hopefully I'll see it and that'll you know help make The quality of the pearl modules better for everybody and then also easier for us to package into Debian So I have a question from dam on IRC. He asked is module install still a burden To to the heroes of the day he writes which I presume. I'm not sure if that means us in the buff or or what? So I guess is this still a real problem. There was some discussion of this earlier and Right Gregor shakes his head in my opinion. It's not not a real problem. It's ugly to have those code copies flying around but Well, so be it and regarding this this best practice stuff There are some checks in the in this quality or however that's built Okay, k-w-a-l-i-t-e packages and Gabo shavo However, his name is pronounced correctly is always very interested in working together with distributions and getting stuff in there Yeah, so that's also a good way to go but in my personal opinion. We could just Take off this module install Be done with it Unless I mean if someone wants to to draft some best practice recommendation or whatever that's always fine, but It's not Worth the group a group effort in my opinion What do you think is really key? Or what should be the high priorities for the group effort? Do you think that's a good question actually? RC bugs. Yeah, I guess The immediate stuff is fixing bugs in the long-term stuff is is keeping the high quality of the Of the packages Which means making some changes over them Following best practices in Debian packaging. I mean, it's the next question actually Okay, so let's move on good The next one is about Proposal I sent to the mailing list about adding a paragraph to our totally internal Debian pearl group policy I Don't know how many people have read this That was I think yeah, we had a kind of kind of sides discussion and Salvador replied to it Okay, so I will put it on screen No, it won't be large enough for For people on the video stream. I think I think that's on Oh, they've got a link. Okay. Just click on the hyperlink in the video stream Wait, well, no, the question is how many Old versions of dependencies do we want to support? So like in the example where we if a Module needs test more larger than 0.88 then we write it as Pearl larger than 5.10 1 or a little simpler Okay, and the more or less common practice so far was to to add versions to dependencies if there is an older version of the required package in Old stable unstable and to remove the version is if there is no older package anywhere and also to write these alternatives if Well if pearl in Stable and all stable doesn't Have this module included Yeah, and the idea is just to to write it down that let's write the versions there as long as they are Available and otherwise just keep it just to make it very clear also because of our these discussions on the mailing list I Completely agree with with this part of the proposal of this this proposal It makes very good sense to me that to to say that the limit where we cut off is When Debian do not know do no longer provide support for the packages. We no longer provide Fallback mechanisms for the packages. Is this something we we already do anyway, so Just a clarification and then and reaffirming rear Since hardly anybody replied in the mailing list. I thought let's ask here again before I commit it Okay, then I will commit it afterwards It would be good. I think if we could clarify exactly what this means for end users I think some people will come to Debian and say, okay, I want This module it will pull in a bunch of modules. Maybe one will be missing and they'll have to go to an older version Maybe we'll want to make that clear. I Think you are touching the other part of the discussion now if we actually support older versions of the system because this really is just a Theoretical things of others borrowing our packages and then they have to deal with however They want to want to have things working or people cherry picking a package from a newer and then running old stable So this is this is not about us back porting to stable or making them. This is a different issue I think if I understand your question greatly, this is this really does not touch any of the issues of people mixing across distributions or across time Let's keep that secret separate not secret separate Yeah, but we can also look into this issue. I know that's important for you As I understand there was for this for this other issue of how far back do we want to Support back ports or back portability of our packages There are two styles one style is we don't really care unless we are really lazy with our Packaging which typically works as finer to And the other one is like we want to keep back portability and we even want to hurt ourselves a little bit by doing so a little more details is that a Depth helper 7 depth helper 7 points different sub versions of that provides improved handling of for instances what we just talked about before the one of the Make make maker. Yeah, make it all And that was added in a fairly recent version of that helper a version that is not in the current stable Which means that if we then want to ensure that it works correctly Then we want to Limits to only working with this current version of the people which means that we cannot just take that package and rebuild it for stable anymore It will work in binary packets from unstable will work in stable But the principles of re-compiling packages in stable will not work It will break it will require a re a backport of the help itself to and then we can go into details of saying well Yeah, sure, but people can dust the backport depel but on that is always back for backpots.org But backpots.org is not Debian. It's not Debian stable. So We could try to make a different kinds of cuts saying that we support these kinds of unofficial Mixtures of packages. I really would suggest that we just focus on how much officials Debian do we support and and keep the discussion to that and I imagine that it's pretty simple and short and saying that well, I'm a fanboy of backpots There might be one more fanboy of backpots. I suspect that the common sense would be hey Most people use their purple most people want to use their purple 7.2, which means the discussion is moved We really want to use funky new features Bam if only all of you used CDBS There would be no problem because it what it has been working correctly with all also with the other make-maker tools since 2004 Yeah, just holding the mic Yeah, the question it is how much do we want to hurt ourselves at which costs do we want to support the Possibility for backpots. I also guess the consensus is Supported where it's easy, but don't hurt ourselves too much by not using new tools that make stuff easier I think I saw a discussion about this on RC a couple of months ago and about backpots and I think it would be really interesting to Routinely backpots our packages automatically something like that, but Yeah, maybe we should fix all the RC books So so Ansgar has a question on on IRC and he says aren't there plans to make backpots an official part of DBM anyway anybody Yes, so that would be a point at which we would presumably more Interested in supporting it I think from what I heard which may not be all the details back ports or will become Part of the you know Debian family officially we won't be supported to the extent that stable will it'll still be a kind of Unofficial kind of thing is just in terms of infrastructure and so on I think they Yeah One one thing that I know are currently is Hitting this just does a practical concrete example is this about if you're using a specific make a build Mechanism then and I'm using their helper then you would want to limit hurt the back portability What I would suggest that we say is that in general if there is no Explicit reason for limiting bad portability, then let's be open to backpots Which then allows us to later on make funky? Routines to try to backport and then we can take which packages did not back for for each reason Oh because it uses annoying Builds mechanism and that's maybe one brick two in the get rid of that system, but but it could be different As I said TV bears is working since 2004 nicely, so hit me again. Okay, will you know, but it For the when we were running Lenny and it was backpotting to it We had different problems of different reasons that people were ticking the newer versions That was the whole rewriting into short form DH that was so that was a nice tea You could say it was not a necessity, but but still it was a same thing that didn't hurt us that was that much So I'll just I'll just say let's keep it open in the future What will be the reasons for for tightening and if there is no explicit reason then don't just Routinely tighten packaging because it might hit something Yeah, it's difficult to disagree because it's very good argument does does one point I'm not so happy about and that is if you keep for example that the app helper versions and features Down for the packages that exist and then you have new packages Which are created with a new app helper version, and then you have packages which are created with an even new app helper version then you have a whole generations of variants of Debian rules files in the in the repository and and Well, it's a bit annoying Jonas is gonna mention CDBS in a second And CDBS hasn't changed since 2004. No, that's that's the main problem with it Okay, so any any conclusions on this Yeah, yeah, yeah, yeah that that one will this was this was the next discussion yet, okay Yeah, then Damian also wrote it supporting old stable when not hard is preferred until it hits Okay, good Let's go to the next question That was yours Yeah, I just wondered Now that we've frozen do Does that does this affect our workflow in any way? Do we continue to Upgrade things in RSV and just waiting for squeeze plus one or Do we put hold on that and start, you know squashing bugs more Release candidate box, of course always comes first case But I mean I don't see any reason Technique it it could really be shortened down to read the release email It has details instruction on how to deal with this current situation of should you then stop working or should you Not release our packages anymore And even if we have a package that we would really like to have in squeeze There's still chance to do that the change now is that you need to Convince someone else. You are not anymore just relying on the systems of 10 days And in unstable so but but read read the email that it really applies to pearl too I don't think we need a special style. Oh, I think that there's two bits in that one is Should we push new packages to unstable? I would say the answer to that is definitely no in case there are problems that come up that are going to be fixed by a minor patch There's a question then about should we move on full steam ahead in SVN so that once we release we have stuff ready to go I haven't done anything complicated with our SVN thing, but we don't do branching or anything like that. Do we? so it may be that the way our current setup works it may not be a good idea to do it because if We end up having to do a minor patch in a package. It's already an unstable Then it may be a case of rolling it back that might be an argument for the fanboys to use a bike kit So so something to to consider there is I mean I was gonna say something similar to what you said about We probably should not be uploading new upstream versions to unstable One of my other packages that I maintain upstream. I've been working with them They just released a new release last night and then you know today I just didn't get around to packaging it last night today squeeze frozen It's you know, it's a couple hundred lines of diff So I sent the diff to Debbie and release asking, you know for pre-approval So I think in cases where we have modules that are historically not buggy You know if a new upstream comes out and you know, it's a relatively, you know easy diff I think for those cases, we you know, we can probably just take the diff email it to Debbie and release and ask for a pre-approval For for a new upstream they'll do that. We're still pretty early in the freeze now as we get later It's gonna get harder, but I mean I don't I don't see why We need to I mean the worst thing they can do is look at it and say no You know what? I mean so I so so all I'm saying is you know You have a package and a new upstream release comes out And it's a few hundred lines of differ or whatever something that's simple Maybe just documentation changes, you know We can always ask and that way we can continue the work on some level without just bringing everything to a grinding halt Yeah, I was gonna say that I think the the the release managers are mainly gonna be you know Concerned about things that you know really drastically change the dependencies So you might have some chance of getting like little Individual pearl modules that don't depend on anything that might You know that might not be such a that is such a problem getting things like that in but Well, also every simple change we throw at the release managers is time taken away from them looking at that a more complex Release critical bug fixing thing So, yeah, we look at it when we go. This is a hundred line diff. It's mostly documentation If it's a hundred line diff mostly documentation then convince me that it's important enough to actually race the release team's time on it Yes, it's a nice But if it's not fixing a release critical bug I would argue that we should hold off The principle of the phrase is we're trying to get released rather than trying to squeeze everything We can't end and and they're already overloaded and I was just gonna add one more thing that I think that one thing We should try and Try and sneak in if we can is a raccoon What with the? Yeah, Raccoon of star just came out and it would really suck if like the next, you know, one and a half years We didn't have But parrot I thought was up to date Yeah But I mean if that's the you know, there's nothing depending on it and Because it's new code that shouldn't be a big problem five minutes. That's not good Was a bit confused by the discussion before I think There are two issues do we want to get something to squeeze and I agree that it's not worth overloading release managers with some Pick our battles, but but but the other interesting question is Do we still upload to unstable? Are we taking a holiday for six months now and historically for the last two releases? We have just continued to upload to to unstable It can lead to problems if we need to fix it back in testing, right but it was very rare and if I look at the At the amount of new upstream releases we have I guess that's around five new day or something like that and we have The freeze of four months, I mean, I don't Don't think it's realistic to say, okay, we don't upload anything to unstable now wait until Christmas and then upload thousand packages That just doesn't work. I Guess it's important to be careful. Maybe not upload a Critical packages where which have many are depends But just stopping to work Doesn't sound like a good idea SVN. Oh, wow, that's really loud SVN does have branching. I mean it doesn't have merging, but it does have branching Well, if it's a case of we're worried about an unlikely meeting to Diff against I guess we can just check out an old version or something and work from that I mean, I'm just thinking should we do something now? Should we take a snapshot? Should we branch off a trunk a squeeze? I mean I'm a good person, right? So even doubt branch But that's the first stage of every get workflow is branch Yeah, I guess that probably is a good way to go because in reality You know, we can always go back to whatever version was in testing, right? Or isn't testing if we have to fix a bug in testing branch from there and In reality, are we gonna have to merge? Probably not and if anything if it's like to fix up a new bug that comes up, you know It's it's simple and that these you know at this point We're talking probably like max 29 line diffs if we're gonna get past the release managers with it You can diff and then just apply it, you know to the head and in a stable So it's kind of a clue because like you said there really isn't decent merge support and subversion But yeah, it probably makes sense to do it to just plan to do it that way that if we need to we go back to whatever version Was in testing this branch off of there. Yeah, I mean that that's what we're doing for first table proposed updates That there's a branch as Lenny which has don't know five packages now Or maybe it's ten because we've added three this week Ansgar has anything that uploaded them Yeah, that works fine for these cases Okay, anything else on squeeze freeze one more SVN ignorant question So so it's no problem to check out an old version and branch from there No, no, that's no problem. They are all tagged. You just copy the tag to a branch Yeah, I know it sounds weird to forget people copy protect the branch, but it this works Yeah, as long as you don't merge afterwards, right which we don't plan to so it's fine Okay Yeah, something like two minutes Okay, so this this list of work Tools well, it's it's in the wiki if you like to work on something do it But there's not really much left. So I'd like to leave the last minute. We have to Jonas and Some advertisement we have been asked to do here I'm involved in a in packaging a tool for LDAP administration called Cypux It's actively used for some years in Germany Quite some years the author the upstream author has used it before five six seven eight years something like that but it is the the current Major branch of it has been used for Developed during the last two weeks two years and used in school in New York in Germany there is one maintainer upstream and It could be super cool if this project could have some more help upstream in developing it is a This is considered by us in school in Germany as a very crucial tool to have at the moment for LDAP administration. There is only a very general Browser like tools to look around in in in a lot of structures and a PHP based Tool called goza, which is entering a testing now There is no in my opinion reliable tool to handle it up And this is just a little advertising if anybody could be curious about maybe looking helping looking at Helping out upstream with packaging Maybe parts of this Cypux some plug-in structure and stuff And working on getting it into Cp into cPan It is not currently in cPan upstream author wants the next major release to be fully inside cPan But he needs help with some clever people then We would very much appreciate it Okay, is there anything left we can discuss in the last 10 seconds we have Yeah, that that the idea was to to go outside after the talk to Give the video team our thanks and then some free time and do some more key signings for those who haven't yet Well and other than that, thanks for coming Let's continue working together. I'd like to thank Greg or for all his work for the team and damn Also, even though he's not here I'm sorry for the other people the things I didn't mention, but Yeah, what's great about debconf is you get to come and thank in person all these people who've done so much work for you So I'd like to say thank you very much Greg or I'm down