 Okay, the next talk will be about Debugs, the software of Box Debenog, and it will be held by Don Armstrong. Thank you. So for those of you who don't know, my name is Don Armstrong. For the past few years, I've been the primary developer behind bugs.devman.org, although I've been helped by a bunch of other people, including Lars Blarson, Colin Lawson, Anthony Towns, and a whole bunch of other people who originally wrote the code. But most of what I'm gonna talk about is stuff that's happened recently, or relatively recently, in Debugs development. Hopefully also throughout this talk, I'll get some of you interested, or some of you who are watching this talk after the conference or streaming. Some of you interested in contributing to Debugs. Unfortunately, I'm a postdoctoral researcher, and so my day job does not allow me an infinite amount of time to spend developing Debugs. So I need more cannon fodder, as it were, to help me develop and make Debugs a product that enables all of you to maintain your packages in Debian. So to that end, the goals of this talk really quickly. First, I wanna introduce you a little bit to Debugs. So for those of you who aren't aware of how it's set up, what the architecture looks like, I'm gonna talk a little bit about some of the new features that I've implemented. I didn't, unfortunately, get to implement as many as I had planned on during Debcamp. It's one of the nice things about coming to Debcamp. It's the most development on Debugs I've gotten done in probably a two or three month period. So, but I always think that I can get more done than I'm actually able to do. So I'll talk a little bit about those, and some features that are going to follow very soon after, as soon as I get this talk over with. The next thing I'll talk about is a couple tips and tricks, then also some planned features that we have planned for the future. And finally, the most important, as far as I'm concerned, is the places that you all can help me. So if I can get at least one, and hopefully three or four or more people who are interested in helping out in some small tasks in Debugs, that would be really awesome. And you don't even have to know Pearl for some of these. So, the BTS has a couple different goals. First, we want to enable the proper reporting of features or, well, bugs. We also want to be able to track the evolution of bugs. So let me step back just a second. So reporting of bugs here, report bug in some other packages help us a lot. As much as we can, we want the bugs that are filed in Debian to have as much information that enables the maintainer of the package to resolve the issue. So at the time they reported there's enough information and also we can add more information later about what the state of the bug is. We also want to be able to track the evolution of the bug. So not all bugs that are filed in Debian come fully formed with a patch that's brilliantly executed, has the exact problem description where you can just take the patch, apply it to your package and be finished. There's always, or often a period where bugs are assigned to the wrong package, they have an incomplete problem statement, you thought it was one problem, it ended up being something else, or you find out that it actually belongs in an entirely different package. But we want to keep track of all that. So we want to be able to go back and see what happened when we were working on bug X. The third thing and probably most important for all of you is to enable us to fix bugs. So anything that dev bugs can do to make finding and fixing bugs easier and faster, less painful is a good thing as far as I'm concerned. So I mean, the more time you guys are out there fixing bugs instead of playing with altering state on bugs and finding a bug to fix, the better as far as I'm concerned. And the final thing, and this is especially with regards to testing in Britain, and app list bugs and some of the other neat tools that consume the information the BTS provides, is to reduce the impact of the bugs. So if we have particularly severe bugs, we want to make sure that we're not extending those out into testing and we're not releasing with those. So this is a third, or sorry, the fourth goal of the BTS. So with these four goals basically covers everything that that bugs is doing. So how many bugs do we actually have? We actually have more than apparently Windows does. So this is bug growth versus time. So as you can see, we've gone from nearly zero bugs to a lot. This is Christian's favorite plot since he's always interested in what time we're passing through different hallmarks. So as you can tell right now, we're roughly in a linear phase and we tend to average about 136 bugs filed per day. These statistics aren't very accurate, but just gives you an idea of what's going on. So there's a lot of things going on. This is the blood closure rate over time. This is a little bit of a guess. This is actually tracking when a bug was archived, not when it was actually closed because figuring out when it closed is a little bit more difficult. And for this, I only have data since I turned back on archiving in about 2008. So this sort of shows what's going on. And some of these big ones are, I would imagine, are close to release time or some other time when a whole bunch of packages started flowing back into the archive. We seem to close around 138 bugs per day. This is just a guesstimate. It's obviously not the same, but it's of the same order of magnitude as the bugs that were filed. So we're not losing ground to the bugs. We're keeping up, sort of. This, though, is not such a pretty picture. These are the RC bugs that have been filed and fixed in the past year. So the ones that most matter are bugs that affect testing. So you can see that we have a little bit to go before we're ready to release. This is the case as of some time, a couple days ago when I did this graph. You can always see this, of course, on bug status. One of the things that would be nice if someone could take and rewrite the graph's part of bug status to use R. This is all done at R, and I haven't had a chance yet to do that. Anyway, these are the plots. So on the top, you can see the total number of RC bugs. This is the bugs affecting stable, testing bugs that have a patch, bugs that are pending, and at the bottom here are bugs that are marked ignore. So yeah, obviously too many RC bugs. Okay, so with that, I'm gonna talk a little bit more about how the BTS is structured. This is basically the current structure of the BTS. Debugs itself lives in this area. So we have three machines right now, three of which are operating as web front ends. So Bisoni, Lindbergh, and Duarte. Lindbergh and Duarte are connected to the back end, which has a flat file system with various Berkeley DB indexes. And Peter Weasel wrote Smart Sync, which is basically a tool that uses iNotify to notice when the mailing back end modifies a file, it R syncs it across so that within not too much time, Lindbergh and Duarte are back in sync with the mail back end and Bisoni. The information that's in this archive here is utilized by bug status, which also is part of the Debugs team. And that information you can see on the web pages that produces those nice graphs. And the other main consumer of that that matters to all of you is Brittany. So the testing propagation scripts utilize the information that is present in bug status to figure out whether a package propagates or not. So there's a file called testing-nr and a file called unstable-nr, which tell Brittany, okay, is this package more or less buggy? And so that's what's going on there. Obviously email interacts with the BTS and we also get a lot of information from DAC. So DAC tells us what packages are currently in the archive. It also tells us what's been uploaded. So this enables us to connect one package to another. So we can see that when you've uploaded version X prime that was based on X, we can see that connection and we can track that out forever as long as you keep uploading packages that are based on our previous package. This is what also enables us to say that a bug that was found in X that was not closed in X prime is still present in X prime. Yeah, exactly. This is a very lamentable state. It would be nice if they were automatically closed, but that's the way it is. So DAC is also important. So that's the state diagram. Inside of Debugs itself, it looks like this. Mail comes in, gets despanned. It's a process called processall. Mails that are set to submit a bug number or a bug number dash something go to the script called process. All the control and request mails go to service. Various bits of things happen. They get stored in db.h or db-h, which is the flat file system. This contains all the information there is to know about the state of bugs in Debian. The final bit are the indexes which were built out of db-h and then the CGI, which is part of the web front end. So everything there is to know about Debugs is right here. So with this, you all can now replace me and become prominent Debugs hackers, hopefully anyway. So it hasn't been a huge number of changes, but some of these are pretty major. This first one is just easy. It's just fun to show. You can now view CVs that have been linkified. This is the type of change that anybody here could do. This is a simple regex that looks for CVEs. You can test it using local Debugs yourself and you could have implemented it. So what this looks like, I was looking at beard shrinks, exciting. Well, let me click on it. Right, so this is the bug and you can see that now the CVE number is linkified. So that links to something on testing security, which will enable you to find out more about that bug. The major change that I've been working on and is status caching. So this tracks what has happened in the status of each of the bugs that are signed to Debian. So every couple hours it goes to the entire set of bugs and figures out which bugs are currently found, fixed or absent in unstable and testing. So that's not that exciting for you unless you maintain a package like Linux, which has the Linux kernel, which has a couple thousand bugs and your bug page takes forever to display. However, what this is really useful for is reverse status lookup. So this will enable me eventually to replace bts.termzimmer.net because this enables me to figure out which bugs are present or absent in unstable or testing without manually calculating it out the whole time. Finally, another thing that's involved here is force merge now does the right thing. So by this, I mean it figures out what changes it should be applying to the bug instead of naively just doing them itself and then invokes the appropriate control commands to do that for you. So this is also hooked up with the fact that once I deploy this change you'll be able to force merge binary packages which are different, sorry, force merge two bugs which are in different binary packages but are part of the same source package. So as often happens, your user assigns a bug to the wrong binary package or a binary package and you want to go to a different one. Also coupled up with this is a change to reassign where reassign will no longer clear found versions and fixed versions when you're reassigning to a package that belongs to the same set of source packages. So that'll also clear this up. Force merge will also issue the retitle commands, the summary commands, the effects commands, the block commands, the block by commands, everything that it needs to do to put the bug into the same state. And that's really useful because it enables to track what actually happened when you forcibly merged a bug. So that's pretty cool. Okay, yeah, so this is what status caching is all about. And yeah, eventually we're going to replace that functionality. So I'll talk about a couple more features that I've previously implemented but I think are neat and I don't think get used enough just to hit them again, effects. So if you have a bug in one package that causes a problem in another package, obviously the bug is in the first package, it's in package A. So it's not appropriate to have the bug assigned to package A and package B. But you don't want to get a hundred or a thousand reports of the same bug. So for example, if libc6 broke all the programs in the archive, clearly we don't want to have a billion bug reports filed in other packages. So we want to file it in libc6 and we want to have all the other packages affected. That's a kind of crazy case but you can see where this would happen in a slightly smaller library with a slightly smaller number of dependencies or reverse dependencies. So this is the documentation for that. This is how you would do it using the BTS command line utils and this is what it looks like. So this here is an example of a bug in Lilo that affects Lilo but is filed against Linux kernel. And it's actually been fixed already. Yes, you can just ask it, I'll repeat it. This is a feature which, okay, the question is am I discussing features which are upcoming or features which I'm looking for people to implement? Everything that I've talked about so far are features that exist or will exist very, very shortly. This already exists, you can do this today. This is a real bug and this is a real BTS. So if you were to type a search in for bugs that are in package Lilo with severity critical or serious, you'll see these two bugs and your page will look something very close to this. So you'd know not to file a bug against Lilo about it being unable to load the kernel. There's some question about whether this is really a bug in the kernel but whatever. That's another question. The other thing that's neat that I don't think anybody is using or hardly anybody is using is summary. So this is useful when you have long bug reports which have hundreds of messages sent to the log and you don't wanna go through and figure out what exactly has gone on for the whole log. So you send a new message to control or to the BTS and you indicate that you wanna make a summary out of it. And so this allows you to select a summary for bug one, two, three, four, five from message 30 in the BTS. And so it extracts the first non-control, non-sudo header, non-coded paragraph from the message that you nominate. It won't work for quoting that Manoj uses but if he gives me a regex that I can understand then yes I will make it also ignore his coding. Actually it may already but I don't remember. So this is what it looks like. Yes, if there's a mic that's fine. It's just not worth waiting too much. Does that summary command support something to where like I could write up a message and at the top put summary bang and have it when the BTS receives that particular message it would just make it the summary so I don't have to send a second command later. Yes, there's an option to do that. I think it's explained in the documentation I don't remember what the command is for right off the top of my head, huh? Is it minus one? Okay, yeah it should say in the documentation and it is a function that exists in the code. I just don't remember what it was and or even if I document it. So if it's not documented please file book because it does exist. So anyway this is what it would look like. So this is an example you can look at this bug yourself and you can see that the summary has been set from message number whatever this was. So that's pretty straightforward. The other thing and this is now actually sort of working or at least it will be as soon as the archive pulse happens again is local Debugs. So this allows you to run a full local copy of Debugs. You can select bugs that you're interested based on a configurable query. This is actually something that I need people to help me out with because this is not very well documented but by default it does the right things. So it selects all an archive bugs which are in packages you maintained, packages or bugs you've corresponded with, bugs you've submitted and bugs which are RC. So for most people that's all the bugs that you care about. If you haven't mailed it, submitted it or maintained the package that it's in and it's not RC you probably aren't too terribly interested but you could have this poll and mirror the whole BTS if you want it. Currently takes about two gigabytes for me. Most of which is indexes. Can grow or shrink a little bit. As part of the experimental Debugs package. So the EXP0 version of this works but not terribly well. The EXP1 version actually does the right thing and it should work just by installing it. If it doesn't, again, file bug. I tested it and it does but I don't work it everywhere. So literally all you have to do is aptitude install Debugs-local and then assuming you have debemail set which I assume you all do since you all use BTS command line, right? Everybody has debemail set, the environmental variable. Okay well if you have some other way of cluing in tools what your email address is I'll configure that properly. But anyway if you have that set all you have to do is run local Debugs mirror. It will take however long it takes to download all the files. Then local Debugs-demon and then now you can run local Debugs show to see a bug. You can search for example search Lulipond or you can also search for bugs with Verity Critical. These search strings right here are by default a package but they follow the exact same setup as the search strings that show up after your URL. This also needs better documentation as well. So if somebody could clarify that, that would be great. You can stop the demon as well by running local Debugs-deskstop. And it's exactly the same as a copy of the BTS running on your machine with just those bugs. So you can see exactly what's going on. There's some issues with it. It doesn't handle missing bugs particularly well. The mirror size is extremely large. It could also be faster to sync and as I've said it needs someone to help me write better documentation for it. So if you can write pod documentation you can write better documentation for it. If you can write text you can write better documentation for it because I can accept that. I'll format it correctly and put it in. Another thing that you've probably already seen are silly symbols. So let me go back just a bit. These silly symbols are these things that show up here. Almost all of them should have tooltips so you can hover over them and see what they are but just in case you hadn't seen the whole set this is the whole set of silly symbols. So you can see if it has fixed versions, blocks. So blocks means it blocks another bug from being fixed. Blocked means that it is blocked by another bug. So it's the pawn to the queen. Forwarded means it's been forwarded upstream, archived you know, it's recycled. Effects means it's biohazardous, won't fix, it's obviously unhappy and the rest of them are pretty clear. Most of these are actually already in use by the term Zimmer and the RC bug status pages. So those you should all know but the upper ones are kind of weird. Okay, yes. Oh okay, so the question is what was a missing bug in the context of local Debugs issue? So because you do not have a full and complete mirror there are some bugs that you're missing. So if you're trying to go get that bug all it does is it tells you it doesn't exist. It doesn't tell you why it doesn't exist. It doesn't offer to update your configuration so the next time you sync it gets downloaded. So all those things would be nice features but it doesn't do that currently. So that's why it's suboptimal. It should tell you that hey, this is a bug that I could have gotten. Do you want me to get it next time and do that? Okay, now on to the planned features. So all these things I haven't implemented yet but I'm planning on doing it and I'm in various stages of having them completed. The first and probably most requested option ever is control commands and submit. The reason why this has taken so long is because all of the control commands are run out of service or had been until just recently. I only now have one more command to get out of there which is clone. I hope to have it finished by now but it's not. Once I finish pulling out clone then you'll be able to do things like this. This isn't exactly how it's going to be formatted. I think this is just my current thinking. If somebody has a better idea for how it should work I'll let me know. But anyway, you'd say oh yeah, I'm submitting a bug to submit. It's in package blah and then I have a control set. So user is set to that. I want to user tag this bug. I think I'm going to use zero as the current bug that you're submitting but haven't totally decided on that yet. I want to also clone it for some ungodly reason and I want to reassign the clone of this new bug that I've submitted to blah. So all of that in theory can be done. You should be able to do any control command at submit time or also at bug number time when I've implemented this. At least that's the theory. The second thing I promise to implement and I haven't yet, then I will, I swear, is to, yeah, sorry, one more question. I can just repeat it if it's close enough, whatever works. So on that control command and submit does that mean that we would no longer have to like BCC or BCC control at? You would just be able to send, you know, like to the bug number at bugs.dev.org and include those control pseudo headers and then there's no need to do the BCC or CC. Exactly. That's the idea. The main thing and the main reason why it's useful for is submit time but it can be useful for other messages. If somebody has a better way to make it clear that you're actually doing control command and when to stop it, feel free to talk with me on IRC or later in the discussion period. We can think about that a little bit. The main problem here is I want to make it obvious that it actually is a control command so we don't send it to the control parser and cause problems when you didn't need it to be a control command. Okay, the next thing is this. So this is basically locking up on the fact that I need a rewrite process. So David Wendt is working on that a little bit. I'll hopefully be able to integrate those changes and get this to happen soon. So the main idea here is that we'll deprecate totally in and in dash submitter so that your submitter will now know everything that's going on with the bug. Eventually this has to be better so the submitter can opt out but I think everybody agrees that the submitter kind of wants to know what's going on with their bug in most cases. And it would of course be possible to proc mail it away or filter it out if they really didn't want to get it. And they can always change the submitter to somebody else if they don't really want to know about it. Yes. Yeah. So the question was you can change the submitter to any email address you want and the answer is yes but it does tell the old submitter that you've done so. Sorry what? Yeah, yes. Somebody has a lot of pills to sell. Okay. So the other thing that I have as a plan feature is user values. And the way this is going to be exciting will be seen a little bit later in one of the plan features but this will enable you to say, oh yes I have a field called priority and you can assign any value that you want to it. You can have a field called VCS commit and you can put in it the path to your Git web or whatever repository that indicates what commit happened when you closed that bug. Anything that helps you organize or prioritize your bugs can be put in there. And if it ends up that some of these values are really useful and there's a common usage then they probably should be promoted into the BTS proper but that's a change that I really want to make. So this is what I'm talking about. You can set a priority, you can set difficulty, all sorts of things that enable you to order your bugs and or provide more information. The final thing is changing the way that the short URLs work. Currently when you go to bugs.dev.org slash libc6 you actually go to the binary package libc6, this bud page, which only contains bugs which are assigned to that binary package. So the way bugs in Devian work you didn't already know is bugs can be assigned to a binary package or a source package. If they're assigned to a binary package they only show up on the binary packages bug page and also the source packages bug page. If they're assigned to a source package they only show up on the source packages bug page. This may or may not be a bug that maybe they should all show up but it's quite clear to me anyway that almost nobody cares about the per binary bug page. Anybody who's looking at the bug reports really wants to know the bugs that are in a particular source package. They could care less that the bug was assigned to libc6. They want to know if it's actually in eglibc. So that's what I'm going to change. I'm going to change the binary only package mapping to go to the source package. Now you'll still be able to view the binary only package name if that's something that you wanted to do but it'll be a slightly more difficult to get to by accident. So you'll have to know that that's what you were doing. So if you have a use case for that, that's fine. Ari has a question. Okay, so yeah, the question is, we'll be taking the mapping from stable. I actually have the mapping available for all time so I can do both. So I haven't totally figured out whether I'm going to use the mapping from a stable or just include all source packages that it was assigned to. I currently think using the mapping from a stable is the most sane thing but it would be possible to do both. So yeah, I haven't totally thought about that. Other things. Currently, merged bug reports do not merge bug history. So when you're viewing the bug log, it only shows the merged copy that you're looking at. I mean, so this needs to be fixed. I don't have a good idea yet how to do it because the code of doing this is kind of complicated but this is a problem. Another thing that needs to be done that's tied together with this is threading in the report. If somebody knows of a good ProLibrary that handles threading of mail messages that can also handle a different type of mailder-style backend that I can plug in code for, let me know. I kind of like the way Lurker looks but as far as I know, there's no little tiny library that does that sort of thing. So here's a mailder-like object, make it into a threaded view for me and then allow me to export what it's doing. The third thing is extremely necessary and that's user category duplication and replay. So currently the on-disk storage format for user categories is totally different, well, relatively different, from the format that you use to create a user category in email. So it's not trivially possible to generate the email from the on-disk storage format. So that means that you can't right now say, hey, give me the user categories for this user so I can edit them and then replay them back to the BTS and change them. So I wanna change that. Another thing is remote attachments. This will keep us from sending out 200 meg core dumps to all the mailing lists and all the mailing list subscribers if someone tries to do that. Unfortunately, as far as I know, very few MUAs actually support remote attachments. So a remote attachment allows you to use a URL or a URI to indicate that the attachment is not currently located into the message. You can use some other method of downloading the attachment that usually requires some sort of web access to pull it. So this means that instead of sending on the 200 megabyte core dump to every user on the mailing list, we just send them a link. Say, hey, if you're interested in this attachment, go to this webpage and download it. If there are MUAs that support it and somebody knows how to do that, I'd be interested in hearing from you. As far as I know, MUT doesn't because I couldn't, or at least it doesn't by default because IETF does this and it doesn't work for them. Another thing is tied also in with threading is the new spool storage format which will also speed up things for huge attachments and also back in indexing using PostgreSQL. So if you like PostgreSQL and you can help me with that, that would be awesome. And some other things that people have asked for, user tags visibility and smarter CGI options. What am I doing with regards to time? Awesome. Okay, so another thing that we need is better statistics. We need to track bug changes over time. We need to know when they were submitted, when they were closed, how much mail is going to them and we need this information on a per package, severity, maintainer, ed tag, maybe even basis. So we can see which packages need more love, which maintainers are MIA and all those sorts of things. So this would help us get a better eye on that. So if somebody is interested in this or has more ideas of things that they'd like to be able to measure using the BTS, I sort of need a list of feature requests before I can really strongly implement statistics. So I kind of have an idea of how to keep track of all the information that I would need to regenerate this, but it's not in a format that could be easily readable by anybody else. So that's something that needs to be worked on. Finally, or not finally, but another thing that would really help you all that we talked about last year in Spain is action required sorting. So even though a bug has a high severity and doesn't currently have a patch and may not be won't fix, doesn't mean that it's necessarily the next bug you wanna work on or a bug that you wanna see next or a bug that needs any action from you. So if you're a triager, you care about bugs that have no response, but you don't care about bugs that have active responses. So if a maintainer and the submitter are actively mailing each other, you could care less about that bug if you're a triager. Likewise, you don't care about, you care about bugs with ancient found versions because maybe they're already fixed, nobody noticed. But you don't care if there's multiple versions that they're found in. Same thing, if there's an incomplete report, you wanna complete it. If it's complete, it's up to the maintainer at that point. Same thing, the maintainer has some slightly different things. Some of the same things as a triager, but slightly different viewpoint. And a submitter has almost the inverse. They care about bugs that are tagged more info, but they don't really care about a bug that's been tagged more info which they've responded to, to which the maintainer has not responded. And they also care about when their bug is fixed and they're not as concerned about a bug that isn't fixed, presumably. Maybe they're a reverse if they're a developer or something. So this sort of sorting would enable us to look at bugs which have high priority and also have an action that's required. Again, minimize the time wasted, maximize productivity, or at least minimize the drudgery of looking through bug reports that you've seen and forgotten what the bug report was about. This is a little bit about, we're also interested in more of collaboration with upstreams and downstreams. So this is part of distributed bug tracking with Christine is going to talk more about, there is a BOF schedule later today about but Joey Hess is not going to be there and he's also interested in this and I myself am probably going to attend Joey Hess's talk. So don't show up in Shapiro because I don't think anybody's going to be there. However, this is the main point of distributed bug tracking from my perspective and I'm sure Christine will tell us more about different ways that other people are looking about it is to share the state of bugs between upstream, downstream, and sidestream. And by that I mean our fellow distributions who are also dealing with some of the same bugs. We also want to be able to share comments between all the bugs if we can. We want to be able to enable more distributed bug tracking. And by that I mean where you're able to look at the bugs that are affecting your package on your own machine, make local modifications, then when you get back, sync them back up to the cloud, also have them so all the hackers who are working together can then see which bugs people have been fixing can pull them down, SD does some of this and there's a bunch of other methods that are working on this. And another thing that I'm sort of interested in is distributed version and or commit tracking. So where you can track which revisions and stuff still have a bug present in it, which commits actually fixed a bug. So that you can see, oh yes, this bug was fixed and commits so and so therefore all things which have this patch set after it have also fixed the bug and things like that. So we have a lot of tasks that need contributors. These are some small things, relatively small, that people can do. So if you're looking for something that you can use to help me, you like the work I'm doing in Dead Bugs and you wanna help me out, thank you is great but fixing my bugs is better. So these are seven, well I started out with five and it just kept growing, things that are relatively easy to do, some of which required no Perl experience, some of them do require a little bit, but most of them are fairly self-contained units that you can work on and resolve yourself. And I'll almost certainly select almost any patch that fixes any of these. So the first is documentation of user categories. User categories are basically not documented. This needs to be fixed. I have said that I would fix it for four or five years, clearly I have not. So a couple people have mentioned that they were willing to start on this, so yes, please do so. Another thing that I'm probably not going to be able to do is implementation of RSS feeds for packages and bugs. If you wanna know what's changed in a bug report and point your RSS feed reader at it, then someone needs to implement this. It's relatively self-contained but it's not something that I can do. Well, it's something that I can do but it's not high priority for me. This CGI options on package report, there's a bug for it. This is basically making our CGI options slightly more sane. Yeah, Jolder has a question. Okay, so the question is, are the HTML hard-coded in the CGI scripts? And the answer is no. For the most part, they are not. There are some small edge cases where they're still located in there but for the most part we're using text template which happens to have embedded Perl in it but it's a pretty easy way of doing templating. Yes, it would probably would make it easier as another template, so yeah. I mean, the implementation details, if somebody is interested in doing this, I'm very willing to discuss and I can help you get a handhold on the code or any of that. Also documentation of multi-package reassign and when it or effects should be used, needs to be documented. This is just a straight philosophical question. So if you understand how bugs work, you can do this. This also a mail to link with the subject references and everything filled in would be really useful. So it would stop breaking threading and it would also make replying to a bug report more easy. And finally, documentation for local DebBugs including its configuration file which is totally not documented. In the few minutes I have remaining, I want to talk really quick about how you can get started on these tasks since I've said that you should. So the upstream branches of DebBugs are all located, we all use BZR of course and they're all located on bugs.dev.org. So it's bugs.dev.org slash debugs.source slash mainline. And mainline has the upstream DebBugs. This is what I'm releasing when I release packages in Debian. This Debian branch has what we're actually running on Debian. These are very, very similar. There's just a very small number of Debian specific patches that don't really belong anywhere else. Most of DebBugs is Debian specific but these things are even more ridiculously Debian specific such that I would never put them anywhere else. My branches. So if you want to see the exact code that I'm working on including uncommitted changes is here. So if you want to know what directions I've headed even if I haven't made a commit yet to the mainline you can see that there. The mailing list is debian-devbugs.dev.org. A lot of people are subscribed there. I think there's also a CVS auto post list which is just a pen dash CVS. And finally there's also the IRC channels. So there's pound-devbugs or debian-bugs on OFTC and I'm Don Del Carle there. The other thing that you need to know is how to set up a BTS mirror. This is a very short and quick version. You just need a script to R-sync it. All of the BTS is publicly available via R-sync so it's pretty easy to set up your own mirror if you know how to do it. You basically just need to get it and I have a little script that does it for me but you can write your own. It's all of 10 lines. And then to make this easier for people I'm gonna write a little setup config script that will get given a path to a vzr repository. We'll set up all the configuration and the couple sim links to the archive that need to be made for you. And it will exist suddenly but it's not there now. So with that I'd like to acknowledge all the people who are currently working on Debugs and all the people who have worked on Debugs in the past and I hope that you will join us all. And with that I'd like to entertain questions. Russ has a question. I have another thing that you could put on your for probably fairly easy task list. Somebody could sort out exactly what would be required to get Debugs and LAO mailing lists with subject prefixes to stop fighting with each other in such a way that the bug number replicates itself indefinitely on the subject line. Okay. Yeah, that's something that could be easily done. I saw in the effects slide that it said from other branch. Is that right? Yes. It shouldn't say something like affected but it's not affected by this or something like that. It's kind of confusing, isn't it? Okay, so I don't remember what the exact state of this bug is but I think it may be in a branch or the found tree doesn't connect anymore but I need to check out why this one happened to be in from other branch. I haven't looked at that yet. From other branch, literally there are three states that a bug can be in Debian that we talk about. It can be fixed, which is what we hope it is. It can be found or it can be absent. Absent means that the bug is in a state where we have no idea. It's below or outside of the version tree that starts at the found versions. So that's what absent means. So if it says absent, it shows up as from other branch and so that's why you see that there. Yes. So this category, so it's an affected bug question and so what's going on actually here is if it was a bug that was found in Linux, it would actually show up up here in this list. I don't know why this bug is currently from other branch. So normally it just, the only difference between an effects bug and a bug that's normally in the package is this bit right here as far as you're concerned when you're viewing this list. There's actually an option to turn it off if for some reason you didn't want to see affected bugs but by default they show up. What are we missing out on by rolling our own bug tracking software? Things like RT exists that CPAN uses and I just wonder what we're missing out with manpower wise with using something that a lot more people contribute to. Yeah so I mean the main issue that we are is just a pure manpower issue. However there are a lot of problems that Debugs solves that other bug trackers don't solve. For example, Debugs is designed to handle being a very wide bug tracker where we have a couple million bugs spread throughout 100,000 packages. It handles that problem with little issue. RT and some of those other bug trackers are designed for a more narrow problem where you have a few number of core packages with a lot of bugs in each of them. So it's a sort of a different problem domain between the two. The other thing is that a lot of other bug trackers do not track versions like Debugs does. So there's a whole integration with the Debian itself and our workflow that Debugs already does for us. So even though we don't have enough manpower that I would like, it would take a lot more to adapt any of the other tools that exist besides probably Launchpad to fit our needs. And I don't think very many people wanna run Launchpad and Debian. I know someone wanted that because it was on the GSOC ideas page. Ah, well it wasn't me. Yeah, another thing that someone could at least look at doing is updating the Debugs Debian package to something close to the current version. Yeah, so the current version now and experimental actually has. Yeah, so it's pretty close. I just, the only reason why I haven't put it in unstable is because I'm very concerned if anybody is actually using it that I will destroy whatever they were doing because it needs a little bit of manual care and feeding before I let it go into unstable. But if people could tell me that nobody is using Debugs, then that's fine. I can upload it to unstable with no concern whatsoever. The other people too who are using Debugs, so it's not just the case that only Debian is using it, Emacs is now using Debugs as well. So we actually do have some other people out there who are helping a little bit, although they haven't made very many changes so far that are terribly useful to us. But hopefully they'll commit some that will be useful. They've also created a couple new Emacs modes that deal with it, which is also nice if you haven't used Emacs. Emacs modes to deal with the code itself? No, so they're actually to deal with bug filing, some that deals with the pseudo headers and some other things that they found useful. So that also might be interesting to integrate better with Dev Scripts EL. I think it's the right name of that package. So I don't really know all the things that they've done. I sort of follow that from the very periphery because I only have enough time to dedicate to Debian. I can't be a maintainer for Emacs as well. Well, I don't even have enough time for Debian, so it would be even worse. Can you core Utils? Oh yeah, core Utils is just, sorry. It's the same, so the question was the, or the statement was that core Utils was using it as well. And yes, they are, and it's the same install. So, new core Utils is also using it. And GNU, the GNU project may use it on a couple more things. So as more hackers use it there, that'll actually be really helpful to us because they will be fixing more of the general issues and hopefully I can, I probably should go talk to some more of them and give them the same talk and get them excited about working on our bug tracker for us. If only I could get Evan Moglin to give my talk, that would be excellent. Okay, anything else? Uh-uh, so the question was, what's the issue with sideways coordination with other distributions? So the idea there is to know that if a bug has been fixed in, say, Fedora, that it happens to be the same bug that we have, that we can find that, ah yes, Fedora has seen this bug, they fixed it, or even more simple, Fedora has seen this bug and someone has created a reproducibility case for it. So you know that this bug is reproducible. They have a core dump that you can look at or something that enables you to actually get a handle on what the bug is. Having that all together and also having it in a way that upstream can see it as well would be ideal. So this is sort of more of a federation of bug tracker's issues. And so that's what I was talking about with sideways. So side stream collaborators. There was a question on IRC about, in the list of new upcoming features, you don't have anything about RDFA. So I guess that refers to an export on RDF of our bug tracking graph. Yeah, sorry. Yeah, so there was a question on IRC about that in your list of planned new features, yes. Yeah, there was nothing talking about RDFA, so I guess somebody has asked for a dump of the system on RDF or something like that. So yeah, so somebody was talking about interacting with the Helios project and providing more information about bug reports to projects like Helios. And I think that's a really interesting idea and I think it ties in well with the distributed bug tracking. What I'm basically waiting for is for the dust on that to settle because I don't know yet who the contributors are or who's going to be consuming that information and whether it's the right format to be shifting around. And just because I don't have a lot of time, I don't want to implement a feature that isn't going to be used by enough people. But of course, if somebody does implement it, I will of course accept patches because I know sort of what Helios is trying to do with it. Hi, I was wondering if there are discussions with other core teams of replacing, there are instances with debugs, visual packages, like security team or the VSA. Yeah, so there are a couple core teams who use Request Tracker internally. And the primary reason why they're using that is because it enables them to maintain privacy for specific things which should be and have their redistribution restricted. So as far as I'm concerned, any core team who has stuff that they're okay with being public the entire time, it's no problem to create a pseudo package. But honestly, whatever works best for the core teams is fine. So they have limited time. You're not planning to add a feature for embargoed or private bugs? No, because so embargoing a private bug would require such a huge change to everything and it would just be very, very difficult to do. So yeah, we have one minute left. Any more questions? Ah, so I was supposed to give away books. So let me do that while I'm thinking about this. I have to unplug you, sorry. So let me ask these questions. So who knows, so we have a couple different books here. The first one I have is Essential Linux Device Drivers. So this question will go to the first person who can guess within, let's say 10. No, let's make it five. So who can guess within five what the oldest open bug is? So what I'm gonna do is, I don't know how to do this best. So who wants to guess? We can just have a handle, yeah, sorry. Well, raise your hand first, so yeah. No. Yes. Okay, I'm now gonna start telling you whether it's higher or lower. 244, it's higher. Yes, yes. What? It's larger. It's larger. 870, it's lower. Who is first? Okay. It's higher. It's higher. It's lower. Oh dear, who is first? Fine. Awesome. So that is currently the open bug and since I'm giving the CU, it's your job to fix it. Find out what it is and fix it. I checked it actually is opened. It's not just unarchived. So, I don't know, that would be really nice though. Okay, so I have advanced programming in the Unix environment and this goes to whoever can correctly tell me why we're missing some of the oldest bug reports. No, it's not a fire. No. Bruce Perrin's dilly iddimal? Close, but not quite right. Exactly. We didn't use to archive them. We used to just remove them and there's actually an option still in the BTS that if you set it, it will remove the bugs instead of archiving them. So, good job. So, what's the pass it to Mark? Pass it back. Okay. And the final book I will give to somebody who promises that they're going to fix a bug requiring Perl in Debugs. Who is going to promise me the book is effective Perl programming. So, who wants this book and will also in exchange for it promise to fix at least one bug in Debugs? Jaller will. Awesome. So, it is yours. With that, thank you very much and I believe it's probably time for the next talk and or the video team to relax for a second.