 Okay, Herm, hello everyone. This is the state of the BTS, with the owner of bugs.debian.org, Don Armstrong. Yeah, so I'm actually only one of the people who is owner at. So if you want to follow along, if you want to follow along, the slides for this presentation are not very informative, but they're available on rzlab.ucr.edu.debian.dc9. And so there's two talks there. You want the one that's obviously the state of the BTS. So just a brief technical overview of how Debugs work. Those of you who've seen my previous talks have already seen this diagram. So mail comes in, it's desband, and the desband process is pretty much entirely written by Blares Blarson. He's in the back. He basically takes care of making sure our BTS is relatively free from spam. If not for his work, we'd be totally drowning. And from that, it goes into process all. So we're actually in the process right now of taking the mail in and spam processing part and splitting it onto a separate machine from the rest of this. And that'll enable us to scale out slightly better and make it a little bit more robust in terms of receiving mail so that if we start getting mailed by spammers, we can spread it over a larger number of hosts. Process all actually then takes all the desband messages and then shoves them into two different scripts depending on where it was received. One is service, which deals with all the mails that you send to control at or request at. And the other is process, which handles the mails that go to submit at and any number, number, number at bugs.dev.org. So anything that you send to 1-2-3-4-5 at bugs.dev.org or 1-2-3-4-5-submitter, that all goes to this script. So these two scripts basically handle everything that goes to the BTS. And then it's stored in db.h, which is sort of a slightly expanded flat file database. Each bug has a few files located in a slightly hash directory. And from those we build indexes, which are then used by the CGI scripts that most everybody actually interacts with directly. And the CGI scripts also can read from the database itself by raw. So just sort of to orient everybody to how it works. So while that part of the diagram hasn't changed much, because it's relatively sane, the actual underlying code that drives it has changed quite a bit in terms of its architecture. So the primary reasons that we've changed this is because, first off, the original system had a whole huge set of monolithic scripts. Basically, control and process were a monolithic script that included a relatively monolithic Perl library, none of which was used strict or used warnings able at all. And this also meant that it was pretty hard to test. And it also meant that changing just about anything meant that you had to keep the whole concept of what was going on in that particular script in your mind in order to make even a small change. So one of the things that we've done is we've abstracted the functions out so that we can actually start testing and maybe hopefully doing some unit testing in the future. And it also this made it really difficult for new contributors to get started. So hopefully the changes that I've made have or will enable some new guinea pigs to get involved with Debugs. So what I've been doing most recently is primarily working on modularization. And this is all sorts of changes that aren't very visible to you all. But we've gone from a few Perl modules to, at the current writing, 32 modules. Almost all of them are used warnings and used strict as any Perl program should actually be doing. And I've also switched most of the code base now to using the params validate module. Which the useful bit about that is it enables you to use name parameters when you're doing function calls. So it means that the functions are relatively self-documenting. There's not a case where you have to go back and look at the documentation for a function to figure out what argument number five to this function that happens to take a hundred different arguments actually does. It also enables you to do some pretty neat things in Perl. And we also now are able to write tests that test a single module or small functions in a module. We don't have to bring up an entire BTS copy in order to run any tests. So just I'll give you an example of a couple of things that we've modularized out. This has Debugs common for example. So there's a big file that's called error lib which contained a whole set of functions. And these are just general functions that are included all over the BTS. And we went from having a huge number of package or even Debugs wide global variables to almost none. And there's some new routines in here that I happen to use a lot. So make list is an example. For those of you who deal with Perl, one of the annoying things is when you pass a raise or scalars to functions, it's nice to be able to automatically turn them into appropriate type of object along with the referencing. So this does it all for you. Another thing that's changed and this is probably more interesting to most people in the room is Debug status. So when you call the SOAP interface or you use BTS status, what you're actually seeing is the output from a function in here called getbug status. And so this function or the documentation of this module might be of interest to you if you're using the SOAP interface because it explains a little bit and eventually it'll explain completely exactly what the SOAP interface is returning. And this has everything to do with the status of the bug including how to read and write the bugs. And also how to test, for example, whether a bug is archivable. And then the other thing that's changed massively is the way we handle configuration. So beforehand, we used to just read in and require the config file. It's written in Perl. It's a pretty simple way to do it. You just require it. And you let this config file touch whatever it wants to. It can mess with anything it wants to. The problems with this is it makes it extremely difficult to have a zero length configuration file that does anything sane or slightly more complicated, a relatively short configuration file which changes a couple major variables and then sets everything based on that in the same manner. So what we've done instead is we load this configuration file in a safe partition. So it's like a little code or a little subunit in the Perl namespace that isn't allowed to touch anything else except for what we allow it to touch it. And then now we can read in the variables that are being set in this file and then based on those variables, set all of the currently unset variables to reasonable default values based on this. So the practical upshot of this is that if for example you were to set my domain name for my BTS is bugs.foo.com for example, all the other things to depend on the domain name of your BTS automatically get set for you. So it knows the web pages at http.bugs.foo.com, the CGI's are all in this particular location, the web pages are all in this same place, the mail domain name is here, a good default value for the list domain name is on the same domain, etc. So all that happens automatically. The most important thing that this enables me to do though is it enables me to test a full up BTS very, very simply. So with a four line configuration file, I can override the copy of send mail that I'm using to a local copy that all it does is take the mail, shove it into the disk. I can override the location of the spool directory which is what has that db.h thing. And so now I can actually run an entire test of a full up BTS by sending mail to it, looking at the mail that comes back out of it, checking what's happened on disk, all in a single make test inside of the debug source tree. And so that's helped a lot. So I would have, you've probably already seen that I've broken the BTS on a number of occasions. If I didn't have this available to me, probably still be broken because I wouldn't have been able to figure out what I had done wrong. So this enables me to at least stop the really hideous bugs that would totally block anybody from doing anything at all on the BTS. The final thing that I'm just going to talk about, I'm not going to go through all 32 modules because that would be kind of dumb and really boring. The final thing I want to talk about though is debug bugs. And this is also an extremely useful module if you're using the BTS command line tool or also if you're using the package report CGI. This is how we actually select any bugs that are output. So if you use BTS select and you go package colon, I don't know, debugs, tag, colon, help, for example, all of those get parsed and put into a SOAP request, which then gets dispatched to the get bugs function. That's actually the really the only major public function that debugs, bugs provides. And so this function is kind of interesting. It first starts off and it tries to send the entire request to the indices that we have. So we have a bunch of indexes that index things like packages and sources and maintainers and correspondence and some other stuff. But we don't have indexes for everything. So if that particular module isn't or function isn't able to satisfy your request because you wanted to do something crazy, it gives up and kicks off control to the next one which actually goes serially through every single bug. There's an index file which has a bunch of things about every single bug and goes through that file linearly trying to figure out exactly what sort of request you wanted to do. So for example, if you were to search for bugs and packages which have no maintainer, that's the second serial thing that happens. So if you're ever running a request that suddenly takes a lot longer than you would expect it to based on the number of bugs it's returning, that's why. It's because you've probably triggered a request that doesn't have indexes and it's gone to the second thing. And the documentation within it is pretty complete. So if you're ever at a loss for why the CGI or the soap routines returned a particular set of bugs, this is the module that you can look. I promise it's relatively readable. The documentation is there. So if you find yourself getting confused, check it out. Okay, another thing that's changed and this is, the inside part of it isn't very interesting for most of you, but the effects of it are extremely useful is the fact that I've now started to abstract out all the control changes. And so almost every control action, and I was hoping to have totally finished, there's only the slightly more difficult cases of merging, unmerging and cloning bugs that are not yet done, has a corresponding function in Debugs control. And so what this is going to enable us to do is to do useful things like modifying all aspects of a bug at submit time. Also, perhaps sometime in the future, we'll also be able to do things using a web front and directly talking to these functions. So we'll be able to modify bugs in a much more elegant fashion instead of having to always send out a request to control. The basic way it works, argument parsing, begins a control request, and all the stuff on the top is all, so steps one and two and five, six and seven are all implemented the same way every time for every single bug request. So that means that there's no duplication of code that does this. So you'll always see the exact same header for every single bug when you tell a control message to do an action on a bug. It'll always tell you what the bug number is, what the bug title is, what the package is. So that's what enables us to do all this at once. And I've just lost my microphone. Am I back yet? Okay, then I've gone deaf already. And so this enables us to make everything the same so that it's quite a bit easier to update things, etc. Okay, so with that, that was kind of boring. Let's talk about things that you actually care about. So one of the most important things that most people are interested in are the new features that I've added. So I try to work on adding new features, and I sort of piddled them out as time comes. So the one new feature that I wanted to talk about today, I'm going to talk about a couple. The first is effects. So one of the common problems in Debian, especially if you're maintaining moderately heavily used packages by users who don't necessarily understand how the package work, i.e. probably 90% of your users, if not more, is that if there is a bug in, let's say, package A, maybe we'll call package A Lib C6, which causes a problem in package B. So let's imagine that you have a bug somewhere in Lib C6 which causes, I don't know, Emacs, for example, to segfault, okay? Or make it worse, iSweazel, okay? So what's going to happen is you're going to get a few thousand users telling you that, yes, iSweazel is crashing. And that's not entirely helpful to you because you've seen all these bugs and you know exactly why iSweazel is crashing. It's because Lib C6 has a bug. So you spend half your time reassigning bugs to Lib C6 because that's actually the package which has the bug. It just happens to be that your package is the most visible package for the user. And so they report the bug against your package. So what this enables you to do is you can now go and say, okay, this particular bug affects package foo. And so by default, then this particular bug, for example, if it was bug 1, I would say, okay, control affects 1 iSweazel. And so now by default, this bug will show up in iSweazel's bug list in the default view. So the casual user as they're viewing it will at least see the bug and know that it's there. You can also exclude this so that it won't show up as well. I have to add the option to do that so that it'll be done for people by default, but it can be done. And so this is how you would do that. So hopefully this will reduce some of the bugs that are filed. And so this is just an example to show you that it works. I have no idea why there's a black box in the upper left-hand corner. But anyway, the important bit here is, so this is the bugs for debugs. It's got version whatever it has. And this right here, which you can barely see, is a bug that's in bugs.debian.org, which I've marked as affecting debugs. And it's because I get this bug file a lot that says that the CGI options are not working. Well, they actually are now, but people keep telling me about it. And so this bug happens to be merged with a whole slew of other bugs, and that's where it is. So the other thing that I wanted to talk about really briefly was summary. So sometimes what happens is you have a really long bug thread, and the original bug report isn't particularly informative as to the actual problem. So you spend part of your time going through and figuring out what in the world the actual issue with the bug is. And hopefully at some point in time you come to the understanding that, okay, no, this is the actual problem now. But unless you totally fix the bug at that point in time, if you later come back to that bug, you're always in the position of trying to figure out again, okay, at some point in this mail log, I figured out what the problem is. And so you spend a reasonable amount of time figuring out what message you decipher that at least I do because I can't remember, you know, in a message, a bug log that has 40 or 50 messages, I have no idea what's message I wrote that summarized it properly. So what this enables you to do is you can summarize a long discussion into a single paragraph. And what this enables you to do is extract the first non control, non pseudo header, non quoted paragraph from a nominated message. So basically, this would be a, even if you did a reply to a message and included some control things, or a pseudo header or something in the message, you would skip all those paragraphs until it got to the first bit of your reply, where you would presumably go, all right, this is what your problem actually is, blah, blah, blah. This is what needs to be fixed period in your paragraph. Then later in a control message, or once I fix this in the same message, you'll just say, oh, yes, this contains the summary. So the summary for message or bug one, two, three, four, five is in message number 30. And the message you get is straight from the CGI. So you'll show you message number whatever you look at that message number and say, yes, that's the message number that had the summary. And this will nominate it. So this is what this looks like. So I think it was message number 28 in this particular bug about, I happen to like this bug. This is my bug to use for options here. So this is again the same bug CGI options not working. And now there's a summary. So it's already fixed in my tree and will be fixed in the BTS the next time I sync whatever the, sync them up. So this is the summary of the current state of this issue. So I don't even need to read the rest of this bug report. I can just look at this little summary bit here. And I know exactly what's going on with it. Yes, it's actually exported by get status. So if you are interested in getting the summary via soap, you can do it by BTS status and the bug number. And it will give you the actual text. So in the BTS, this actual text is stored in the summary status. We don't actually continue to store and continuously extract which, or that text from the bug message. So this is just a one shot thing. Another new feature that BDEL actually I heard the first time about in debcom four or so, something like that is the ability to run a local copy of Debugs. And so this is something that once I fix one more bug in it, I'll make an upload to experimental so you guys can install it that enables you to run a full local copy of Debugs. And so you can select a set of bugs that you're interested in by a configurable query. You can either give it a set of bug numbers or it has all the ability to do the standard select commands that you can do if you use BTS select. So by default it selects unarchived bugs which are in packages you maintain, bugs that you've corresponded with, bugs that you've submitted, or bugs which are RC. And so currently it takes about two gigabytes which is almost entirely indexes which needs to be optimized a bit. But it'll be part of the experimental Debugs package. Yeah, no it's not. So once I have a local copy of Debugs can I manipulate it? Okay, so you can send messages but you can't manipulate it currently on the machine itself. So it doesn't have all the stuff to do the manipulation of your local copy. So you can't actually work offline on your BTS and see your changes? Or then later merge? Well because the way you would do your changes, yeah, so the way you would do your changes and the way I may make it work eventually is you would do it by queuing up mail messages. So you would have your local copy and you queue up your mail messages and eventually they flow, that's how you would merge them with the upstream. And so then later on you would go and say okay yes update me again and it would pull them all back. So assuming you have a laptop that can queue mails or whatever you're using can queue mails, this will basically work. It is though a feature that I've thought about to be able to modify the local copy. It just, it's more complicated so I haven't done that yet. But actually as soon as you start queuing mails you could at the same time just write to the local copy and forget about the changes as well as this thing, so. Right, but the logic to do that aspect of it is what I haven't written. Of course, just to show you that it's working. These are the commands that you would run. So let me see if I can demo it here if it will work or if it'll explode. Let's find a terminal. I have no idea if this terminal will be readable, but we'll try. Oops. Okay, can you guys kind of see that? Okay, well the critical aspect is, let's see where we, okay so the first thing to do is to run localDebug's mirror which will run whatever command or whatever queries you had configured and download all the set of bugs. This takes a while so please, if you build a copy of this yourself, please don't do it here because it's a little bit suboptimal right now. The next thing you do is you start the demon. So let's see if I have it installed properly. Maybe I already started it. Okay, looks like it's succeeded. And then we have a couple different things. The most basic stuff is to interact with the package report or the bug report CGI. So if we want to see a particular bug, so in this case 4 4 1 1 5 1, we can just go local Debugs, lowercase s 4 4 1 1 5 1. It'll send a request off to sensible browser to look at the local, the local Perl web server that's running and if I, once my machine decides to redraw my screen, it's not totally working apparently, but if it was this would show you the actual request. Let me see if I can fix this. Okay, I apparently had a different version installed than the one that I had in my source tree. So this is a local copy running on port 8080 on localhost of Debugs showing the same bug that we've been looking at the entire time. And as you could tell it has the whole thing there. Yes, everything works just as it would normally, or it should work. If it doesn't, it's a bug that I need to fix. So that's that. If, for example, we wanted to see that a package which I maintain, so I happen to maintain Lily Pond which has an interesting number of bugs, I just started so it's not entirely my fault. So we do the same thing, and these have longer names by the way than just the upper and lower case s. It just happens to be what I'm showing you. So this will take a second. Hopefully it'll just take a second. But anyway, so this will show the package report page for Lily Pond once it figures itself out. So this is again also running on localhost 8080. Same thing. It looks just like a normal BTS except it's running on localhost. The port that it runs on is of course configurable and some other stuff you can do. It's just a standard HTTP server that's, it's running. So it's that Pro module that's actually doing all the work. I just sort of fork out to our CGI requests. And so these are the bugs there. And in theory anyway, yes, the links actually work. In theory. So hopefully they do. Let's try to load it. This machine's a little slow. So yeah, there it goes. So and in theory, at least even the version graphs work. Yeah. So yeah, this is really a local copy. You're actually running the real code that would be running on the BTS. So this will only be in experimental because unfortunately there are some people who are, well unfortunately I don't know, but they're running Debugs in production. And I'm not yet ready to inflict the current version upon them. So I don't know whether it's, this is going to make it into a release or not anytime soon. But I'll try to make it so that it's releasable. So if you use this and you find bugs, or if you're a current user of Debugs somewhere else and you have systems that you can use it on and tell me if it's totally busted for your install, that would be useful and it helped me clue me in as to whether I can actually release this. Okay. So there's some issues with it. It has really suboptimal missing bug handling. It sort of just tells you that there's an error. It doesn't prompt you that, hey, I can load this error into the list of bugs that you can look at. So the next time you sync up I'll include it. So it isn't able to do that. The size of the mirror is large. Most of that is in index files. And so what may end up being the right approach is to not bother to sync the indexes but rebuild them. But I haven't really figured that out yet. Once you actually mirror this, additionally syncing the indices is not all that hard. I mean it's just an rsync and they're rsyncable. So that works pretty well. But it's something that could be improved. It also could be faster to sync. Right now I figured out that running include arguments on rsync is a really bad idea, especially when I kind of know what the file names are. So right now it's sort of just shoves a file, list of files that it should be getting at rsync, and it doesn't really distinguish between whether they're archive bugs or unarchived bugs. So rsync throws a lot of error messages about files not existing. But in general it does a reasonable job. So that's something that's technical that needs to be fixed about it. But it works to some degree. I have a very quick question in relation to the BTS command. It has a cache, like devscript's BTS cache, which basically downloads the bugs, rewrites all the URLs and makes something similar to this working. What's the benefit of the of the whole bugs install? Well so the benefit here is that you have a full fully working BTS and so you can do select queries and stuff that you couldn't do easily using BTS cache. It also means that the updates for this are much faster and it does things that it's just not possible to do in BTS. Like with this you can actually download the mail logs, for example, where you could do that in BTS but you had to know beforehand that you wanted to look at the mail logs. So with this it just works basically. So I mean BTS still has a use case but it's just slightly changed. Does that mean that the SOAP interface is also working on the local machine? We could make it work. I don't think I have the, I don't think I've written it so that it knows about how to execute that CGI. It's sort of limited. It knows about the CSS, the package report, the versions and the bug report CGI's. But I could certainly. Well you mentioned BTS select. Doesn't that use the SOAP interface? Yes, well so the yeah I could certainly make it so that it would work properly with that. You would have to change of course the URLs but that's configurable in BTS as well. Okay a couple other tips and tricks. One of them is the ability to do full tech search. This has been around for a while but I don't think enough people know about it so I'm going to talk about it again. Currently it uses HyperStrayer. I'm not certain if that's really the best way. We may have to switch to Zapien or something else. But that's its URL. So an example we can do is we can search for LP0 on fire. Let's see well if I can do that. I have no idea where I did that but anyway I'll open up a new tab. Assuming I have network on this machine right this second. That looks like a deal. Okay so this is a pretty advanced thing that we can do and because of that unlike Google where you sort of put words in it automatically figures out with the words split on. HyperStrayer enables you to make exceedingly complex queries. So by default everything is a phrase and as you can tell I need to document this better because I didn't tell you that at all on this page. And so if somebody wants to do that for me that would be really great. But anyway we can search for example for LP0 on fire. Classic error message. And so there are four hits in the BTS which actually indicate people's quote pages which talk about the LP0 being on fire. So apparently no actual error message is involved in bugs. And the links here work of course. This actually goes to the bug report. Okay that's that's sort of exciting. Let's look for something else more interesting. So let's look for memory. Maybe I already had it here. Ah we can go search for memory leaks. So leak and memory. So this looks for leak and memory in the same search request. And so we get 2000 some odd requests. We want to do the classic complaint. We're going to add an attribute and we want to look for a package. This is suboptimal here but a package that includes since the package is a string and we want to look at ice weasel. Classic complaint that ice weasel is leaking memory. So we just click search again. So it takes a little bit longer because it has to go through and check with this attribute. Assuming that Merkel is still standing it'll return eventually with the results. At least it was earlier. Yes in the meantime is that a search device linked? Yes it's linked from the front page. Yeah was I missed it? Oh there it goes. So there are 10 hits for ice weasel leaking memory that you can see. And so this is slightly useful because it will enable you to put in error strings and stuff and find bug reports that have it. Google is also now indexing the BTS so that is another option as well if this is slow or not working for whatever reason. So that's something that's useful. Another thing that's useful is that's recently changed are the CGI options now work again. So this means that you can do relatively complex queries without having to know precisely what set of things you have to type into the URL. All these things can be done if you know all the URL options but almost nobody does. So let's do a couple examples here. So what did I say was the first one? So first let me look for bugs which are in debugs which aren't tagged, pending or won't fix, which happen to be owned by me. Okay so first we'll search for bugs and debugs. So there's our bugs and debugs. Go all the way down to the bottom here. Oops that was good. Okay so we have bugs and debugs and we want to exclude bugs which are tagged pending. Okay that's good. Fortunately currently you have to go through the submission process every time but also want to exclude those that are tagged won't fix. Okay so we've sort of drilled down the bugs a bit. And I only want to look at those bugs which are owned by me as well. And so just like that we've drilled down to a small set of bugs. So that's an example of the different things that you can use with these options. You can see that the URL that we're using has gotten quite a bit more complex than we started out. We started with just package equals debugs and it's done all of this. If you ever get a URL that somebody sends you it also is smart enough to be able to populate this by itself. So it can do all that. You can exclude bugs with just about anything. If there's more things that you want to exclude let me know. You can file bugs ask for them. You can also include bugs. So this would only include bugs. Oh I should also point out too that if you add additional things in here for example if I wanted to look in bugs which were in either debugs or bugs.debian.org which were owned by me but weren't tagged pending or won't fix you can just add an additional package here. So for example bugs.debian.org helps if I spell correctly and so this is and it tells you what it's searching for at the top. This is bugs in package debugs or bugs.debian.org which are owned by me shown as if they were in unstable and then that's what it shows up. And so do play around with these options. You can do quite a lot there. Most people don't really use them to their full potential and if you have ideas about things that we should change for that let me know. So we have about 12 minutes left here so we're getting to the end. So what's next for the BTS? These are the major things that I'm thinking about doing. Obviously I currently have something like 150 or so some odd open bugs against debugs and bugs.debian.org so there's a massive number of things on the to-do list but these are some of the things I think are more interesting. So the first one I sort of talked about which was control commands in submit and messages to a bugnum. And so this is something that is all the ground work for it is done. It basically needs me to sit down and start rewriting process which will take a while but probably in the next couple months you'll see an announcement with this. The other major thing that was brought out by the earlier bot which we talked about people drowning in bugs is trying to order bugs by action item so that you can figure out which bugs require an action. So when you're a maintainer or a bug triager or somebody looking at the list of bugs there's a way for you to order the bugs in packages or whatever that you're interested in in such a way that immediately at the top you see the next bug that needs something done to it. So you don't spend your time trolling through the list of bugs trying to figure out which bug. Because honestly in a lot of times that takes just as long to find a bug that you need to do something with as it does to actually do an action like send a mail about a bug. And so that's something that needs to be fixed. I'm still thinking more and more about how to actually identify the bugs that require actions. So I'll open a bug against that bug shortly with my initial thoughts on the matter and if that's something that you're interested in or you have ideas on what bugs are important for you to respond to that would be helpful. So that I make sure that this is as flexible but at least initially covers as much of the common use case as possible. Another thing that needs to be changed is we need to keep state on the package report page and a couple other pages using cookies. There are a lot of people who like to be able to view package report with everything expanded by default and so I want to be able to have them when they click that until they click the expand everything option it stays expanded for them by default. If you're not using JavaScript it's expanded by default because there's no way for you to toggle it on or off so that's the way we keep it but that's something that needs to be done. I also want to use cookies in a couple other ways to try to make sure that when it's possible the view of a page that you were looking at is the page that you come back to so that if you spent your time to set things up you can return to it. If somebody also is really good at JavaScript I would love it if somebody would enable a tabular display using like jQuery or something where you can actually select which columns you want to see from the bug report and immediately in this table order by different things so if you want to order by bug number or by severity or what needs to done and filter out on this table as well and so just in a small table like that it would enable you to really easily sort your bugs and drill them down in a much better way instead of having like we have now where if you have a large number of bugs you have to go through three or four pages of bugs this would enable you to have a small page of the bugs that you are currently interested in and to change that rapidly. The other thing that we're working on and which a lot of work has been done on BTS link not by me thankfully but Lars and Christina a couple of us have been talking about ways of better integrating with upstream bug trackers and also bug trackers and other distributions so it would be really nice if upstream was able to export in a common format that multiple bug trackers supported that provided information as to what the state of the upstream bug was immediately available and we could also see for example what the state of the equivalent bug was in SUSE or Ubuntu or Red Hat or I don't know whatever all other distributions you were interested in so that if someone had managed to fix this bug that happened to be forwarded to it would be immediately apparent by anybody viewing that bug on the page because the BTS would know exactly what was going on and you could go ahead and say ah yes Fedora has fixed this let me go find their patch and import it or at least communicate at least be aware of that fact. The other thing that this would enable us to do is if in addition to exporting state it also enabled us to export the conversations about the bug especially upstream in a single page about the bug in Debian you'd be able to see exactly what was going on in the upstream bug tracker about the bug so you'd have an idea if something else needed to be said about it so this is sort of a pipe dream as it were but it's something that we're interested in at least trying to lay the groundwork and as many major bug trackers as we can. So with that I am open for questions I have to of course thank the rest of the Debugs team a lot of people who have done a lot of work besides myself so with that I'm available for questions or suggestions. There is a few questions on the RISC channel the first one is from MRBN I don't know who is here. Can you make it possible to select a users in the web interface and show that user tag and a way to see all the user tags attached to a package or a bug number? Okay so yeah that is something that I've actually been thinking about is currently in the CGI options there's no way to show which users are available to look at a particular view and so that's something that needs to be thought about. One of the things that's also sort of in there is some people would prefer if their user tags were I mean user tags are necessarily a personal view of the world and so it may be a question obviously they're already available to all developers and there actually are publicly available if you know where to look as well but it may be something that people want to by default not be shown so that's something that I need to think about a little bit but it's definitely an idea that I think there's already a bug about it but if not I'm aware of it and something that needs to be changed. Okay the next question is from Marga let me see well in the middle my question is that it's any way for the future to implement syndication or RSS for the bugs and for the search? Yes so it would be possible. The main concern that I had originally and why I had never really gone deep into implementing RSS is primarily because I didn't want RSS feeds banging away on the BTS constantly all the time so however most of the bug pages at least now do appropriate things with last modified so that they know whether to short-circuited request. It's not so for a package report but at least package report now and the whole web facing part of the BTS is now spread over three machines and so it can trivial relatively trivially be spread over more as we have hardware resources and the need for more machines. So it's something that I can now again contemplate doing because at least if somebody is banging away at the RSS feeds it won't cause everything else to fail. Maybe you can use Jabber or something like this. Jabber. Jabber to if you have new messages or something is to send it. Oh yeah but I mean anybody who wants can consume the feed so I mean that people want it in Jabber or they want it in IRC or whatever they can write those adapters. There's no way I'd have time to do that so that's something that once I get in an exportable format from RSS or from XML that's oriented by timestamp somebody else can do the transfer to do that pretty trivially. Okay the question from Marca in IRC is how far are we from being able to apply actions through SOP? It's O-O-A-P and how will that work regarding authentication? Okay so one of the issues with that is that currently there's a lot of locking involved and so a lot of the code has all the locks in place but it assumes that it's the only writer and they're relatively big locks that make it extremely difficult to implement a case where you have a lot of writers who are non-synchronous but with the abstraction of control at least for some operations if you're okay with a little bit of lock competition would be a possibility of at least starting to think about so I mean if it's just me working on it we're a long way away because that means I have to do it but if other people come in and help then we can be going a lot faster but at least the groundwork is laid towards going to that position as far as authentication goes that's always been one of the issues of course currently we don't require authentication at all for the BTS so the main question there is just avoiding abuse and it might be a case of having open ID from a set number of providers or requiring dpg sign messages or something like that some way of associating yourself with the BTS so we at least sort of knew who's coming from so we have two minutes left so just a couple more questions yeah so currently the BTS has a knowledge of whether a patch is or is not attached to a bug but it has no knowledge on where is the patch in a sense it is not able to identify the patch so have you ever thought about making that support on the server side because that would enable a couple of cool things one is automatically downloading the patch and the other one is marking a patch as obsoleted by another version of the patch which get posted afterwards so yeah I haven't thought about that but that is something that would be useful to say is specifically which message encodes a fix so please file a wish list bug against Debugs for that because otherwise I won't remember with patch yes if possible any other questions or comments so I mean I'll plea again but if you're at all interested in how Debugs works please feel free to join in our code is available on btasetr if you have any questions you can ask me in pound Debugs on OFTC or in any channel that I'm in I'm Don Delacaro on most of the networks so feel free to ask questions and jump in and help out thanks for your attention