 Okay, so as you no doubt guess, today I'm going to be talking a bit about that box. So for those of you who are actually looking to code this diagram, is definitely familiar. To those of you who just send mail to BTS and things magically happen, you probably have no idea what goes on in between the mail-in and CGI boxes. So just in the interest of kind of explaining what we're going to talk about a little bit, basically the way mail works is mail comes in, goes through a spam processing called spam scan. Think it's kicked into a script called process all. So each of these steps has different cues with different letters. It's kind of neat and confusing. Which then kicks the message to two separate scripts. One's process, one's service. Process is what does all of the bug number at processing. And service is what handles all the control of your message. So if you send a message to control a bug that's on your network, it goes to service. If you send a message to bug number dash whatever, it goes to process. Then all of those tie together into a single database of flat files that's in the db-h directory. And that directory has a hash based on half 100 of the bug number. And in that directory there's a log file, which has a very interesting file format. There's a summary file and a status file. Anyway, all that feeds into a set of indexes, which we then used to query with CGI programs. Later I'll tell you a little bit about the SOAP back in. And basically everything else that you see operates off of db-h. Okay, so in today's talk I'm going to talk to you a little bit about the versioning and how that works. And I'm also going to talk to you a little bit about some of the recent feature enhancements that have been put into the VDS. I'm going to assume everybody kind of knows how to use it. And I'm going to talk then about some of the things that I have planned in the future. And hopefully during the questions part and also during the box. I'll leave this tomorrow at 11 o'clock. You all can give more suggestions on things that you might not see. So the version information basically comes from that. It tracks the versions from which a package is descended. So that means if you upload a package today that's version, I don't know, 1.1.5, or 1.1-5. If the change log matches a package which has been descended from 1.1.4-4, then all the bugs that were applicable in 1.1.4 or 1.1-4 that haven't yet been fixed in 1.1-5 are still present in 1.1-5. That's the basic hypothesis behind which the VTS versioning system works. All the versions are tracked by a source package version number compilation. This means that if you see version numbers that don't match the version number of your binary package because you're insane and your binary package version numbers don't match your source version for very good reasons, whatever those top main reasons are, then that's why. It's because we tracked it by the version number of the source package. So we had a whole set of mappings to go back and forth between what the hell version number is this source package on architecture that's crazy to what the actual source package was that somebody uploaded. Again, just because you have one binary package on one architecture doesn't mean that it's built in the same source on every architecture. It'd be nice if that was the case, but it's not necessarily the way it is. All of this information is accessible via DevOps versions. One of the big things that I've been working on, and I wasn't actually responsible for DevOps versions itself. That's called DevOps in an African town, so the rest of the head looked in there. But one of the other things that I've been doing is, throughout a couple of years that I've been working on BTS, is abstracting out a lot of the functionality that's been hidden, unfortunately, in various modules that were sourced directly. So now what you can do if you like Polovel is you can use individual modules to interact with BTS. And this is the start of that. So the way you can set versions, obviously by an issue of submitting the bug, if you submit it with a version header, and it'll set the version, one of the, hopefully this means the version pseudo header is actually accurate. We don't currently check to see if it's a version that we know about. And there are a couple reasons for that, one of which is the fact that BTS doesn't necessarily know, because it lags a little bit behind what DAF is doing. It doesn't necessarily know when all the versions are out in a while. Of course, before recently, we didn't actually even check to see if it was a policy-compliant version number. But we do that now. So at least we reject version numbers that can't possibly be correct. I think report bug like 3.33 or something was setting version numbers to NA, which have the unfortunate property of not being clearable by any other command to the BTS. So this is the issue. The way you set versions, if you find a bug in a package, you can send a control message, found bug number, the version number. I believe now it works so that you can actually give it the source slash version number combination. But that again assumes that you know what the right source is and the right version number for the source package that corresponds to your binary package. If for some reason found and somebody is screwed up, you can use not found. And it will reverse a specific found message. I've recently changed the way found works slightly. So now if you send a found and you have found a bug and a version, which according to deep package compare versions, well my equivalent implementation of it, is strictly later than any fixed version it reopens the bug. So that's a little change there as well. It used to be if it was only the last fixed version was equivalent to the last found version, then it would reopen the bug. That was done. Yeah, yeah it was. So this confused people to know it, but they found the version that was later that it didn't undone the bug. And I'm going to explain a little bit the difference between done and buggy because a lot of people get that confused. Then to actually notice that a bug has been fixed, there are a couple different ways that you can do this. One, you can use a controller fix, just say fixed bug number version. That market is fixed. Or you can send a version.message. If you send a version.message, make sure that you're sending it with a proper version number. We'll see an example later if somebody can send one with a version number that doesn't exist. And that doesn't do you any good as far as versioning goes. You want to make sure that you're closing it in the right version number. The first package that was uploaded to Devian, which actually fixed the bug. In general, you should be using version done messages as much as possible. This is because it tells the bug submitter why the bug was fixed, what version it was fixed, and all that good information. Otherwise, they're stuck seeing what the bug has been fixed, but gee, I didn't necessarily get an email about it. The fact that submitters don't get emails all the time is another thing that we'll talk about in a little bit. Again, just to remind you how to set it. Okay, so one of the common questions that I get asked a lot is, why is my package still buggy? So you probably noticed that we changed the default display a while ago to show you what's going on and unstable. So if for some reason you don't like that, you don't have to append dist equals unstable to your URL. But this is an example. The most common case is that it hasn't built on all our architectures. So if you look at the header of a bug's not damning no work page for a package search, you can actually see the versions of the package that at least that bug stays, is in the archive. Usually this is some architecture that you may not care about, like for a while, SH was behind. But anyway, that'll tell you, if you don't care about any of the architectures, you can also append ART equals i36, whatever architecture you think is important to your URL. And that'll only show you to that point. If you still can't figure it out, the way to figure it out now is to look at the graphs. So this is an example of a graph that we've got going here. This happens to be GLC. It's an interesting thing to look at the graphs of. And so this is bug 419103. So can anybody look at that and tell me why that one still appears to be open, even though it's not? So this bug has been done. So you guys can go check it out. Let me see if I can. So what we can see here is that it's been closed in 2.5. So if we click on the graph, we can see that there's no record of a 2.5 version. Yeah. That's actually kind of a bug. It was meant to be a version under interpolation that can't figure it out. But the significance is it might be too hard. Yeah. I mean, part of the problem is because you could always have a branch at 501 or something. So it's always hard to know exactly which version should be closed in. So in this case you should be using, sending the version done with 2.5-1. So that's the first version that has it instead of 2.5. So if somebody wants to fix this, they can send a fixed message to this bug. Okay, so that's one example of the problem that people might run into. Another thing that we see occasionally is non-version done messages. Non-version done messages should only be used for inbound bugs. That means a bug that you didn't have to do anything at all to fix. It was a buggy, it was a buggy in another package. It's something that doesn't require tracking at all by the stable release manager or the testing release manager. If you do that, it makes the release manager's job very difficult because they have no idea if this bug applies to testing stable or whatever. It also makes the user's job difficult because sometimes they want to know, hey, when was this bug fixed? It doesn't still apply to me. If you use a non-version done, they can't figure it out. At this point, I want to talk a little bit about the difference between buggy and done. For whatever reason right now, there are two separate states in the BTS. One, when a bug affects a particular version, and the other one is whether it's been done or not. That means whether you've sent a version done to the bug, or whether you've sent any sort of done message to the bug. Usually people or maintainers think that the done means that they are done with the bug. I've done whatever I need to do. It's fixed. Eventually it'll be fixed in all the other architectures. Buggy just means that at that particular version, there still is a problem. If you're not sure which is which, you can have a version or a bug which you have fixed, but still not sent a done message. So you haven't sent a message to bug-done. And that's the difference between the two. If you want the old appearance on your accurate report.cgi screens, you can just delete the distribution equals, unstable, whatever. And all the only difference then will be between bugs which have been, had a done message sent and not. Is that kind of clear? So, bugs have two different states. One is the bug still existent at this version. That's buggy. Is it buggy or not? The second one is the bug done or not? Has the maintainer sent a done message to the bug? It fixed effects whether it's buggy or not. So, if you send a fixed control message to the BTS, that does not affect the done state of the bug, that only affects whether it's present in a particular version or not. That's why you should not use fixed the first time around. So, use done. I don't know if we should change that up. Maybe we should. I don't understand why I've been so confused. But in the general case, because most people close bugs and change logs, you don't care because it sets both that it's been fixed in a particular version and sets the done flag at the same time. Yeah. So, when you send a closed message with a version number, does that also set the done state? Yeah. Please don't use closed. Don't use closed now. Close or does it set the done state? Well, it can do both, but it sets the done state. That's what the closed state is. Even if you append a version? It can do both then. But the problem with using closed is it doesn't send anything to the bug submit. So, close. One thought. GANF is not in the room, right? Because if this thing will get other to the new maintainer question about the architecture, about the technical system that we have, we're going to have no more living room. Passing in there. And which kind of gets to the second question. Do we have a collection of recipes? Like, if you want to do this, this is actually the procedure. I mean, don't use closed. Use fixed, use done. But in that case, use done. Use closed now. So, if you want to do this, please step by step. So, the step by step is in server control. So, bugs slash server control on the website. Web slash reporting on the website. And the general rule is don't use closed. We have a list of bugs slash something that documents something, but I think I could have a title for it. Yeah, well, if you just go to bugs.dev.gov and click through the top five links, that's all that's document. Okay. Here's the still difference in the way and the user handle from maintainer calls. So, the only difference as far as I know is I think we're still setting the fixed tag. But in general, there is no difference as far as the BTS is concerned between a maintainer upload and a non-maintainer upload. And the fixed tag is set for maintainer calls only? Not maintainer. Non-maintainer. Yeah, because it still has the unfortunately convoluted fixed interview. And that probably will change at some point in time through the original meeting of fixed. So now we've got done-less and not done-less, and we've got fixed-less and not fixed-less with applied particular versions. We've got fixed tag which doesn't apply to particular versions. Are there any plans to rationalize this at all? Yeah, so I think one of the problems is I sort of inherited the system that had been brought up over a period of time. So right now, all the fixed tag means fixed interview. That's what it shows up when we look at it on the BTS. I don't know whether we should get rid of it entirely, whether it has no meaning, whether we should keep it as a maintainer, some state between pending and fixed. I haven't decided. I mean, I haven't opened it, but all that. So this goes back to the discussion that you and I had. I've actually been one of the stronger supporters of this conceptually. I think it's really important. It seems like we still have a mark down. Yeah, I definitely think that we should go over that. Part of the problem too is, I mean, I look at it as a maintainer of DevOps, so I know what a reasonable amount of coding there does. So, I mean, I had told you from my side that people actually use it without knowing what the insides are. So I think one of the problems is that we started doing the versioning system with the awareness that we had to keep compatibility with what we did at the start was to make sure that the normal flow of change logs work properly, that we didn't have to go through and manage 100,000 bugs to fix up the states of all of them, or to a single new schema, but maybe it's time to go through a load of bugs automatically fix up their states to some new parents. It's definitely possible. Actually, as a bottom-off, I would say, users of versions like him, I'm quite happy with the implementation. I know there are a few things that I don't like so much, but most of them, what I do quite often is I go to the bug list and these are the RC bugs. They say, oh yeah, this is what needs to be fixed because it looks a bit strange. A few minor things, but mostly, for my side, it's really working good. The main thing for the maintainer, because at least it's available to currently. Right, no, I think one of the things too is that release team deals with the bugs on a daily basis, so you know exactly when it's broken or not. Yeah, I understand how bugs can convert anyways, so I didn't know how to work on any bugs that they have. The thing that's interesting about versioning bugs is that there's a version that matters a lot to the package maintainer that's not visible to the rest of Demian, which is the head of the source tree in the control system. And so I think part of the struggle that I felt is that the view that I want to have of the state of bugs, which of the bugs in the bug tracking system still applies to the source tree that I'm staring at, right, improvements in for the next step forward. And so the thing that I think, what's the right sort of, you know, and this comes back to hold that closed things, changed their state and so forth. I have found myself using tags and so forth in the bug tree action process so that I can approximate the name of the state and this is something that I... Yeah, I mean, I should kind of show you. I use it a lot. Yeah. Yeah. Just a quick thought regarding the fixed tag. In a certain sense, seeing the new view among the news, which are no more an unfriendly app, no more something that crosses a bit the line and everything, it probably makes sense to close the tag. I mean, the maintainer, if it doesn't acknowledge whether it knew or doesn't like it, can just develop it, right? Oh, yeah. The bugs are... I mean, it's exactly the same as a normal upload. So the bug is closed. The only difference is that currently, no way, because I ask for it, but the tag is still there. And the only reason why I ask for the tag to be there for the time being was so that if you're a maintainer and you have it in you, you can quickly see which bugs you need to look at before you make your next upload. But there's better ways of doing that. So that comes back to what me, Dale, was saying. So the reason why I use the difficulty is because the maintainer, that is the only person who's allowed to sue that they can make an upload without first doing a download and checking what those two subversions are. And that's why the bug system needs to reflect whether or not this change has been made to the maintainer's tree, which is not visible anywhere else. Right. I think it's like the avatars and the definitions in me. Because what happens is the maintainer just uploads his source, he will just cut out from the BN change logs in a new version and basically all these bugs will appear un-stable, which helps us to fix about the 20 to 30 SE bugs where the maintainer just uploads in a new. So it actually just works. If the maintainer uploads his version, the bugs will open automatically. That's a great thing about version for me. Yeah, I think we should hold off on that discussion, I guess, a bit more. Let me at least get to the recent enhancements and then at the end, we can come back to that because I know there's lots to talk about there. So some of the, well, some of the bugs and switches have been around for a while. Version graphs, you'll probably all notice that, because that's pretty visible when I made that change. I think Steiner actually started writing that, but I finished that up. Another thing that's been done is there's now a soap interface. Along with the modularization of the bugs, I've started to expose more and more functions publicly using the soap interface. And this basically, currently, I'll show you an example of all the different things you can do. If for some reason there's something you want it to do, you want it to write it because it's a soap that isn't available yet, or for some reason you want some other aberration, besides the aberration that soap is, you can tell me about it. Maybe I'll read it and as well. It's actually pretty simple. Another major thing that's been changing is I've started to modularizing the code more and more and more. Part of that is because I can't handle uploading stuff or making changes to the live BTS when I can't test it on the forehand. So I mean, even though I've broken the BTS more than enough in the past couple of years, if I wasn't able to do that, I would have broken it a lot more. One of the major changes that it's still going now is versioning the where archival. I guess I should explain how this works a little bit. Basically, bugs are now archived if they are fixed by fall in unstable and testing for at least 28 days and the bug is closed and no activity has occurred on the bug in 28 days. If the bug is important and it should not be archived until stable has fixed it, so until we increase the new stable or point release or something, you can tag it above stable and that will add stable to the set of releases that it weighs, stable. I think it's stable, actually. Maybe I'll go with that. I'll check that out. It'll either be as stable or as unarchived. I'll correct the verbiage on the server control that explains the tags to indicate which is correct. But whatever tagging is of the unstable version, then if you set that, it will not archive. Along with that came the ability to unarchive and archive messages. So you can now unarchive any bug that you want to bug the previous before, but it required bugging somebody with an owner to have. So this basically enables you to do that for yourselves. What goes along with it is the ability to archive bugs. You can archive any bug which has previously been archived. So long as the version requirements have been met. So it has to be fixed in whatever architectures or whatever distributions in addition to having closed reopened boards you can now have closed reopened archive unarchived boards. But why is it why archiving is there? Oh, yeah. The reason why we archive bugs at all well, there's a couple different reasons. The first and foremost is because it cuts down the number of bugs that gets found. So you can email any open bug and if you're a spanner, for some reason they seem to enjoy doing that. Larson in the back is basically responsible for eliminating how many gigabytes of spam in a day. And reducing the number of unarchived bugs we have helps reduce that. Another thing is it also helps clean up the view that you do not care about a bug that you fixed a year ago in general that hasn't shown its head again. So this takes care of that as well. And so it reduces the page load times. It also makes the searches faster and does some other things. Along with that, I'm almost ready to sort or to search in archive bugs and in archive bugs at the same time. So if for some reason you really want to know it all, it definitely can. One of the most recent things I committed is the ability to sort a bug by age. So if you add order equals age, and you select the order sorting option, you can have sort your bugs by age, which is the last time that anybody mailed the bug. Some people will ask for the ability to say, hey, what was the last time I mailed this bug? That's a little more people to do. I don't know how many times soon. But this is pretty easy. So, Stiner Ruderson wrote the versioning where bugs scan, which basically tells you now exactly what bugs are open and stable testing and that's stable, and I think even that is experimental. We also have an assistant finally that's encoding where to blow up. But now, if you've got funny characters, your name works correctly and the rest of it should work. Let's see. This test week's one of great things. Oh, another cool thing we've got is full-text searching. So you can now search for anything in a bug anywhere with a whole bunch of neat additions using hyperspray and I'll show you how to do that. We also have force merge support, force merge. For those of you who haven't used it yet, it's probably a lot of you have. Basically, if you're one of those people who has users who don't check the BTS in 8 billion bugs and you fix the first one, so it's the way you want it. You can now just say, well, after you re-sign it, after you re-sign it, because it probably signed to the wrong match, start with it. Then you can force merge the bug number that's correct and then all the other bugs that they've sent in. It'll change everything in the other bug to match the first bug that you would have to really change the version. Oh, we also have searching now on Elmer. I don't know if anybody used this at the Science TVM, but it's there. Oh, and we're also getting rid of the boring information. So things that are messages, the useless information that we use to show doesn't show up anymore. I mean, you can have it show if you want it, but it's not there by default. And we also don't show the message received by sent to messages anymore. But you can toggle those on. They're actually in the HTML. Here's the version graphs you haven't seen them. Green is fixed. The red's important. And the gray is met. It doesn't know what it is. By default it doesn't show you the gray, but if you now click ignore boring the version graphs will show you the boring bugs. And we also do collapsing. So if you see the some versions so this is a whole bunch of versions which are going to collapse there. So if you actually unflashed it, you can see all the versions. So now we have you can select user tags using it and do bug searching or selection by it. And you can also call the bug status granted. So and anything else that you're interested in pulling. So for your own private application there's just so big an example. It's pretty simple. So the basic thing is this is the actual method that you call. And so this actually returns the status of this bug. This part's not a total document either. So this is bug 300,000 who closed it. The versions that it was found in etc. So you can run that code and you can see the output that it generates and the source stuff that you can pull out from this. There are a couple other functions. I don't think that bugs so much. Maybe if I have time. Okay, this is for me. It actually brings everybody BTS and sent them out. It actually makes it much more similar now to bring up around BTS. You don't actually need a configuration file anymore. There's a configuration module that sets same or relatively same defaults for almost everything. And the hyper straighter back in. So this is now running on account. Let me see if I can get this to work. So this is the full text search. There's actually a link to it from the BuzzItec.org web page that you know from the URL. But some of the neat things that you can do obviously you can search for yourself. So this is actually using a hyper straighter based back in. It's kind of neat little full text searching thing. But basically you can use it to search for BTS this way and you can add all sorts of neat attributes. So for example if you're interested in some very important books so you can search for books that contain mining that's very important. It's a little slow. You add constraints but it's very much fun. So you can add basically any number of files on your search to the ones that you want. What I'm missing on this page is some info on which format dates should be entered and stuff like that. Would it be possible to add that because if you don't know what's behind it it's practically impossible to use constraints like that at the moment. You have this drop down list of all kinds of options equal to string fuzzy matches whatever. And basically I don't know which should be used with which attribute. So please add some information about it. Sure, yeah. It's more difficult with hypostria itself because you actually have to know it's a query language. So this is a step above but I'll definitely add that. If you just use JavaScript because there's a variety you just get a small amount of select. But what I originally wanted to say is that what I would like to say is something like I want this availability to actually be this important or whatever. There's not going to be a metric just like this query. Just like this query greater than using this. But you could do that using other methods. So yeah, just don't make it good. I think I'm not sure if that's still the case but I've done searches and if I can change something in the search conditions and search again. So if you have a search page it would show the data page by default instead of going back to page 1 which is kind of proper when you restrict things and you don't have that number of pages anymore. If you then go back up it will first keep on displaying the last page and just leave it for you. Finally get back to the first page. Yeah. I thought I'd fix something like that at one point and then I'll go back to the URL that you're at and then I'll definitely look at it. Oh yeah, this is sorted by age so this I've just added so you can now append or read with age or select it from the menu. What's in the URL is ungodly complicated and one of the things that needs to happen is a much better way to add all of these neat options that Package Report has without looking at the source code finally the select options at the bottom sort of start towards that but more work needs to be done on that. So you can see this huge URL that I've got. It's kind of neat. First it's sorted by last time the books are modified and you'll notice as well the bottom here that I don't have any books that I fixed this year so and no books as well that I fixed my upstream source because they're all tagged in so that's how you do it but I'll show you guys how to do this and probably fix this little options at the bottom so that you can do it more easily. Why don't you just like blog it or something? Yeah my blog hasn't been updating in three years so but anyway that's an example. Okay so future stuff more so methods I know this is from people who are doing things stuff like marketing or planning to be stuff like BTS so any more so methods one of the other things I'm trying to do is control abstraction and that means that ripping out all the e-commands that you can do with the control mail so that you can also do that to some extent in messages that you sent to a lot of people and the same message that's sent out you can do them all and that's happening slowly another thing that we'd like to do or kind of thinking about doing is integration with your own small base that you've been talking about one of the questions that we had is the ability of containers to add specific information to the tops of bug pages and the packages that they maintain so that if there's something that you wish bugs and others would do or information that you'd like to give to people browsing the bug pages would help that out another major thing that a lot of people ask for is better statistics and that's something we need to do and the other things are templates for all output so all the output that BTS produces now is hard coded and the code obviously suboptimal and that means that it's rather difficult to make small changes to the output format because you have to make them about 3 different places depending on your and in order to make that change I have to change it in 30 different places which is a little too many so that's one of the changes that hopefully will be made and the final one versus more documentation and that's something that everybody here can help out I'm available if you want to find something I could give me 5 records see if you can have this one I don't know if it's useful or not so here's some information on how you can help that's where the source is it's all at BZR right now it's much better than it was in CBS I don't know if it may change again but at least BZR is kind of working most of the functions that have been added are now documented with pot so you can kind of get a handle better on what the source goes through it has same patches that explains how to fix our documentation and with that like the rest of the Daedalux team all these people have done work at some point in time and Jackson has also done work it's different than I don't know if a couple of people have sent a lot of patches have done other but these are the current people but I think I still have some time to answer more questions about the source interface I'm using a source interface in half blisters I think it's one of the only software which uses the source interface in stable distribution so if you change the interface now we will break the package in stable that's actually something that I've constantly been trying to avoid or trying to come up with a good way multiple API versions and so because I've already gotten caught up with it once with the report bug that was directly parsed with the HTML as a bug report or something and so by the way if you're doing that and your packages please stop tell me and I will write SOCO or something for you because I hate special casing stuff but yeah I will definitely be compatible in some way with the solicits and stable for the statistics thing I was wondering if you were aware where David Martinez Moreno vendors graphs that he's been doing he started tracking at least for some packages like I believe the installer he's been doing all the extracourse packages he's been graphing closures and certain aspects of modifications for us and it's really been helpful in terms of seeing so maybe you should talk and sort of take some of this code and see if you can integrate it one of the things that is always useful I think a couple of people are going to use the statistics board because that helps me by looking at what I can write so that the user can see the ethic of the sections so right now when expirer is not running as it's been running for the past couple of days it's basically running it's stopping every two hours so stuff is processed but in general bugs are processed every three minutes so it used to be every 15 now it's every three so it should be fast enough to see the response but if you're not seeing fast response right now it's why it's because once it's expired it'll be back normal the physical amount of spam we are getting is taking enough time to process to cause at times hours of backlog I've been rewriting the spam stamp code to reduce that it can now process spam less hassle on 20 bugs at a time and we've got faster machine and more in general unless we've got some crazy DOS going on it's usually relatively quick for the normal state of DOS that we have to play any additional questions? the main least currently rejects mail sent from so-called demon addresses like root, demon head and so on however the BTS happily accepts them which means that such mails do get into the BTS but do not get to the intended receivers if the main things are the main least it would be great if that could be seen so that's either both reject them or both accept them and I think it's more logical to have the BTS reject them the same way that the list do as it's basically spam on measure and people shouldn't be sending from root addresses anyway yeah the problem it's kind of a two-part thing because we don't actually bounce because we can't bounce on media well I guess we could probably start bouncing on media because we could work with DSA to change the action of the BTS because we have to bounce on media any additional questions? just a comment to what he just said and out of person it was the the filter you're mentioning is also rejecting the plain local part mail which is more and more common for people who use the name the domain and then it's main ad so if you're changing that then you might I mean I created mail demo but just main ad is common for root addresses and for users users so if their BTS mail would be blocked it would be confusing for that the problem is that it's kind of hard to use the filter and then still accept from certain parts of our part of that so it's either activate the main email feature or not use it so thank you very much for your attention don't forget the bot tomorrow at 11 feel free again as well if you have feature requests that you think of after the bot or between now and the bot to file bugs on devlogs or bugs on devlogs so be really close to the point