 So I'm going to be talking about DH underscore bus factor at this talk and I have even better slides than last time, as you can see. As a little digression, if you want to make slides like the other talk, which is all Zoomie, that's the program that you install, because a lot of people ask me about it. I'm sorry, I'm a little hoarse right now, too. So yeah, if you want to make pretty slides, use that and now one with the rest of the talk, I guess. So this is kind of about Depp Helper's maintenance model and how we can improve it and ever since I wrote it back whenever that was, I've pretty much been the sole committer. I'm sorry then. I'm trying not to pursue feedback or something. Is that better? Okay. Yeah. So ever since I wrote Depp Helper, I've pretty much been the sole committer. I'm certainly not the sole code writer, but whenever there's a bug, I'm generally the one who ends up fixing it unless it's a nasty bug that I ignore for months and months and then somebody else fixes it. So that's one thing that I'd like to address, but another thing is that if you actually look at Pergam's name, DH underscore, something that are in the WN archive and you could write some ugly Haskell code like this that loads in the contents file, looks for things that look like Depp Helper that are in user bin that aren't DH make because it's not Depp Helper commands and you make it look pretty and you ignore Depp Helper because it's not interesting for this data set or while you partition things into Depp Helper or not, you get 58 commands in Depp Helper and 99 other commands. So Depp Helper is now distributed throughout the WN archive in some way and so I've kind of been thinking about that. I mean, are all these pieces that are out there part of Depp Helper or not is a question that I would like to get answered here and I don't know the answer to it. And I thought we could kind of go over the list of some of the commands and just get some idea of, first of all, could everybody who's in the audience who maintains or is in team maintenance of a DH underscore command, a Depp Helper command that isn't in Depp Helper or one that isn't Depp Helper and you're, you consider yourself mostly responsible for it. Could you please raise your hand? So what, 10 people, something? So yeah, there's a lot of these things. I don't know if anybody knows what they all do. Most of them should be written to a standard, which is that it's a parole script that uses this library in this way and looks like this and has documentation. A few of them, where's the Haskell ones? Ah, there they are. Or not, they're written in shell because Haskell would be too hard or something. So we have a little bit of consistency maybe and they should all take the same options at least, which even the Haskell ones sort of do, although not entirely. And there's a lot of them. And I kind of think that's okay, but I've also noticed that lately, especially in the past few years, I'll learn of some cool new Depp Helper command that does something that was added to some new package named DH-something and I never seem to have even heard of the idea until it landed in the archive. And maybe that's okay too. You know, I'm not yelling at people for doing work. I'm just, it's interesting that people think that I'm just going to say no, sorry this won't go into Depp Helper and we might as well just route around the block and put it in the archive. So that's kind of where I'm coming at in this session, which isn't really intended to be a big talk. The idea was just to have some kind of a little boff thing and discuss this, especially among the people who raised their hand, but also, you know, just among everybody who uses Depp Helper and so on. So I've been struggling with the question of do we just let Depp Helper split up and do we say, say everybody who maintains Depp Helper is part of the Depp Helper team, I'm sorry, maintains a Depp Helper command is suddenly part of the Depp Helper team. We add a mailing list and you know, we talk among ourselves and it doesn't matter which package it's in, you're still part of the team. Does that sound reasonable? Everybody who has opinion, feel free to, does that sound reasonable? Raise your hand. Not many people think it's reasonable. Okay. Does the people think that's an unreasonable thing to do? I'm sorry, the proposal is to basically say everybody who maintains one of these programs is suddenly in the Depp Helper team, whether they want to be or not, and are subscribed to some mailing list. You're raising your hand that it's reasonable, oh question. Yeah, I think there's one. Sorry, Joey. That's fine, I'll just bring it to you. Hello, that's working now. So I guess my question and that would be, would you be comfortable with any of the people who maintain random Depp Helper commands for something that's basically entirely demand-specific, having commit access to Depp Helper? Because that's sort of the question the other way around. It is sort of the question the other way around. And I mean, in a way, things that are in Depp Helper are special in some way, or at least some of them are, because they're kind of the commonly accepted subset of stuff that we all use most of. And so I think it's possible that maybe the team, I mean, you know, if you have a real team, then the team should be able to come to a consensus. This command belongs in Depp Helper now, and that's something else that I wanted to talk about is, which of these commands belong in Depp Helper? You know, how many of these things, and I didn't get around to running the stats and getting a breakdown per command, how many rules files use it. But, you know, we could do that. And we could say, you know, DH auto recall for something is used in 10% of all rules files, and therefore should be in Depp Helper. And if there's going to be a Depp Helper team, then, you know, it seems to me that the team could make that decision. So let me talk about something else that's kind of background to talking about this, which is that there are commands in Depp Helper that I don't maintain. They're maintained by the people who contributed them, or the people who are on a desktop team and have the icons back in their head, or, you know, whatever. And, you know, they're basically responsible for it. If I get a bug, I just forward it to them. And so, looking at it that way, it's really no problem to have DH auto recall put in Depp Helper as long as they get the bug. And I could continue to be the sole maintainer of Depp Helper, and this could continue to work. I don't know if that even makes any sense at all, that I'm the only one with the commit bit to this. So I should probably talk about my concerns with having the commit bit, but I think we have a question in the back. Is that Steve? Yeah. So I was just wondering if you have any thoughts about what your position is on the question of helpers being included in the Depp Helper package versus helpers being included in the default sequence. Should there be a relationship there? And should that be the threshold at which things get included in the Depp Helper package? Okay. Auto-reconf is what? A great example, Colin says. Is it in the default sequence? Ah, thank you. Okay. Yes, it should. Yeah. I mean, it sounds to me that, okay, here's the problem with that. Anything in Depp Helper being in the default sequence idea. There's all kinds of garbage in Depp Helper. And a lot of it is garbage that I wrote, and some of it is garbage that I shouldn't be calling garbage because someone else kindly contributed it to me, and it happened to not end up solving the right problem in the right way for the right amount of time, and it's now deprecated. So you could say anything that's not deprecated in Depp Helper could be in the standard sequence. Maybe. There's a few things in Depp Helper now that aren't in the standard sequence and aren't deprecated for pretty good reasons. So I don't know. So the other thing that I wanted to bring up is my general feelings about how hard Depp Helper is to maintain. And I think this is something we need to think about before we really think about having a team maintain it because if there's only one guy who can maintain it, Depp Helper has a problem, and that's the real purpose of this talk, right? And it's kind of my fault that Depp Helper has actually become harder to maintain as time has gone on. And it's also kind of not. If Depp Helper were only used by 10% of Deppian, it would be much easier to maintain. If Depp Helper did not have this DH thing, it would be significantly easier to maintain. Really significantly. Probably 50% of my work now is someone wants to change something in DH and I have to figure out what this breaks and how to deal with the breakage. So even if there were a Depp Helper team, it would need to have experts on DH in it. And there are a few people who have done awesome work on DH, and so maybe we could rope them in and get them to handle bug reports on a daily basis since they know how to deal with it. They know how to think about, is this change which seems completely innocuous and the bug reporter is like, there's no way this change could possibly break anything or we're not even thinking about breakage because it's such a simple thing that if it were any other piece of software that wasn't used by every single source package in Deppian, making this change would be obviously correct. And in a way, I'm responsible for this problem too because Depp Helper's API is very broad and people in Deppian often think that Depp Helper's API is anything that Depp Helper does, whether it's documented or not, whether it's a bug or not, and they depend on this behavior and of course they'll do it without even realizing that they're depending on it. So I recently had a bug report here at DeppConf which I went and bisected the bug and it turned out that I introduced it the very day that I rewrote Depp Helper in Perl 15 years ago. I had a think-o and I put in one word where I shouldn't have and the bug lurked in the code all the way to the present when somebody ran over it and I was like, well, this is a trivial bug to, oh, wait, you can fix this bug in ways that could break things that depend on this behavior and this behavior isn't specified and yeah. I don't know if part of the problem is that now that I'm not as much of a Perl programmer anymore I kind of care a little bit more about correctness. Maybe I've shot myself in the foot and I just need to be the Joey that I was five or ten years ago was like, I'll just break everything, I don't care. So maybe the DH bus factors already happened and the guy who's standing in front of you can't maintain Depp Helper without going insane. So I tend to think that I do have overblown fears about breaking stuff in Depp Helper and I think that Depp Helper should be good at handling random breakage, yeah. Go ahead, Colin, if there is a mic. Test, test. So on the old bug report in the past, you've correctly, I think, gone and said we need to make sure that all source packages in Debian work with this change. Fine, in some cases this may require going off and fixing packages in unstable to cope with this. In some cases those may take a while to probably get to testing, et cetera, et cetera. What's your threshold on the point when you decide it's good enough? Because in some cases the things that break may not be in Debian. In some cases they may not be in testing and we may have to security update them, et cetera, et cetera. Yeah, and I don't know if you said in Debian specifically thinking maybe in Ubuntu too. I was actually thinking more of, because I think we can probably figure it out, but I was thinking more of third-party packages that have happened to depend on some random weirdness and are probably aren't maintained by people who are plugged in enough to the rest of Debian to notice such changes. Right, so yeah, I mean if a change only breaks one package or three packages and we catch that on the next full archive rebuild and the breakage isn't package suddenly lost file that nobody will notice is gone and or something like that, then we're fine. And Ashish, no. I'll go ahead. Let me try that again, but I'll whisper to avoid feedback. Okay, great. Yeah, it sounds like you've said a few times with me as the only committer on DevHelper. So let's just change that question mark. It sounds like you don't want to, but it also sounds like you haven't given any reasons. Also every time you take a drink from that it looks like you're taking a swig of rye or something. I wish. I mean, I'm conflicted. That's why I'm having this talk because on the one hand I would love to have a DevHelper team and on the other hand, it's not that I'm questioning the competence of somebody on the team, it's just that I have a lot of experience with dealing with this and they don't necessarily. The mic is vanished again. I'll repeat it. Yeah, I'll repeat it. Then maybe it makes a lot of sense to let people commit whatever makes sense of something and if you read the diff before making a release, I'm sorry. Okay, here's the thing. I'm suck at patch review. It's not a thing that I'm good at. So this is not a good solution. My patch review would basically consist of exactly what I'm complaining about now which is needing to go figure out what it breaks. I already get patches. So getting patches isn't the problem. So maybe what you need is a better testing framework to rebuild the entire archive with DevHelper. Maybe I do, but like I was saying, some of the failure modes might be hard to detect. It might just be missing a file or it might put the wrong thing in the post-it script or it could be anything. So hypothetically, if we had binary reproducible builds, then you could verify that the contents were the same. Yes, please do that. So where was I? If people have questions, keep asking them. Otherwise I'll just ramble on because I'm really just trying to come to kind of a decision here and your input is what I want. So when I'm just rambling, I'm just filling time. So I was thinking about the breaking the archive stuff and then trying to rebuild it to find what breaks. But what about silent failures? What if we don't notice the package suddenly has different entries and all we did is test whether it builds but now it's broken. I'm not that convinced that trying to have this broad interface and just trying to break things and see whether it still works is a good approach and maybe we need to step back a bit and need to make the interface more explicit and explicitly telling this is a Python package, this is a Makefile package, this is an Autocon package and not having to figure this out automatically. Okay, so you're thinking I'm talking about just the interface to DH and often magically figures out what to do and yeah, that's a problem and I pretty well understand how to avoid problems with that interface and a few other DH people do and we can easily teach that to a team and not have that run into those problems. The larger problem is outside of DH though. It's that any change to any dev helper command that can ripple down and have unforeseen consequences in the archive because it can be depending on a bug or something. Thank you. What I wanted to say is not about the DH main part about all the helpers, all the small helpers. Supposedly they should have some very clear interface, they should be very clear what they do which is many times not the case, especially for some other language helpers and whatnot but the thing is they seem very suited for having unit tests and a clear definition of what they do so once you have that it will be easy to check that they are not breaking. So I think there's about three different answers to that. One of them is the whole Debian Archive is a pretty good unit test. If you can actually use it as one. I use it as one for Pristine TAR and it works great because I have a well-defined interface. I'm only doing one thing with the whole Debian Archive. I'm trying to make Pristine TAR output it. Unit tests is something that would be wonderful and unfortunately I suck at writing test suites. This is why I don't write PURL anymore. And if there were a Dev Helper team maybe some of the Dev Helper team would feel motivated because they're in the team to actually write tests. I mean it's not that there aren't any tests in Dev Helper. There aren't very many. And I think there was a third answer to that. If I answered you sufficiently or was there something else? Okay, we're supposed to have tests. We're proposing to have tests as a way of making sure that things don't break when other people are contributing. Yeah, but again I'm talking about the kind of breakage that yeah, you can write a regression test for this kind of breakage just fine. But detecting the breakage in the first place is the problem. I don't know if there's anything about Dev Helper's design that makes this more likely to have this problem than anything else. I think that, for example, the package build package has exactly the same problem because I've struggled with, oh, you want to add these build flag things. Well that's actually going to cause arbitrary random breakage to packages in the archive when they're configured. When you turn on dash JX some make files will break. And people, you know, you have, it's a complicated system with a lot of moving parts and you can have very well documented simple commands with a simple interface and still have these problems. You mentioned sucking out writing test suites which I can definitely relate to. The, as a really, really low impedance option have you considered something like the way Lentian's test suite works which is, it's not actually this but imagine that you took a copy of every source package that breaks and shoved it into the Dev Helper tree and you know you could reduce it or something but would that kind of thing be a decent test to start and at least then you might have regression tests? It would be a good way to do regression tests, definitely. And I think that if we had a test suite not having to worry about how much the space it used would be a good thing. Because we really are going to want whole packages or whole packages minus the actual sourcey bits. So yeah, I, I love the idea of having a test suite. I'm kind of curious if anybody in the audience would be interested in working on writing one because I think we all have lives and stuff. Yeah. Oh, were you interested back there, Steve? No, I was. So I'm wondering with respect if the problem of interfaces changing and breaking things without realizing it is a test suite the right way to go because in a sense where you never test for the bug until you conceive of the bug so you're always risking breaking things anyway. The test suite is only going to cover you for regression testing anyway. Well, you know, I guess I'm wondering if just incrementing the Deb helper compat level more frequently is actually the way to go. I think you could be on something and I've really been doing it more often. Often if I get to a case where I'm like okay, I need to fix this bug by making this change. Oh no, this change could possibly theoretically break something. I don't really feel like trying to get a full archive of rebuild and check it even though I may understand what the breakage might do or I might not. So I just throw it in and say new Deb helper compatibility level fixes this and I'm doing that more and more. The problem with that is, and maybe it's a good thing, is that it distributes all the load to you. Well, not all of it because there's still the issue that you have a lot of dead code that you're carrying around in Deb help. There is the dead code issue, yes. But on the other hand, a test suite is not going to be necessarily smaller than that. That is absolutely true. However, how many people in this room have updated the W incompatibility version from N to N plus one or more without reading the man page? That's all? Come on people, be honest. Yes, man Deb helper. Search for compact in uppercase. That's exactly what I'm saying. So, but then that takes an active effort on the part of the maintainer to have broken their package in light of your changes. So they broke it, they keep both pieces. Yeah, it's definitely true. It's just that if you look at Debian as a whole, I'm still breaking Debian. The fact that somebody else has responsibility for it, Debian is still broken, right? So I have a horrible suggestion that everybody's going to hate. Every time you've got these, that's not the horrible suggestion we hate. Every time you increase this compact level and you keep the old version, you have to have some kind of if stuff in your code which no doubt is eventually going to become fragile and break. Have you considered just putting multiple versions of Delpepper in the archive? Yeah, I haven't considered that. I personally haven't found the maintenance burden of the old compact code to be that high so far. Very, I really don't refactor Deb helper that much. If I did, it would suck because I'd have to test everything. But since I'm just putting an if in and the old branch is the old code and the new code that can be maintained, it's generally not been an issue and I don't know if it would really save me anything to have version Deb helpers in the archive. You could definitely do it that way. I just don't know that it's any better or any worse. So without going too far down this, it's impossible to fix Deb helper rabbit hole. You know, it's definitely possible to keep maintaining Deb helper the way it's been maintained and it seems to work okay because I only have, you know, three or four people a week sending me bug reports or saying why didn't you fix this bug report that I sent you three weeks ago or three months ago or whatever and I only get twice that many at DebConf, I think. Twice that many per day at DebConf. So I'd kind of like to, you know, get back to DebConf team idea a little bit because it's kind of seems to me it's the only idea I have that would make maintenance of DebHelper any better. I think I've said DebConf a few times when I met DebHelper. Yeah. So I have a comment on your code review thing. Personally I love code reviews and I love reviewing code so maybe your expectation is just a little bit too high. Maybe you think that a patch should be perfect or your review be perfect and can't fail and you want to verify it all whereas there already is great value in having a code review to catch just minor issues or design issues and all that stuff. And also before you answer I think that the only way to move forward with team maintaining DebHelper is to actually allow for some breakage to happen and then count on the people who are responsible for in quotes for that breakage to learn from their mistakes and not make them again and in such a way spread the knowledge and also your methodology. That's I think the important thing. So if I would send you a patch what I would love to get is the feedback that you say well here's what I would do personally to ensure that this doesn't break and then I could do it. I hope that I generally do that but sometimes maybe I just make all the changes and commit it with a commit message that doesn't make sense. I'm human too I guess right. How many people in the room get the sense that my fears are overblown that I should just go ahead and suck it up and do whatever. Okay, DebHel does, other people do, people I trust do. Okay great. So I guess I would like to explore the team thing and I don't see any reason not to just do it really. People in the team want to continue running stuff by me until they feel comfortable. Maybe that's just the way to do it and just let them figure it out. And it's really not like you have to have 10 or more years of hard won experience on DebHelper to maintain DebHelper because I clearly maintained it for 10 years before that was the case and Steve. So an interesting example that comes to mind in this discussion is the case where I proposed particular variables be exposed in places as substitution variables to allow multi-arch paths to be expanded in a useful way and you rejected that and I think at the time you made a very brief comment in the bug went off and implemented your own thing and it came back as a fatal complete that of course well that was the DH exec that led to DH exec it basically said you could have anything any DebHelper file could be an executable that does its own thing and spits out the result which is a clever insight and it's very general I guess what I'm trying to say is those kinds of insights are somewhat unique to you Oh well okay I was taking this comment in a completely different way so I think I'll just take it that way that's what you're actually saying so first of all I apologize for the depths of my heart for being an asshole about you and DebHelper and other things secondly yeah that was an interesting general solution that was arrived at in a fit of peak and I don't think that I'm unique in that regard I think that anybody can say well we'll just generalize the hell out of this or whatever you know and I'm not saying and if there's a DebHelper team I'm certainly going to be part of it going forward I have no interest in not being part of DebHelper maintenance at all I would just like to not have as many bug reports that I have to personally deal with and or that stay open for too long or and this splintering problem which I don't know if it's really a problem that we have all these different DebHelper commands out there but it seems to me that it can't be ideal unless we just want to fully distribute DebHelper maintenance throughout Debian and maybe we should be thinking about removing commands from DebHelper and giving them to other people or something so let me talk a little bit more I mean the fact that there are people who are responsible for little pieces of DebHelper already you know I could easily give up more little pieces that would not be a problem so what I've been really thinking about with this team is there is a DebHelper team and what is the team maintenance model I don't like the team maintenance model where everybody in the team is equally responsible for everything which means that no one is responsible for anything you know I think that if we have a DebHelper command to just say at the bottom who is responsible of the man page who is responsible for this command and that way when it breaks you know who to talk to or something like that we kind of need a team maintenance model DebHelper command or something and we've kind of split it up in that way already except for the third of it that is actually in DebHelper so I've kind of been mulling this kind of thing over and I don't know maybe it's the kind of thing that we need to form a team and think about it and you know come up with something that makes sense I think I've kind of run almost dry on as far as what I wanted to talk about because people seem receptive to being on a team did I ask for a show of hands for who would actually be interested in being on a DebHelper team okay let's see there's five or six maybe we have a third of Debby in here so there might be 15 okay or 20 I forgot to raise my hand that sounds like your reasonable team to get started I guess I kind of like the idea of just drafting everybody who has a DebHelper and command it on the mailing list at least because why not if we have a mailing list you know we should communicate on it that's what it's for okay I don't know really how I'm doing on time do I have 10 minutes left or something ah so it actually worked out I actually ran dry at the right time that's nice yeah I think I'm done unless somebody has comments so I guess we'll just go to comments now I wanted to make a couple of comments one I think what you were saying about the splitting is that in my opinion it will make sense to have more DebHelper packages and concentrate more on the core and maybe enforce more some adherence to the DebH standards and the other thing is what you said about team maintenance you were saying that you don't like a team with nobody everybody's responsible whatever and I think you might try some team can work pretty well doing that if the team is functional I've been on functional teams that have still had the problem that a bug came in and everybody was busy so the bug didn't get dealt with because they all thought that the other guy wasn't busy that's unless your team is all hanging out on IRC every day I don't see how you can avoid that do you yeah but I don't have the bandwidth to hang out on another IRC channel and actually know who's active I need to have a mailing list with synchronous communication please Steve I thought you had a mike I've been holding the mike for a bit I don't know if my comments were low you were looking at me with the mike in a way that indicated you wanted to talk okay never mind I think Geerest is the one with the mike I raised my hand before I'm not interested in maintaining all of DebHelper one of the maintainer of one of the DH comments. And I definitely would be okay for me to maintain it within a greater developer team, because there's also the best factor on those tools. I'm maintaining one myself. There are no co-maintenors or anything. So it's also great for those if they could be integrated back. And you have a subset of the same problem that I have. Really, I don't know which thing you're maintaining. Maybe it's only used by a few packages. It's not the DH link tree. I think I submitted it to you and you suggested it to me. I said something like, I can't maintain this or it doesn't seem like the idea. I would have no problem maintaining it within developer. So the only comment is, well, this tool is rather stable and doesn't change much. I'm not sure I would be interested to get all the traffic of bug traffic just to watch it. So if there are some coordinators, we could ping or assign it this. Yeah, I mean, if you do have that kind of responsibility, that kind of thing could develop, I guess. You know, and there could be some way of routing the bug to the person who's probably responsible and if they don't get around to it, routing it to the team or whatever. Yeah. That's only a potential problem. Otherwise, I think it's a great way to, it should rather be opening it's new kind sooner because well, that's a kind of, that's a way to find new volunteers, really. They start with one comment and tends to discover other bugs and fix them and gain knowledge. Yeah, can I poll the audience on another question, which is just as general Debbie and package maintainers who I assume probably use Dev Helper, how many of you use Dev Helper or things that aren't in Dev Helper or think you might, okay, like half the audience or more? How many of you find that to be annoying in some way or another? So, Joey, I was actually gonna comment that I wanted to really thank you for this talk. If for no other reason than I had no idea that this many of the DH underscore commands were not things that you were personally sort of keeping high on. And that's simultaneously wonderful and amazingly scary. It's interesting because I've certainly been using Dev Helper stuff for a long time and I've actually been a very happy consumer of DH now for a while and as I look down this list, there are a number of those that I'm using at one time or lots of times. And it's been very interesting because in general, they do mostly just seem to do the right things. And I am one of those people who actually test things a lot before I actually upload them, except in really strange and rare cases. So there have been a couple times when I've stumbled over something that surprised me, that caused me to trigger a conversation with you or somebody else. But in general, I have this gut sense that this ecosystem is working amazingly well, particularly now that I understand how distributed some of this is. So that's why I raised my hand a little while ago when you asked, are you worrying about this too much? Because my sense is, this is working pretty well and you can certainly do things to make it better or make it less stressful for yourself in the future. But it's not like, I feel like there's some big net present danger that we have to be tackling. I feel, I mean, I agree with you in a way. It's just that I feel that maybe I'm not as active on Dev Helper as I have been at some points in the past or something like that. And it might just be an app or whatever. I had a big app and then I did DH and so, who knows. But yeah, thank you for that. Gert. What about pointing out a new generation of DH? Make, write down some guidelines from, okay, this should be the next kind of Devian Helper. I wasn't there when the switch from D-Select to Upt was there, but there was a moment, okay, the old system doesn't work. We need a new generation. Would you be guiding that? Could you point out a roadmap for that? So, I mean, as far as I've been able to come up with, DH was the new generation of Dev Helper and it just built on the old generation of Dev Helper and I don't have some master idea that would make Dev Helper's architecture better because if I did, I would probably just do it. So, I can't really help with that. If somebody is trying to write the next Dev Helper and wants to replace it, and let's say it's maybe not CDBS or hey, maybe it is CDBS, I have some suggestions for you. If it's CDBS, I have a few more than I would have had for somebody else. So yeah. Thank you. Are there any more questions before we're done? Questions, comments, whatever, we're done then. It looks like, okay, well, thanks for a good discussion and thank you for helping me maybe make up my mind on this thing that I've been mulling over for a couple of years, I think, on an offense. Oh, Ashish, go ahead. What's the plan? Sleep on it and find somebody who can make a mailing list, I guess. I guess that's actually easy, isn't it? Okay, so thanks again, folks. Thank you.