 So, hopefully what we're going to do today, what I kind of hope is to sort of have a discussion about how you guys use DevBug's, maybe show you a couple, or maybe show you how I use it, some of the couple, if you don't maintain a package. I don't think about not maintaining a package, but I'm not here because I'm a package maintainer. I mean because I want you to use DevBug's better ways. The scope now is for the package maintainer as I understood. Well, yeah. I mean, that's the first start because I think that's what the majority of us are here. And I mean obviously if somebody has suggestions for other classes you can listen to. Having issues or wanting to be able to only show bugs, it actually matters. So one of the things you can do currently is if you've got a bug report. So if you look at your package or page, you can append, pending exclude to the URL. Equals done. So pnd-exc equals done. And that will get rid of all the bugs that are marked up. If you're using tagpending and you, when you make a change in your subversion, you immediately run tagpending or run tagpending soon thereafter. You can also go add an additional pending exclude of pending-fixed. And that will not show any of the pending bugs. So with those two additions, the done and the pending fixed. And I'm seeing that I probably have to write it in the Wiki so they can see it. And hopefully in the option screen I'll add it too. It's not there already. You'll be able then to restrict yourself to the class of bugs that you're most interested in. Another thing you can do is if you append ordering equals age, then you can sort from the last response to the most recent response. And so because we now also split out won't fix bugs, pretty much the top bug on there should be is the highest severity, the bug that you talked about the least or talked about a long time ago. So those may be the bugs that you want to send a message again to as a maintainer saying, yeah, I'm going to fix this or maybe you need to mark it won't fix or help or something else. So that's kind of how I personally use the BTS. So can everybody get to the BTS now? Are we still playing with the UCP? I can. We do have wired in this room. I'd opt for my baseball but it's not one of the work. If you don't, it won't. This is a MAC that has to be in here the corpse or not a MAC that has to be in here the corpse. Be a kicks on me. Be a little kicks. Do you usually text like that? Yes. Send your screen message. Where do you have your wireless? The one that sends your screen message. Do you see the two wires in here? Sorry. Okay, so beyond that, I guess you just go around and see what are the current problems that people have with the BTS. I mean, there's a whole lot of bugs that are open against bugs that definitely don't work. Close to a bunch of them, but there's still a lot of them that are open. So I mean, current thing, what's the current most crack-tag glue thing about your workflow in regards to the BTS? You just go ahead and start. Yeah, well I work a lot on E-Beneview, and we have a user tag for our bugs, and I report a lot about the bugs related to E-Beneview. And I don't know if it's a lack of documentation or my knowledge, but I would really like to be able to report about and tag it with my user tag with the same message. I would like to send a message, wait for 20 minutes, and then tag it when I got the number. Right, I can do that. And if you put user tags in the report, they will be tagging it with your user tag. Okay, so lack of documentation or is it just my knowledge? There's main format from HTA, and they've been developed now for only a good documentation for that. I don't know if the fact that user tags set user tags is documented. In fact, I don't know if it actually works. If you go to the... I've heard that it works. You can add user... Yeah, I could have added it, but I just don't remember. The 424174 is about reporting against one-on-one package, and how user tag in the report. Oh yeah, it does do it. I think you added it to your last ad comfort, so... Yeah, it could be. I would like to search all the bugs with the same user tag. I don't think it's possible now. Ah, so you want to return the list of bugs, which are the user tags? Yeah, we don't come to specify any other things. Yeah, probably a mass... A mass... I don't know if it's for the English part. The mass bugs have the same user tag. I want to see how other bugs fix it, so I want to see all the bugs... So you want to search? Yeah, so... Okay, I'll definitely make sure... I mean, that's pretty easy, because the user tags, the way they're stored is totally separate. So it's just a file with the solenoid. Yeah, it's not an option. Right, so what may be good is just to make the user tags capable. So you can just click on the user tags. And if you swipe one, that's where all the bugs... Sorry, many user tags. So it'll link it. So when you look at... or find A-bomb with that user tag, you can click on it and... I don't know. Okay, that's not an option. Yeah, not an option. Yeah. With the first bug tracking we have now, it would be nice if you had a simple drop-down box, like we have on package Devanorg, to select for which distribution you want the bugs listed, because currently the interface for that is kind of involved. That's really fun. Yeah. Okay. So the interface as general is very confusing and will be nice to be synthesized, for example, by distribution, by severity, in a very friendliest way with the filter, which is very unfriendly. Yeah, the problem is, I agree that it's not friendly now. We've got two separate things working together. I don't know which way to go necessarily to make it more friendly, because at one hand, it has to be searchable by users, and at the other hand, it has to be searchable by maintainers. So make two pages. Wow. I have a basic interface for users and kind of an expert interface. Yeah. Well, it would... I hope that has all the options that people really know how to BTS structures. I mean, what it could be is just having it so that the pages are cut. One version is cut down, and another version shows it all. But one of the things that I was planning on doing or hopefully in the future is having cookies, so that you could say, hey, I'm a maintainer for these packages. Do not... I only want to see whether I've marked them done or not for these packages. All of the packages by default distribution is unstable. Only show me the view from unstable. Another approach would be different backgrounds for different distributions on something that is something where we can visually distinguish very quickly the bugs for its distribution. But yeah, that's bug scan. What does that mean, to some extent? So, I mean, but if you're asking for a best product or the toggle switch, what he's asking for on the display list of bugs having a different background color or different distributions that the bug applies for. But since the bug can apply for multiple distributions, and that's... I'm not sure that that's really doable. What you could do is something like... This is a bug applies to this set, and you make... It always takes the same color for stable, testing, unstable. So you can see, oh, this is now just marked as a stable and unstable color or with all the colors and something like that. We could just do exactly what bugs scan does now. Have a little box that says, bestie you need. You could cut the box. Is that called an expert? Yeah, yeah, but it's too expert. The problem is, though, is we have one thing where we have to reduce the amount of information or condense the amount of information, and we can expand back out of that. So the thing is that STUV doesn't really tell you much. It only tells you if any version is buggy in stable testing, unstable or experimental. Basically, I would prefer to see if the source version is buggy. I don't know what the first version is. The source version. But there are multiple source versions and multiple architectures. No, if you say it's buggy in unstable, it doesn't necessarily mean the source is unstable. It should just mean that one architect shouldn't keep up. You don't just don't care about this. There's multiple source versions in unstable. No, multiple binary versions. No, there are multiple source versions in unstable. There have to be, because otherwise... We don't have to accept multiple versions of binary architectures, of course, that have different sources. Yes, but you could easily have multiple source versions in unstable as well. Because you don't forget, we don't necessarily distribute exactly the same version. At exactly the same time, because the build piece is buggy. Yes. Answer, can I only... Most interesting, just the most useful question... I think he only wants to know about the ones that, if you get source, apply to that source. Well, but that depends on what architecture you're running. No, architect source is always the same. Well, that's always the most recent version that's been in the distribution. Which is the most relevant for... Backflash. Yes. I know that it sets up a different... Basically, something like a most recent only or something like that option. That's good, because we've been hidden elevated, but... Yeah, I mean, I'm trying to think of the use case where you would care about that. And the use case that you would care about that is when you're the package maintainer. What if... Or when you're QQA. But if you're the release manager, though, you care... Or you have other tools to... Well, basically, I don't really care, because I've got all the tools in the box, I just have to take them away, but... Well, but you care... I'm trying to think about the general case. As a release manager, you care about all the architectures in the suite. No, you look at build demon data for that. When architect is lagging, you look at build demon data. You don't look at the bug tracking system. I have, for each package, I have... That's not in sync. I have on the page, what's build demon data? So I can just jump to the build demon log. It was a status in the Wanna build. But I don't care if the bug is fixed or not, because it's basically... It's not fixed to testing. In both solutions, it's a build demon and not CRO. I think we should really focus on the interface for users and package maintainers, because the release manager does such advanced and special... They know the bug tracking system well enough that the best... I mean, the interesting thing and where the most improvements can be done with most people is really the package maintainer, the general package maintainer, and the users. So let's focus on that in this book. I would also not really be interested in that that are fixed, that have already been uploaded. Yeah. Because if an architect is lagging, I don't care. Right. And that's when you want the view out of the distribution into some stable. You just want the... Whether you've marked it done or not. Whether a change log has been uploaded that close on bug. That's what you want to see. Okay, so that should be an option in that drop-down list that we talked about earlier. Actually, users should like this water for their run. Actually, I think basically it should be better if maintainer would be interested in what does the bug tracking system think that's fixed in unstable, because if they have accidentally moved an NMU, they wouldn't see the bug in the app yet, if they only ask what's now as mark is done. So if you look at... If you always take the latest unstable version, then you would really see the correct view. You would see it get reopened. That's what you want. Actually, one of the great features of version 2 is that you don't need to reopen a bug if you cut the version out. Yeah? And that's something that the default view for the maintainer should support. So not only we sometimes see, it's like, oh, you just forgotten to keep that fixed in, but also maintainer sees this page. Yeah. That's true. And I really would like to have some help in creating. So I think there is some of the proposal which is being developed, in my case, which makes it easy to forward bugs to upstream, but I don't know if we can have some help in the debug side too. Like, if I have a web page with like 200 bugs and I need to forward 50 to upstream, it's really painful to write 50 emails, and I would like to have some kind of templating. What you can do right now with just, I mean, if it's already existing in the upstreams BTS, you can just go BTS forward bug number URL, common BTS, or whatever, forward. You don't need to actually send emails to do, I mean, send one email to do all 50 bugs, or all 200 bugs if you wanted to, and send one. It is documented in server control, bugs-server-control documents that forward control command. One interesting way for a user, if you take a user and you want to know about, do you want to view a page like this, there's mostly two things you want to know about it, whether it applies currently to the version you are using now. Like, I want an unstable policy and I want to see whether it applies there, and whether it has been fixed at all somewhere, so that if there might be somewhere else, a version that's fixed, for example, I want testing an unstable one fixes it, so you want to show the open books and also, I don't after it, or state in the bug list, whether the bug has been fixed somewhere. I don't really think it's currently viewable, but it is not very obvious, but the case is that if a bug has been done flag-set, so if you see it done by so-and-so, it's been fixed somewhere. Yeah, but that's not really obvious to users, maybe it would make sense to make a user and face much clearer, like open books, and then note, this has been fixed meanwhile in an unstable body way. Maybe what we mean for a user is some sort of introductory documentation, like a select body documentation. No, nobody brings documentation. What you could do is try to make it look insane on the page and adding documentation so for more than just people, or something like, instead of saying, what does this mean, or something like that, but people don't need documentation by itself usually. And who do it already can work as a previous, as it is most people. There are certain features that aren't documented yet, but that's getting better. What I was thinking about there is maybe just, because that is something that's viewable on the bug, so if you take one bug, just the frame, and just have one page that says, for introductory users, this is what this means, that means, and the other thing, because we have, I mean, almost every bug that you view Apache Report has exactly the same format. You could take one example and explain it all a little bit, Stu. You could also add little question marks in the various pages. Click on the little... Open some text, it explains it more, but for the possibility, because users are about getting the information, as fast as possible, not really being what's there at the time. There was an excellent slide where I read about users and how they're using UI, and they basically, they go through what they think will get them to what they want to see, and it doesn't take a lot of time for them to do that. So they're all about their results. They're not really at the time to do that. Yeah. So what else for maintenance? I would like, I know this possible, that Apache has something incredibly good, who is attached with upstreams, bugs, and you can associate a bug to upstream bugs. So when... Sorry? Does this exist? Oops. Well, it's not like official that works with the work of user text. It's maintained by... Can I look at? Right. Thanks. And with user text, you can set, for example, for a couple of the common bug tracking systems, like bugzilla, you set URLs. And whenever, for example, on the upstream bug tracker, there's some status changes, then user text will get set on the package. So you can see upstream confirmed or upstream result or upstream this. And it's with user text outside of the other one, outside of the work tracking system. Maybe speedy. Yes, definitely. But it should be, of course, incompletely documented for the user to know how to make it easier for them to use it. I think there was recently some message about it being documented a little bit. Yeah. But I basically have made sure that I don't break it for them. I'm not terribly involved in the BTS thing, Stan. Maybe it would be good to incorporate the documentation on bugs or devils, even though it's not actually implemented on bugs or devils. Yeah, that's definitely possible. Yeah, speak. One of the things that kind of give the idea is that the documentation for developers is kind of screwed about there. One of the things that I don't know how to do yet is how to structure it in a way that makes sense for developers. Some of you know exactly where all these tags are documented. They're all the control messages are documented. Some of you do not. So that's something that maybe if you're one of the people who doesn't know, that if you look at it and see if you can come up with ideas and rearrange it so that it would be a slightly more logical presentation. Oh, yeah, by the way, all the messages about status changes, like, you know, could they have like the date if it happened? Oh, yeah. Yeah, that's one of the changes I made a couple months ago. They now tell you exactly where that change happened. I don't need translation to your local time zone. No, I shouldn't deal with it. I just want to know how long this boat was closed and then reopened. Yeah, it wasn't included before in the control message. It's obviously in the headers in the email. So you could click there and figure out what exactly it was. Yeah, it's but now it's actually every control message includes the epic time so you can just displace it now. Is there any concern? It's becoming more and more for people, particularly those managers to change things about status, tagging the link with BTS and insert a comment such as here's why I'm doing this kind of comment. Those are in the bug dragging system. If you click on show the text of the message to change the status of the bug but they're not anywhere that the average user knows how to find them and I've seen several people be very confused with why did you downgrade my bug without putting in any explanation of why. Well, there is actually an explanation. Is there any way we can lift the comment of one of those things up to the main page Yeah, I mean, it is possible. The problem is that three products that are practiced to send some action to the user of the bug. The problem is though is when fans don't actually do any show. Yeah, well, when Steve is tree-outing, you know, 500 bugs I'm not sure but I want him to spend the time writing individual messages to the host because I don't know how to write the message. Yeah, but when you use the BTS command you need to fix the BTS command. Yeah. I don't know that probably in the one you said. Well, I was trying to get out of the default user. Yeah, perhaps what would be useful is in the case where there is a comment. It's only the comment that we care about. And then maybe just one of the things too that I'm trying to do is to pull out more and more of the control commands so that you can now run in the subject of the first bug. You can't do it now, but in the future in the suit of headers of any message you'll be able to alter the control stats so you can just send a message to the bug in person. What the noise means is that when a bug is reassigned only the original maintainer for the package that the bug was against gets the message. And not the guy that the bug is reassigned to. That's awesome. So you basically also always have to CC package at packages.dev.org to make sure that the other maintainer gets it and knows that he actually has a new bug to look at. So I always try to do that because without that just the control message is not enough to get involved in a bug. Especially you because you usually only get the control hack through the second maintainer. That's part of the problem is because the way the process right now is control messages are totally separate from other messages. And hopefully when I finish or at least get farther along the control messages you'll be able to use a reassigned pseudo header to do that. Do you have to control entirely then? Well, the control is still there as far as I'm concerned. It needs to be there and it's going to stay. But what I'm just going to do is the bits of control that reassign the bugs or change severity. I'm going to rip out a new module so that I can call the exact same code from the process which does the bug number stuff and service. That's how I implemented it. And you're then going to say okay if control receives a bug that was also cc'd to the bug itself or send to the bug itself I'm going to ignore the cc'd control. What I'm probably going to do is do it so that it's only just pseudo headers and so that it has to look like a pseudo header in order to have it work. So if you use the current format you'll still get the current behavior. Yes. I may do it so that I have to think about it. It would be so nice if the current structure would be worked as well so that people don't have to switch their way of working and everybody would have to send me if you're basically because otherwise you still have It is a possibility to maybe allow a header to be set in the mail like the xdeb. What I want to avoid is the case that all messages get control parsing because the way it works now it doesn't look like a pseudo header for a real line it says oh there's no pseudo headers any parsing. Whereas control, you send a message to control it tries to find a control message for five times and then it stops. So I kind of I want to avoid having the case where you automatically get a control app that type of app your message to the bug was a command no that wasn't a command either no that wasn't a command because that would suck to get that back so you get an app and a control app every single mail annoying. So I think maybe a header or something. If you didn't use pseudo headers in the first line, maybe a header that said hey I'm using an old control syntax or something. That's something to think about. Even if I do it wrong the first time we had a list changing we didn't actually make bug submitters get old mills of bugs or something like that it's just one of the things that's one of the things breaking out everyone who didn't know the bug system in the past. That's one of the things that kind of used to be thought of and I think the idea was at some point to subscribe the submitter to the bug list by default you can't just to put it on the basis of meeting bugs? I don't know whether I'm going to actually do it by using the submitter list but to have them set up so that they're always getting the mail by default and have it so that they can opt out of that list because I know there's submitters who do not want to receive additional mail Also when you are basically the maintainer of the package yourself or your team maintainer you are already getting bugs through the team list probably so you don't want the private CC as well so there has to be a good option to opt out or it would be great to have a second submission address and one that is this way and the other one that is another way so you can submit the error you like but quiet yes, a bit quiet a bit noisy because right now we have mail and stuff we actually could extend mail but that's not good I also see users who submit quiet and no mail because there's definitely too long if you do mass bucket content as long as it's just you want but you always send it to mail so mail only is quiet anyway the bucket has where you want don't want to PCC and you want don't want to submit only yeah, what I was thinking about maybe just like the pseudo headers yeah that's already added to not get an egg on actually submitting yeah, that's a real header oh yeah, it's a real one I've changed that to though so all the silly real headers that you could set you can also set now in pseudo headers and vice versa I think but it's definitely going from you can set X, debugs, no CC, colon, and pseudo headers in case you're using a broken MUA that for some reason makes you shouldn't set real headers does anybody know anybody who's an administrator in hotmail? I don't know hotmail no, okay a recent problem that has come up is apparently hotmail sending messages that have totally broken the text plane I've already gotten two of them it's basically an integer they're going to accept any mail from online yeah, well, somebody was saying I should hack around it that was my response I'm more likely to block it entirely you should do that online because it's something you can easily check in the NTA for example if the mail is a lot of uses get bounces oh sure, yeah that sounds easy to check if I get more than the current number of examples I have, then yeah, that's probably something that's going to happen also the suggestion I'd have has been mentioned before I'd like to have the link to the page of the bug in every mail so I can tick on it and it'll be pasting if that's possible the main thing that's blocking that is currently the way that every single thing that would be his outputs is hard coded in the code and one of the things that's blocking that is I really go assuming I get it done soon I want to extract all that out into some sort of templating system I'll probably test that later something easy and that way I make that change in one place at that point and see if it's done the right, yeah, because now I have to make that change in like 30 places it sucks speaking of the format of the mail when you close the bug, the mail that's sent out from the bug close always strikes me as having odd things in an odd order or something we have detections usually I detections usually I want to see a message to close the bug first and then maybe the original bug has the second message does everybody agree that should be reversed? yeah okay and leave out detections in the original approximation which is totally nonsense yeah sometimes all the text is in an attachment yeah but send just negative attachment left out now well I would actually want patches attached to be included in the relay in the dumb message? no that's under the submitter we're talking about the closed message that is sent to the submitter saying your bug has been closed maybe if, would it map are you really complaining about the case of the attachments that are critically significant? yes so maybe if there's no need to have attachments in a dumb message the submitter the message is just very narrow in mind yes okay so it could even cut very low message but that's probably a lot more involved in the submitter the submitter and the maintainer already get two different messages right the maintainer gets the original bug for complete headers followed by the message that closed it and the submitter the bot actually didn't already get the closing message first followed by the bug I don't remember the bug is closed if you have those problems there's a few places of work and then you get a closed message yes but I there was definitely some difference in the ordering of the components the problem with the intercom is right at the beginning of the message that goes to the the original submitter there's just a lot of boilerplate there it's not I'm just wondering if there's some way of reformatting it so that the whether the maybe making the subject line or the message that closed the bug more obvious because right now I think it's like the third line and there's some text in front of it it just like there's it feels like it's difficult to tell from that summary what is going on let me see if I can find one the case I'm thinking of is installation reports where we like to attach a hardware summary and the syslog for instance and whatever it's you don't want them in the DOM message yeah well right now the DOM message goes this is an automatic notification regarding your bug before blah with the subject which is filed against the package package then closed by closed it and then there's information is attached below it's unsatisfactory shoot somebody contact mark mark find the message and then the attachments that's how it's done submitter closed we actually don't send the original yeah that's what I thought I thought the submitter closed was actually a little different it's the maintainer closed that has been I'm looking at one right now it's closed by somebody else and it starts off with I don't know I'm sorry it's weird because if you're the maintainer you can't consider the way around it I like it with the maintainer one but even with the maintainer one I'd like to see the message that closed the bug first but because you as a maintainer didn't necessarily close it exactly the act is different than the maintainer the submitter I sometimes find is annoying that I can't actually see what the bug again often needs submitter sometimes you some people then you forget what's it's about then you need to go live yeah but it doesn't start at the beginning of the it would be great to have a short introduction, white line not more entitled just right now it's a second line so I could just do a quick one I don't know I don't have a submitter close the handy so I can look at it and tell you exactly what I was seeing you can scroll down because the wireless connection was lost that's the first screen so it's almost like if you make the third line, the second line and then add white space and then have the bug number and the bugs would be clearer definitely so if you had just something like that yes yes exactly because people when people email us at the beginning of each paragraph the first line of each paragraph and if it's later in the paragraph I sometimes agree to look hard to find the subject of the bug so I'll reverse the the same goes for control confirmations it would be great if they could start with just bug number, bug title and then the processing stuff okay probably do that you remember all of this? he's making notes he's making notes one thing save your file before your laptop crashes like AJ had for his deck buff he has to watch the video to reproduce what was the tiny nine every time I see severity change from my mind can we please severity change from students yes I think it was one of those cases where you your eyes thought that you didn't care what the severity was what it is now all of the signs are huge step toward more that we now know from disability so I would like to every time I'm confused at the rate it's in there I feel it will also vary so is it really the wrong way around seriously I don't find it I'm trying to remember it's probably different from the order in which it's not it's probably different from the order in which the retitle works no the retitle does it too from I think actually most of them do it too from severity is the most weird one because then you can't really easily see whether the severity downgrade or upgrade and you look at the last bit automatically again you skip what's in the middle the boring stuff I don't know so I have no idea okay does every view just go from the two or do you want to go the other way around I'm going to standardize all on that excellent because it's both ways which is complicated okay what else something simple I think maybe maybe next if the pacifist has communication with our RSS speed for a bug log yeah there's nothing really stopping that should be easy I don't know the main thing that's annoying about is trying to jam a mail message but I can just I already have the stuff to rip out the first body part so I can just do that so in particular it will be nice to have an indication for the patch and for the particular bug so I can subscribe for one particular bug with my blog lines or something like this in a easy way for temporary things it's a bit unfortunate that like any RSS read this and go to Hammer to go track and test RSS speed annoying protocol oh that's good hammering the VTL RSS is not has full RSS files actually if we get one good caching of the stuff done which of course caching is basically static files but which is of course not too easy to do poly static files are only just too many and you will show that a lot of sandwiches are just a base where should be some of these the idea because the bug pages right now and if you have a gigantic bug log it takes a while to generate the bug log page the active core page that has a thousand bugs takes a while to generate I see it is it would be possible to kick the RSS feed users onto a mirror of the VTS that's not a problem I mean they can compete with each other to have as a thing which is what you can also do is already have the mailing list page but turn on the archiving for these mailing lists and make sure that the mailing list supports RSS from the archived mailing list and it's all done on the host address I doubt that it's going to happen and it's a formal list master and what about I think that's the thing guys, as you are not going to say I just want all the new messages I want to see any changes happening to the package so back to the real side I want to see my RSS feed for example which isn't so trivial anymore but which needs a little computing some can get as from the bug mailing list but the mailing list is just like you get a mechanic yes but perhaps I want to co-watch it basically of course I use 20 pts to co-watch it but if you do RSS you should do it live not just that it still works in some cases well yeah but if you subscribe it's going to work it's going to be subscribed you'll see what you decide what else sometimes the bug tracking system has had a denial of service attack from places crawling the packages links mainly the packages links the bugs links usually don't take that long to process but generally in combination with other things and so on and so forth well that's one thing that I think we're really interested in so we can't we actually have a school do with UTS although I guess they do they do have a mailing list well and they do actually if you really want to use Google you can use if you put site photos.dunharmshrung.com they have the index because I don't care if that bugs slow it's not my problem it works fast yeah so you can do that and also with the hyper straighter front end it has actually if it even though it is a little slow it returns within a couple seconds in like 20 seconds in the most yeah I think what we're listening to right now is just all the basically who you'll be able to search for a lot of that is to get much better results that we could do and that's developing some of the bugs to be working to get much better results for you know you can search for an error message or any plan if you work better I'm just guessing you're talking about users who are using Google users who are just looking for why they might be in service they would get a link directly to WVTS for that for that you need to provide a view to Google that doesn't provide like 20,000 different views of the language if you just want to Google excitement maybe you can tell Google excitement what types you have and maybe you can still say please don't scroll beyond that what we can do too is just do a user agent redirect based on user yeah so I don't know if there may be a list that will say sure as we mentioned earlier in dev talk there's apparently rules of deving folks at Google one of those would be talk to the search people and figure out the right thing for us to do yeah so now let me let Google.com ask them to fix yes they fix it about how to start when Google is interested I guess in it well because the dev and bug technicals is a good resource for problems and if we also software though so it would be very good for Google as well if they could use it sensibly so I think they're interested in covering them I mean knowing Google's willingness to do odd little special cases it wouldn't, I would always surprise me if they didn't study just special cases like the dev and bugs they have a tendency to do that by the time do they name them they've been promoting it lots about Hubstrike the search field the search field itself I asked for documentation just a few days and so on I would also like to see some documentation for how the search field can be useful and or queries and stuff like that yeah I'm sure what I think I'm going to do for most of that is link to Hubstrike documentation but what is it much more even though I think it's written by some sort of weird English but it's at least more understandable than I could do it just by replicating it I think I'll probably link to that and explain what the pre-options to anybody that has any comments on how the spam is handled or any spam assassin experts that can help me with certain things I don't know I'm the one that's been handling all the spam on the bug tracking system like in the past few years you should speak as much as you can if you can do so okay I think actually you're going to get together yeah that's going to be a this monster BTS meeting there's one one parameter that I need to and I haven't found it yet okay I'm not even sure it's variable but we're running an older version of spam assassin 2 because spam assassin decided to completely change their pearl interface in incompatible ways not much of it for obvious no good reason but us also he does that stuff for his work too so he already has my very part of Rosemary's work which has quite much do you only look at messages once when they arrive or will you like recheck them when you discover a new kind of spam and see if the old letters was kind of like that look at them once when they were well okay the automatic system does the spam assassins have some filters other than spam assassin does spam assassin based on the spam assassin score spam assassin score is greater than 4 it throws it in the this is spam folder which is over 2 gigs a day typically 3 to 4 and if it's less than 4 it goes on through to the by the control processing or whatever then after that I manually go through and look at everything that scored between minus 1 and 4 and then clean out the bugs that had something between that and I use all of those messages to train the Bayesian filters so something that scores in the middle you know scores like 1 gets that's not spam gets help to trace the Bayesian filters because you need to balance the amount of spam and ham or something like 300 spams for every ham and the Bayesian database at the moment there's only a few hundred thousand ham or a couple hundred thousand ham in the Bayesian database right there's millions of spams because the reason I'm asking is that sometimes I get the spam to a lot of bugs at the same time with the same subject or whatever I did they can take time but I really manually it's almost all the cases that they scored between 1 and 4 and I get to go through all of those bugs and clean them out which gives me good incentive to catch it at the early stage if I possibly can unfortunately there was one a month or so ago where a lot of them scored minus one and a half and so those are I'm gradually cleaning out report this bug has spam and well actually the report this bug has spam does just goes to gives me a list of bugs that's been done to when I go through those with the same process that I do with the ones that score between minus one and four those image link spams that we had two months ago were really fun couple hundred and seven days two weeks couple of hundred is there have been days when I've gotten 5,000 I've cleaned them out of the lists we are getting a lot better at keeping the lists a lot of it is I'm currently unemployed and have the time to check it thoroughly off and we're lucky when I was on vacation for a couple of days that nothing much got through yeah if somebody else wants to help with the task especially if it's someone who will be in a different time zone yes and patches are always accepted well as if you were working with that it would be quite appropriate you would welcome that you should make the 6,700 they're accepted but I'm just writing to a circular file oh ok and any other suggestions, comments could you make a decision that the patch the back comes in you've got a very great patch that fixes it it would be really useful and that's the upload when I'm ready to lose 10% of my money oh yes I can the members in your testing bug if I use bts-mbox if I take an mbox where the bug title is not non-asky it gets false and you check whether that still happens to current bts the bts command come on I used to check it like that it happens first so bts command there was a bug I changed the way I do URLs I do them in a totally automatic well, relatively automatic fashion you just pass the parameters and it builds the thing for you and so it was broken for a while but it should be ok but I don't so ok there's the answer you can always use get get if I need it somehow and it always finds my bug anything else oh ok so again if you have any more suggestions for 3-5 bugs a couple of things we talked about there actually are bugs already against bug subject but it's always ok to file bugs harassment, IRC, that's fine so don't forget to if you're developing stuff that needs to be created in bts you should probably start using the SOAP interface if you don't know how to do that or you want features that aren't currently enabled or you want me to show you where the documentation is what little documentation there is of it right now ok thank you everybody have fun thanks