 Next session will be H.A. Towns about debugs. So please welcome with me, Sir. Don't worry, this time I will make it right. It's a non-member of the non-existent non-cabal team. Whether to be a cabal, I'd be a hypothetical member. Okay, so these slides were prepared at about midnight last night, going on until about 1 or 2 a.m. So if there's any bugs in them that you see, then feel free to point them out. There isn't a pseudo package for the talk, no. Okay, so everyone here has used debugs, right? Hands up if you haven't used debugs. Wow. Okay. Also, hands up if you've read the debugs section in the proceedings. Okay, that's kind of background material that you'll need for the second half. So during the little break, if you don't have anything better to do, I'd suggest you read that. Okay, so debugs is the Debian bug tracking system, duh. It obviously has a web interface and it has an email interface. The web interface is obviously the main thing you use to actually read bugs most of the time. How many people just use the mail interface and not the web? So you get mail about your packages but never look it up on the web or never look anyone else's package or your bugs up on the web, you just use your email client. Anyone? Wow. Okay. So the web interface is pretty important for most people except for obviously one or two. And it has some particular requirements. So if the website goes down, then it becomes very, very difficult to actually do any Debian work because you can't look up bugs, there's very limited mirroring of the website these days. And formally it used to be a bunch of static pages. So that was kind of for reliability. Is Ian Jackson in the audience? Okay, so the static pages worked really well and were mirrored in a few places but that became a problem when it kind of was taking over 24 hours to regenerate the static pages. Beedal, if Ian Jackson tries to walk in, can you please block him? Okay, so Ian Jackson's obviously the original author of Deb Bugs and he hasn't been working on it for ages so if I say, yeah, if you want to sit outside, that would be great. Okay, so the website's kind of important, it has to be always available, it has to be fairly responsive and it has one of the things with, and there are various sort of things on presentation of the information so it's kind of useful to have the information actually presented in the order it came in rather than blog order. And yeah, okay, we've got an audience reaction shot of Beedal, smile for the camera. Okay, so what do people actually think of the CGI scripts and the web interface at the moment? Reasonable, really crap. Okay, if the answer's really crap, can I get a slightly more detailed response? Okay, for example the interlinking between the sites is somewhat limited so if you want to go from one site to the other, you have to go to various clicks or remember the link or something like that but I guess the information is there so that's not a problem but I guess the interface to find the site or to go from site to one site to another that's pretty much limited, I think. Do you want to pass the bug from behind you too? Okay, so I kind of want to relate this. I love that bug, I really do, I think it's the best bug tracking system, I like working with it so one of the issues, the only issues that I have with the web interface is that the information gets presented in order as you said but it has all the control information, all the headers, directly available to everyone and it's not threaded so when there's these bugs that just keep on going for months it's basically impossible to find information or find a trail of discussion within so that's my main beef. Okay, we'll just take a couple more of the website complaints. PackageInfo.CGI takes too long to run. PackageReport.CGI or PackageIndex? PackageReport.CGI, it takes about 10 CPU seconds and certain users that basically do a denial of service attack on the web on a spore. So you're complaining how long PackageReport.CGI takes as the X maintainer walks in, that's very good timing. He knows where I'm going. Okay, so I'll actually respond to the timing thing. There are index files that are meant to speed it up but they haven't been generated since we moved to spore and no one noticed for about a year, so. Okay, and so there's obviously also the email interface. The email interface is the control interface. The website is just for actually kind of read only. The email interface has to be very easy to use. It has to be if you're trying to set up a Debian system and it's not working and the only thing you've got is a crappy Windows box that's just got tellnet that you can tellnet to an SMTP port, you still need to be able to file bugs. The actual changes you make via email need to be reflected on the website fairly quickly these days. In the past, that used to take basically 24 hours to be reflected on the website. That wasn't really acceptable then and it's certainly not acceptable now. And the email interface also needs to provide a fair bit of information on kind of what was changed because there's no authentication in Debugs so the only way you can correct screw-ups is by basically seeing, yeah, this is Brandon's big kind of issue with Debugs. He likes, he likes item privacy. I was just making sure that Anthony knew that I filed a bug with a patch that as far as I can tell from reading the code does actually have the control bot report all previous state information when you are changing things via the control interface. Because, you know, Anthony was kindly pointing out bugs that have gone unfixed for a long time in one of his previous docs. There are many bugs in Debugs that have gone unfixed for a long time in one of his previous docs. There are many bugs in Debugs that have gone unfixed for quite a while. One of them will be fixed during this talk. Actually, two of them, my mistake. One by me, one by Joey, but kind of put on Debugs by me. And technically it was before this talk. I wasn't quite that game. And yeah, the issue with Debugs is it isn't kind of technically maintained at the moment and hasn't been for a while. So I joined when I packed up some CGIS scripts and kind of they got put on the website before they were rewritten to be secure and haven't kind of been rewritten to be secure, but they seem okay. It's great. Colin kind of got roped in when he was kind of a newbie developer and was all excited about suddenly joining this really great project of Debian and important and gosh, how will I cope? How will I cope? And now he's a release manager, the sucker. And yeah, we kind of don't have anyone kind of leading the charge of Debugs improvement at the moment. So bugs kind of linger unless they're really breaking stuff and kind of stopping development. So there are a few things like that. And if people start feeling really excited about this and kind of getting some momentum for Debugs development, that could be really good. So one of the things that I don't think I've put a slide up is that Debugs is really good for Debian and really crap for just about everything else. So it's very hooked into the package, into the package orientation that Debian uses. A lot of places can't really use a package breakup. So Gnome and KDE were trying Debugs for a while and there were other problems as well with it, but just splitting on package isn't really enough for many things. But it does work really well for Debian because we have, for most packages, a reasonable number of bugs per package. And amongst all our bugs, they're divided relatively equally between packages. And obviously we have, is everyone familiar with all those different ways of sorting bugs? So by submitter, by source package, by maintainer, and in theory also by severity and tag. You are now. That's really great. I'm sorry, why only in theory? That does seem to actually work, I think. It does work, but there are lots of bugs with any particular tag. So it'll work fine for DI, I guess. It won't work so fine for all the bugs with patches in the Debian bug tracking system because there are just too many. And likewise for severity, there are just too many for it to actually be usable. And one of the key things is that finding, like collating interesting bug reports is really kind of a hard and, it's kind of the key problem in the bug tracking system world. And so if you come up with good ideas for that, that's kind of one of the better ways that you can contribute to Debugs, even if it's just this is a really, this is a possible way of doing things that would be really useful. One of the similar sorts of things is like being able to prioritize bugs in a package. So sure you've got these ones are serious, these ones are wishless, these ones are important, whatever. But maybe some of the wishless ones are a priority for the package. But there's no real way to reflect that in Debugs. That's something I've been thinking about for a while, but haven't really come up with a good way of dealing with it. I'll get on to a kind of hack that might sort of work, but a little bit later. Okay, so one of the other things about the bug tracking system is that it's entirely public. So that's kind of defined in the social contract, in the we will not hide problem section, which kind of talks exclusively about the bug tracking system and says issue reports to go to the bug tracking system, they'll be up on the web page and they'll be public to everyone and it'll all be great. That's kind of meant that we don't really track security issues, certainly not in the bug tracking system and apart from Joey's work, kind of not at all. And it's questionable whether that's the greatest thing but it's a lot easier not to implement stuff. So if the social contract suggests that we shouldn't implement it, then that's just really easy, yep. My question is, isn't that true only for security issues that are embargoed? Because there have been plenty of ones that just got sprung on us like with X for 86. That we do track via the BTS. Yes, so there are obviously two sorts of security issues, the embargoed ones that go via the private lists and get fixed and then announced and uploaded all at the same time. And then there are the general ones that are just bug reports that are public disclosure right from the word go, put straight in the bug tracking system and fix that way. And there's obviously the security tag to kind of track those. One of the things that means though is that if you've got some security bugs that are tracked and a bunch that aren't, then you can't kind of do statistics on them. You can't do the release critical bug report. You can't say, I'll look at all these bugs. Sure, some of them we couldn't disclose a while ago but now we can and we can show that it was fixed in a timely fashion or it wasn't fixed in a timely fashion and there's a problem here or whatever else. And there are obviously other follow-ons like that from that. So should email addresses be made public? A lot of people who file bugs to help Debian don't really want their address made public so that they can be spammed forever. And obviously the header stuff, sometimes some of that's private. And the other question is should the bug tracking system be Googleable? At the moment it isn't because the IGI scripts were DoSing master a while ago and obviously be really good and really good for people's Google juice if the bug tracking system was Googleable. So there are kind of some balances there too. Any questions so far? You want to wait for the microphone? I do quite a bit of installation report processing and it would be really great if you could search within only installation reports for certain issues like with serial data or whatever. So you don't really want to search over the whole BTS sometimes but only within a certain subsection. Do you mean a full tech search? Yeah, probably. Yeah, full tech search is kind of difficult because Debugs isn't set up so that you can full tech search very easily and it hasn't been implemented. But after you've heard this talk obviously you'll be able to implement it and it will all be great. So the bug tracking system has to be responsive and reliable. It can't go down because that kind of screws up everything about Debian development and it has to be responsive otherwise you get the DI cron daily sort of problem where you're trying to do stuff then you're waiting for stuff to load and update and then you do some more stuff and you're trying to communicate with people but Debugs isn't being responsive so isn't sending them mail and then they have to go to sleep because they're on a different cycle to you and whatever else. So it has to always be available it has to be responsive and that means that changes to it need to be made very carefully. You can set up obviously back up Debugs thing with your own bugs that you test yourself but when you roll out changes to Master then there are various different settings for that and you just need to make sure that they work. One of the really fortunate things is that the email interface for changes leads people to expect some lag because the mail queue isn't run immediately so there are general mail delays from maybe your ISP as well so if you don't get an immediate response people kind of accept that. So how many people notice the bug tracking system was down for a couple of hours yesterday? There you go, three people out of all of you. So the bug tracking system was down for a few hours yesterday because I was putting some of the new features in the second half of the talk in and the web interface keeps working so you can kind of do development bugs just get spooled so as soon as it gets re-enabled again a couple of hours later because I forgot to re-enable it then they all just get spooled and everything goes out and it actually works really amazingly well. Actually making the web interface allow changes would make that very difficult. It would like lead to the expectation that you just click, you get an immediate response because that's what the web's about. And yeah, that's one benefit of the email interface. I mean, a contrary thing is that with an email interface if you start replying to bots that also start replying back for loops, those are awesome. And even if you have the precedence junk and all the other crap that tries to avoid loops like that, it doesn't always work. One of the other cool things about Debugs is there's a 15 minute delay between actually receiving the email and responding to it, which kind of makes the loop not actually denial of service the box. Yep. One problem in the current thing is sometimes six of spam cause five hour delays in processing. When we get a 50,000 Yeah, so spam is a real problem for Debugs. I mean, not only just publishing addresses but having 300,000 email addresses that have been published around the web, fairly well known, fairly easily guessable, like six characters long leads to getting a lot of spam. We've got cross-assassin. We've got spam-assassin. We've got about 400 gigabytes of save spam over the last year. And yeah, it's a real problem. Like it does, it is probably the biggest load that the bug tracking system puts on its host these days. And it kind of works but yeah, spam's horrible. But the problem with that is we can't really fix spam because we want it to be very easy to mail. We want it to not require authentication. We don't want to have to subscribe to bugs. We don't want to make it difficult to communicate and say, yeah, there's a pretty difficult trade-off there. I'm not sure I should advertise this, but does everyone know that you can kind of mail owner at bugs and get spam removed from bug reports relatively easily? You can. I don't do any of that because it's boring. So the other thing about Deb, sorry? I wanted to raise another point and if I slept for a couple seconds you actually said that, then please slap me. But one of the great things about the email interface for me, and I'm sure it applies to others, is that I'm traveling a lot and I do Debian development and I can just file bugs right in the train without any connection and with bugzilla that's just impossible. And yes, we had at the Ubuntu Down Under meeting Colin and I talked to the Malone Launch Pad guys and tried to convince them to do a good email interface too. In theory they will, but it will require GPG apparently. Okay, so the other thing about DebBugs is it's very big. It deals with a lot of data. So 300,000 bugs, 50,000 or 60,000 at the moment that are active and can be modified and played with. Thousands of messages a day, hundreds of release critical bugs, whatever else. And obviously lots of queries while people actually look at those bugs. So I mean obviously there were issues in the past where the static generation of the bug pages was taking way too long. It was just not updating before the next update needed to start. And there are similar things, so I'll get onto this in a minute, but the structure of the DebBugs database is basically a file system. So there are four files per bug and how many people have dealt with like 200,000 files in a single directory? It's not fun. And so we've had to do some hashing of that and obviously the archive bugs, 300,000 bugs by four files each, not pretty. And so I mean there are scalability issues with that. So you've got to have some sort of indexes that actually make it reasonably efficient to search. You've got to have the bug tracking system be responsive again. And so there are issues with that too. I don't want to start a religious worry about what's the file system. I think it's just X3 now. It became much better with the 2.4 I think de-entry caching. The improvements to the VFS in 2.4 suddenly became much better and it was wonderful. But yeah, we do hashing so it's reasonably decent now anyway. Okay. So it's a file system based on the databases in the file system. So there are just files per bug. There's a couple of index sort of files and that's about it. And that means it doesn't require any complicated kind of databases stuff. There's no SQL in it which is not bad. And the databases basically split into two sections which is the active bugs and the archive bugs. The difference between them is the archive bugs can't be touched at all. So if you mail them, it'll just say no such address. If you try and control them to reopen them, it'll also say no such thing. The de-bugs admins can basically reactivate a bug but you're better off just filing a new one. And obviously all the bugs are available via the web interface. Okay. So the hashing of the bugs is just by the last two digits. So the directory structures orgs, bugs.demon.ogs, bool, db-h, 00301500 .log, .status, .summary, and .report. And they're all text files. So they're rsyncable, they're like readable, they're editable in VI, they're like relatively understandable. Who here's looked at the log file format? Congratulations for still living. Okay. So how many people have looked at the status file? And how many people of those haven't looked at the summary file? Very good. Summary file is the new way of recording the basic kind of status information about a bug. So there's an example there obviously. So there's the topic of the bug, there's the package it's assigned to, there's the message ID that opened it, severity, the date it was filed, basically that sort of thing. And it's now in d-package format. It used to be in this 10-line format that had each line number being some particular thing and it was horrible. There was an unused keywords line, that's where tags came in. Apart from that, you couldn't add any features at all that required any sort of summary, any sort of status information changes. Colin Watson has very creatively implemented a nice RFC 822 format, which is obviously everything else in Debian, and that's the way we're going now. Okay. This is the log file format. Do you like the control characters? Do you like the hard-coded HTML? That's why DebBugs isn't translated. Those hard-coded HTML things differ between really old bugs and current bugs because the code in DebBugs changed to have nicer HTML output. So the control codes in there, the control f, control c, control b, the control d in the middle of the line basically implement a state machine. The control d is like a kind of hard-coded comma to separate different email addresses. The other ones just tell you what sort of text follows. There's kind of a summary of this in the proceedings notes, but you kind of have to use the code to try and understand it. It's really quite horrible. It really should change at some point. Okay. There are the two other files that make up the four files per bug are the status in the report. The status is out of date. It's not really hopefully used anymore. It just contains redundant information from the summary file now. And there's also the report file. It basically just has to be used and it's just basically used so that the original email can be included in the done message. Okay. We've also got for the CGI script some index files because you don't want to basically be opening 50,000 status files or 300,000 status files to see which bugs are relevant for just one particular package that might only have two bugs open anyway. Yeah. This was never actually meant to go on my quick hack to kind of make things work. Debian is really good at making quick hacks kind of stick around for years. So, yeah, basically that's the format. It's just a text file. It's one line per bug. It's got the package. It's got the bug number. You'll notice how Ian Jackson's bugs never get fixed. Those are bugs filed by Ian Jackson, not in packages he maintains. Well, some of them might be packages he maintains or maintained, I don't know. It's got the date that the bug was filed. It's got the status whether it was open, forward, or closed. It's got the submitter. It's got the severity and it's got the tags. That's kind of cludgy to parse because the brackets could have spaces or more brackets inside them or whatever else, but it works well enough. Now, obviously, that's like a fairly long file. I think it's about so for the active bugs and probably about three megabytes for the archive bugs. And in theory, that ought to be really crap to try and parse, but apparently our hardware is fast enough now that for most things, obviously for some things you do notice it, but for most things you don't. There was meant to be a DB format index where you could just constant time say, give me all the bugs for this package, give me all the bugs for this severity, and give me all the bugs for these tags. That didn't actually make it when we moved the bug tracking system across to Spore because kind of they were being generated by a script in my home directory. And, yeah, so all the supports in the CGI scripts to read from them, but they're just not being generated anymore. They probably should be because there are obviously a much easier way to parse things. There are two uses for this. One's for the CGI scripts to just grep through, look for the TWM package and just grab each of the bug numbers. And then you can open the summary files for each of those and get all the real information you want. The other use is for kind of just general hacking on it. It's a very convenient kind of summary of most of the information you might want to grep through, so if you want to see what's the average number of bugs per package, you can just grep through, run it through sort, unique, some walk or whatever else, and work it out. Has anyone here not logged on to Merkle? Who's a developer? Okay, Merkle's a really great little thing because it has mirrors of the stuff that you can't actually SSH to and log into because they're restricted machines. So, there's a mirror of most of the bugs.debin.org on that machine. Obviously, except for the 200 gigabytes of saved spam. I should note that the 200 gigabytes includes both gzipped and uncompressed copies of all the spam. Excellent. So, yeah, if you want to just do some kind of statistical or if you want to hack up some stuff for the debug stuff, going on to Merkle, having a look through the index.db files is a useful sort of thing to do. Okay, any questions so far? Sweet. Okay. Who's here? One thing I thought would be a useful thing to have in the bug tracking system and I might even try and work on it sometimes soon is RSS feeds for each bug. But how hard would that be to add into the current framework? Because I think we can already generate like an inbox for each bug. So, would it be fairly easy to just have, you know, a simple XML based file generated for each bug? Okay, so the way that the bug report stuff is generated is with bugreport.cgi which you see in all your URLs probably. It basically scans through the log file and then dumps some HTML for it. A lot of the HTML in that is hard coded so it would be fairly simple either making a new RSS bug RSS report or something CGI script or actually parameterizing the HTML the HTML or RSS HTML output. So, if you just change bug report make a new CGI script and have it work it should be fairly easy if you want to actually make it just an option like and RSS equals yes or something like that. Relatively easy but you have to do the parameterization work which is useful to do anyway. There have been other sort of proposals for nicer CSS for the bug pages which haven't been implemented because basically it's not parameterized so that would be a useful thing and it wouldn't be very difficult. It would basically be hacking on one Perl script. Okay, so one of the who here knows of bug scan? Okay, you have to have kind of poked around a bit to have found bug scan it's the thing that generates the release of the bug report page. It also used to be the thing in my home directory that created the old has anyone here not seen the old bug graph or the non-wish list bug graph that kind of stopped being updated a year ago. So, it's the thing that generates those sort of statistics. They're separate scripts, they just kind of pass through all the summary or status files and make up statistics pipe it through the new plot files. And that's kind of a really useful sort of framework for kind of hacking on stuff. It doesn't actually involve any special permissions. You just go through the spool on Merkle. You only need to read stuff. You just go through every summary file. You pass it appropriately and then you do stuff with the information you get. So, yeah, if you want a kind of gentle introduction then that's another good way of doing it. And obviously the release critical bug page is really useful. The graphs are kind of interesting. So it's something you can do useful stuff with. I'm not sure if the bug scan code is for the release critical stuff is available on Merkle. A year later he took another page that is exactly the same because he had... Okay, yeah. The basic problem with bug scan is that if you... that's it. Developed, yeah, not very openly. So it was just a hack, I guess, at the beginning and so when I hacked some little bit on it to improve it then it was basically to get Colin to apply the patch and to problem over ISE. That's a very common thing to do with him. But the problem is there is no CIFI... no VCS or something for that. I think that's basically the cause for the alternative ISE bug list by Andreas Bart. So perhaps we could approve that and merge the two pages together again. Yeah, so bug scan up until a little while ago now was running once in Wicked's directory and once in my directory kind of some historically shared code but that's about it. Wicked's after the release critical bug page was down for a while, got merged into the bug tracking system proper by not being in the CVS or anything like that at all. And yeah, it's kind of a hack. So if you feel like you want to kind of take over something without asking permission or anything, that would be a good thing to do and would not actually cause as many flameless as you might hope. And yeah, I mean actually doing statistics on the bug tracking system is kind of something that is really lacking in the Debian bug tracking system sort of environment. Okay. Who here was at Oslo 2003? Do you remember the bug scoshing claim stuff? Yeah, so the claim stuff was a thing I hacked up for the Oslo stuff so that we could kind of track which RC bugs everyone was working on. So that like we could coordinate it and didn't need to worry about changing the topic on an IRC channel or whatever else. And the idea behind that was that you don't want to always have to change bugs.debian.org itself to add new tags. So if a few people want to get together and kind of coordinate, these bugs are interesting for this reason. These bugs are interesting for that reason, but they're only interesting to us. They're not interesting to the world at large. And we don't want to bother people. We don't want to generate bugs to lead or less spam and actually notice our message or wait a year for a patch to be accepted or whatever else. And so the idea behind that is kind of if you just make package report.cgi accept a list of bugs that are interesting, then that list of bugs can be generated by some other script that looks at, I don't know, some sort of PHP inputty thing or whatever else. That didn't really build up to my satisfaction and basically just ended up being some scripts on master that developers could log into master, edit some file that they owned in some kind of slash temp sort of directory. And then they could do a query on the claims.cgi thing to see which bugs are being claimed by which developer. And that worked fairly well. So the list of bugs is just a post, HTTP post. And it's all kind of automated through the claims.cgi. And so it didn't really get used much beyond Oslo because the editing files that are owned by other people on master doesn't work very well. And so if you want to use the interface you have to use package report.aj.cgi which probably no longer works anyway. And it's kind of in theory a good way of doing things but there wasn't any take up so maybe that means it was actually a crap idea or it needs to be modified some more or maybe someone just needs to work on the actual original interface which isn't something I really am very interested in. Okay. In theory though actually being able to say have a small group of people maybe in the same area or maybe just in a sub project say that these bugs are interesting for this reason is one of the things I've been able to say that these are the interesting bugs. I don't want to have to scroll through the entire bug list for X just to find out which ones are about the hardware support for this particular computer that I'm interested in. And getting that sort of information out of the bugs, cabal, control, whatever like that is kind of very helpful for everyone because you can do it much faster and we don't have any more work. So that's obviously a thing that can be very helpful and yeah timing is great. So missing features. This is where we can have some more complaints if you like. One of the obvious things is that the integration with upstream and downstream bug tracking systems is kind of pretty weak. There's the forwarded address which you can send to an email or set to a web page that's about it. You can't get kind of automatic notification or kind of automatic integration if it's fixed upstream. You can't really do anything very special with stuff that's downstream. Probably you should. There's obviously a lot of spam prevention features that are missing. Kind of hiding email addresses from random spiders that are crawling over the web. There's the actual avoiding getting spam in the bug logs that just sit there for years and years. That's kind of a difficult problem. We don't really have any good solutions. We're just kind of throwing CPU power and spam assassin at it and hoping. You can always basically have finer grain selection and control of bugs. So one of the features that I think got implemented was the owner stuff. Yes. So one of the features that some of the HP guys filed a patch for a little while ago was being able to assign a bug to an owner. So rather than just the package having to deal with all the bugs, you could set the owner of a particular bug to someone who'd take responsibility for it. Then I believe you can do queries on it and stuff as well. There are always better things you can do with that. So just limiting bugs, selecting by tags, selecting by subject header, stuff like that. There's always more improvements there. Secrecy and authentication. Debugs has none of that. Obviously there are lots of things to be added if we wanted to. Adding secrecy kind of a bad thing like having all the bugs be public all the time is really helpful. It avoids you kind of saying, oh, this is kind of embarrassing. I don't want to talk about this. Oh, what can I do? What can I do? You just file it in the bug tracking system. You know about it. If you're embarrassed, too bad. Fix it quicker. Authentication stuff. We don't authenticate anything at all basically if someone was going to try and screw us up by closing every single open bug they could do that. I find it really kind of surprising that we haven't had any attacks like that except from people trying to be helpful. He actually fixes bugs. I don't have a problem with that. So the question is what about Lamont? I think that's a very valid question. I'm not sure it's necessarily particularly valid in response to bugs. I was just referring to the incident of him carving his name into the bug graph. Yes. That was probably the release critical bug graph, which wasn't 10,000 but probably only a couple of hundred. Yeah, everyone knows the rule that if you're going to file like a bunch of bugs on a similar topic you kind of talk to people on Devel or at least on IRC or something first. Everyone knows that, right? In their heart. Like in their soul. It's kind of engraved into their forehead and you look in a mirror before doing anything with a bug tracking system, I hope. Yeah. So one of the things with that is that often instead of filing a hundred bugs, you can just kind of collate them and file them in one particular package or you can write a Lintian or Linda check, which I'm sure you'll hear about later today. And if you don't have, if you just can fix one bug that's a lot better than having to deal with a hundred bugs. So that's kind of the attitude there with that. Okay, anyone want to add to this slide? Yep. Wait for the microphone. Yeah, a couple quick things. One would be something better than CVS so that we can have easier contribution of patches because right now I personally have probably close to 300 lines of patches both modularizing a bunch of things. And in order to get those sorts of patches into the BTS it's almost impossible when dealing with CVS. I mean, Subversion is a step better. Maybe Arc, Baz, Darks, whatever, but something better so that somebody who doesn't have commit access isn't a second class citizen. What was else I was going to ask about? Oh, so that would be something that would be really helpful. Oh, and the other thing? I'll just reply to that. So one of the things with that is that Debugs really kind of isn't maintained at the moment. So people are just kind of committing to stuff as necessary rather than kind of taking a leadership sort of thing and saying okay, the way to go forward is to use a decent revision control system like Darks. And so I mean, obviously I'm not doing that because obviously I just use Darks and ignore what everyone else in the team wanted. And I don't think that would be very nice. I've used Darks for the modifications here in the second half. Yeah, next point. And the second thing was to start to modularize the BTS because right now I don't know how many people have actually looked at the Pearl Code, but some of the CGI scripts and stuff, the stuff that actually reads the logs is duplicated in multiple different places and not particularly well modularized. So I mean, anytime that we have a Pearl script that's got more than a thousand lines, it's an indication that it's not written ideally. So I mean, if more people could help to modularize, I think Dugi started on some of it. There's already stuff to read the log. One of the patches that I've got actually uses this modularization to do that. And if you wanted to see what it looks like the the message that I responded to James Troop has those patches on it. So bugs.darmstrong.com has those. If you wanted to check that out. Yeah, but BDAL can just dive out and tackle him. Okay. So one issue that I really would like to see in Debugs, that's the ability to subscribe to single bugs to establish some sort of Okay. And I had another one and I just forgot it. Has distributed revision control stuff has made it easier to work on source code while you're disconnected from the net. I find myself increasingly becoming annoyed at sort of the current state of tools for trying to maintain a local copy of the BTS content that's interesting to me when I'm off the net. I get lots of airplane time that it would be more productive if there were some easier way to sort of maintain a local copy of the state of everything that I care about in the BTS. And it's of course defining the everything I care about part that makes the current tools interesting. So the ways that you can maintain a local copy of bugs that you're interested in at the moment is basically by downloading the particular bugs in Mbox format. That's kind of pretty awkward. The implementation now at least doesn't completely suck, but there are also questions of like it would be really good to have kind of public mirrors of the bug tracking system so if the internet stops working you can just use a different URL and still get to the bug tracking system. As I said that used to work when we had lots of static pages. It doesn't work so well now that we've got CGI's of everything. Yeah, that would be really good to do. It's the kind of thing that you can actually kind of implement yourself by just rocking through Merkel to look at the bugs and make an async sort of thing available or do something else. One aspect of what are the interesting bugs for myself would be can I have a list of all the bugs a special package depends from. So for instance I'm asking for this meta package approach. I would like to know what are the bugs of all the dependency of this package and can I have a list of them? So one of the things that DebBugs tries to do is keep itself relatively limited. I'll get on to that a little bit when we talk about the individual bugs descriptions if we've got time later. And one of the things that DebBugs doesn't have access to is all the packages information. So it doesn't actually have the information on the dependencies. What you could do instead is have these are the packages I'm interested in. The fact that I'm interested in them because they're dependencies of one that I happen to be particularly interested in and maintaining. DebBugs doesn't need to know that. You can I think actually do that at the moment just by saying packages package equals x, y, z, whatever. But yeah, there's lots of things that you can kind of hack on and do that aren't really documented or very easy to support, easy to realize that you can do it all. So it's currently a documentation problem and we... Oh, there are lots of documentation problems in DebBugs because I've worked on it. Okay, thank you. There's a question up there. Something that might be a bit of a feature for the future. I'd like to attach some sort of regression tests to bugs so I can one could automatically test where a certain bug has reappeared. That would be a nice addition but for the future I think. So again, one of the things with DebBugs is it doesn't kind of it tries to just keep itself limited to tracking stuff. So actually doing the regression test is probably out of its scope. But on the other hand, having the bug tracking system store the regression test so you can do a bug report query I want the regression test for this particular bug and then I'll unpack the source and actually do it. That would be in scope. There are similar sorts of things so that at least one of the things that I've been thinking about implementing for a while but haven't gotten around to because I haven't actually paid much attention since the summary format has actually stabilized is tracking a bug that's kind of been filed automatically. So one of the things that you really ought to be able to do is file a bug based on the Lintian report and then rather than parsing email responses and stuff you ought to just be able to say I filed a bug against this package based on this Lintian report, tell me the number and show me the bug report and give me the status of it. And that sort of thing might work okay for the I want all the regression, all the things that have I don't know, I want all the bugs of this particular type and then I want all the regression tests and then I'm going to test them all. So I mean this stuff like that that's just not implemented and would be quite feasible. If I may just say a quick word about Simon's proposal what he's getting at is test driven development where if you find a bug you write a test case that reproduces the bug and then you fix it and then you have the test case forever. Now I think that is not something that the bug tracking system has to do at all. I think that's something that we should possibly start to do as a policy thing in the packages. I work on this open-plone developer team and we're starting to do that there and it proves to be really it's the only way to scale and I think that's not a bug tracking thing but I think it's something we might want to look into. The way in which it can be a bug tracking system thing is if the regression test doesn't actually come after you fix the bug if it comes from before this is how you duplicate the bug and it can be useful in that sense because there's no updated package to put it in yet. But yeah, how many people have regression tests in their package that get run every time it's built? In future everyone should be putting their hand up to that question. Actually this will be the last question so let's run off the back of that somewhere. I have a feature request and an anti-feature request back on the fake tags part I've been using that to track all bugs associated with the LSB which is pretty cool because generally the bugs need to be against the existing package but you want another way of looking at them so I like that and don't want to see that go away although right now it's kind of cumbersome because it was set up explicitly for the LSB stuff and it would be nice to be able to arbitrarily create, you know, be able to log into a common developer machine and arbitrarily create categories for tracking bugs. I think right now I have to explicitly log into Spore which isn't generally available so maybe that mechanism needs to be moved to Merkle or something like that so I like that feature and it's been pretty nice. Yeah, well you should talk to me about that so that I feel all inspired to actually make it more general. Okay, my anti-feature request is something you brought up earlier and that is there are some people who are complaining about the Web interface. I actually like the Web interface and one thing that I don't want to see happen is that I don't like Bugzilla. I think the barrier entry is too high. Every time I'm forced to use Bugzilla I have to go in there and you have to import, you know, input all sorts of information before you get useful content back out so, you know, anything that is added to the Web interface I want to see it be something that's on the side and optional so that you can use it if you want but you're not forced to use it like you are with Bugzilla. Yeah, no, I agree with that. So at least as far as I'm concerned, definitely. Quick. One thing I've sort of wanted a lot of times is structured queries. Things like it was opened less than a month ago. It's severed this and, you know, multiple things. We'll get to the month ago one in a minute. Yeah. Well, what at one point provided that feature was the LDAP backend. Any news on that? No. I try to avoid the LDAP stuff. Very successfully I might add. Okay, so that's break time. I would recommend that you at least skim through the stuff in the proceedings if you've got it handy. If you've got internet stuff that's on my blog at least, I don't know where else it might be. And we'll resume in about 10 minutes.