 Cool Well, we're just about at five if anybody I'll give a couple seconds for everybody else to show up if anybody's showing up But the codes and slides for the talk are there You have all of the code and everything that I'm going to show you So if there's something that interests you that you can't copy Fast enough as we go by you can just get it there So let's get started. So my goals For this talk are pretty simple first I want to show you some bug statistics since I have access to the entirety of the BTS and theory I should know what's going on so I'll try to give you an idea of how the bugs are growing whether our filing rate is going up or down whether our Fixing rate is going up or down And then I'll talk a little bit about some of the new features that I want to highlight that have happened since the last time I gave a talk Then the most important thing for me is I'm going to tell you all how you can help me and hopefully Show you a start to some of the places that you can can work and how you can get a Tiny version of the BTS up and running so you can patch the code base yourself and contribute and then I'll Try to answer questions and have a discussion with any remaining time So let's start a little bit with some introduction The BTS is Major goal is to enable people to report features or bugs to track the evolution of those bugs Hopefully to enable maintainers to fix bugs And ideally over time to reduce the impacts of bugs in Debian Both so we can do release but also so that any issues that users run into are mitigated During you know their time using Debian The BTS is one of the first things that a lot of contributors actually interact with the development part of the of the project Yeah, they might have installed Debian But as soon as they have an issue then they're going to figure out how to communicate with the project And so one of the things that's kind of important for the BTS is eventually to keep Trying to be relevant for new contributors to make it easier for new contributors to contribute to the BTS So I'm trying to keep that in mind as we go along as well in addition to enabling all the developers to do all the work That everybody does So it's kind of has this weird two-faced thing it needs to be powerful enough so that developers Can get the bugs that they want fix them and work on their stuff and not have Useless bug reports, but also needs to be approachable for new contributors so they can get their bug filed and start Interacting with the project and hopefully become DPL one day So this is a plot of The bugs from the beginning of time as far as the BTS is concerned starting from bug zero Well bug one in 1995 a lot of these very early bugs were actually missing because the archive Archival system just threw away the bugs instead of actually keeping them But we have bugs that are three digits Still present in the BTS and so this gives you an idea of how the Bugs have been filed over time We currently have 800 and some odd thousand bugs 170,000 and And They've been growing at a fairly constant rate So this is a logarithmic plot of bugs over time And the good news is is we're not we don't appear to be decreasing the number of bugs filed in Debian which is sort of an indication of how many people are using Debian I think you can sort of see here some blips around the release So when Jesse was released there's a lot lower rate and right before stretch was released There's a slightly lower rate, but it comes right back up Just to give a I'm actually a bioinformatician. That's my day job. So just to give a more formal answer There's no significant decrease in bugs from 2014 to today as you can see here the p-value is 0.6 and the estimate maybe slightly decreasing, but it's 10 to the negative 10 So that's basically not significant So that that's good, but this is also a problem because it's not increasing either So it doesn't mean we're not getting more engagement of people over time, which may be something we need to think about So roughly 134 bugs are filed a day I predict that the 880,000th bug will be filed in October 23rd and The 900,000th bug will be filed in 2018 and will file bug 1 million sometime in 2020 So this is this is a fun game that Christian Perrier often plays But you know these are my entries for this this game so you can see that over time It's been roughly linear the increase in bugs However, the bug fix rate is less than the bug Opening rate roughly 96 bugs are closed per day This is actually tracking bug archival not bug fixing because bugs can be fixed and unfixed over time But once the bug has been fixed for sufficiently long it gets archived and so this is tracking when that archival happened over time So you can see it's Decreasing slightly too, which is maybe a little alarming But anyway, that's the bug fixing rate This plot is a slightly updated version of the one that you all see if you go to bugs.debian.org slash Release that's critical. Thank you, and you can see this eventually I'll update this to actually do it using R This is a much nicer plot than the one you guys get to see but Your new plot is a lot faster to run than pulling up an entire r-stack with ggplot to actually do these plots that I'm showing So that's why that's not there Okay, so enough enough bug statistics Let me give you a brief introduction to how the BTS actually works. This is the BTS system diagram to some degree We have dead bugs itself, which is the gray box Which has two basic components to it There is a web front end which is a set of CGI scripts that everybody actually interacts with and then there's a male back end And the male back end is what actually processes all the bugs and does all the commands So the male back end runs on one machine called Bookstahood or have you pronounce that composer's name? Which I'm probably mauling and interacts with DAC and email and everything like that It also produces output that can be used with bug status that Brittany consumes in order to do testing propagation There's also another hook called smart sync that was written by DSA that syncs the entire contents of the archive the BTS archive every time it changes To a mirror so we can have lots of different people viewing the bug web pages without impacting the underlying male back end So that's just sort of the overview inside of Debugs itself. This is the basic flow Mail comes in we check it for spam We split out things that are sent to control versus things that are sent to a bug They're processed. They go into a flat file system Under db-h for who knows what reason And then those flat files are indexed to make the CGI scripts So the CGI scripts are only able to do queries that the underlying indices Are built for Otherwise they have to go through the entire list of bugs and sort of do some manual looking which is very very slow So one of the long-standing Goals that I've had and which I've been working on for probably five years now in my very tiny amounts of free free time is grafting on a database infrastructure To this this plot and so the database infrastructure is almost completely done now It uses db-ix class and pearl to handle all of this and All of the bugs can be loaded using Debugs load sql. And so this will load all of the unarchive bugs and archive bugs It also tracks versioning information The Debbie and information which Dac gives the bts so the bts knows which versions are of a source package are dependent on it It also knows all the source package versions that are in each different archive component As well as all the suites and all the log information So that's actually the major task that I've been working on during Deb conf This Infrastructure means that we can now do cool things like count who has sent the most messages to bugs This is actually incomplete archive hasn't finished loading yet. It takes about a day for archive to load so I'm working on trying to make that slightly faster, but Subsequent runs of the import run faster So you could see that Christian has the most and not surprisingly FTP master Has also emailed a lot of bugs because that's the bug closing that happens when you do an upload So there's actually more That's the unarchive bug count But eventually this sort of query will enable you to count but more importantly also get all the bugs that you've Corresponded with in real time We can also count the number of individuals who have emailed Mailed one message to one bug Some proportion of these are probably spam But you can get an idea. There's a large number of people who've just sent one message to the BTS and have never done a subsequent interaction and so it might be interesting to For somebody to look at these and see what we can do to build repeat interactions with users in the BTS You can also see which tags are the most frequent in the BTS so In this case you can see that patch is by far the most frequent tag followed by upstream There's also some funny tags There's a couple tags that have only been used once that were done in early development in the BTS that this query pulled out But I didn't even know existed because I didn't have an overarching view of all the BTS until I started doing this import One of the other cool things is I'm also now Calculating the status of all the bugs in the archive Over time and so as the bugs change status I can update what their status is and this will enable you to select bugs and do the RC critical Style listing but for any set of bugs or any set of tags without having to recalculate The status of all the bugs so currently the way the BTS works is you have to give it Something like a package or a severity or a tag in order for it to calculate the list of bugs Then figure out what the status is of those bugs and then finally only show you the bugs that are interesting This will enable us to only show bugs that are found in a particular architecture So if you wanted bugs which were found in stable, but not found in testing or in unstable You can do that now well in theory the code exists to do that There's no user interface yet, but but that's is a possibility to be done. And so that's a major major improvement So there's still a lot of work needed for this SQL component needs to be integrated into CGI. I'm actually working on I've been starting to work on that the rest of debcomp and there'll be a phase-over period where there's a debug slash You know database slash and then the normal interface while I'm getting that working There's also issues with the database loading and update is very slow So if you're an expert in postgresql I've done a lot of hacks to actually make it feasible to load this the BTS But it's still not as fast as it could be So if you're an expert in that and want to look at what's going on what's slow, please let me know I've also identified some corrupted bugs bugs where the log has gone away Bugs where I have no idea what the original report actually was but I know what the status of the bug is So in a couple cases, I've recreated my best guess as to what the report was because I know the subject But I don't know anything else about the bug And so that's actually kind of useful because this is missing history that without me doing this work You would have never been able to figure out what that bug was at all Because the web front end would just throw an error and wouldn't show you anything Needs a lot more testing because it'll fall over and then eventually maybe in the next five years. I'll deploy it Unless more people help So that's what's going on for that Okay, so let me shift gears and talk on Something else a little bit about some new changes that have happened One of the issues is that a lot of people who aren't using command line based mail agents Send messages that are format float or have other Line wrapping issues and this causes lots of problems when people try to read their bug report Because the bug report is one line that scrolls to the right on the web page for you know, 40 40 pages horizontally So I've tried to do a slightly better job of turning the bug front end into a smarter Mail user agent for you and in theory it should be wrapping Forcibly wrapping all those messages to the best of its ability I still need to fix some issues where people send control messages that have this sort of crazy wrapping and it makes the subject you know control our subject negative one Foo bug and then other mail software wrapped it So they've lost half the subject and now they've got an unformed or a malformed argument to control operator Subject there, so That's not yet working or I'm not sure if that's working if you have messages that people are sending like that Send owner at bugs.dev.org an email Saying hey, this is a message that got screwed up and hopefully I'll be able to look into the the Message headers and figure out how the mail software is telling you that you're supposed to magically unwrap that thing and make it work Some of that might not be possible, but hopefully that'll be better Another big thing is we're now using SSL links everywhere the BTS was Actually doing SSL for quite a while But it would you'd send the requests or it had lots of links that were using HTTP instead of HTTPS So you would send a request and then it would just redirect you to the correct encrypted link Which is kind of silly for a thing that's SSL encrypted. It should everything should be SSL So in theory that should all be done. I've caught I think the last couple cases where it wasn't properly Giving out the SSL link if you find more of those, please let me know We're also doing e-tag based caching everywhere so in theory the BTS has a There's a patchy on the BTS has a cat on this caching System in front of it because some of the pages like if you want to look at all the bugs and Linux take forever to load and so hopefully This tracks all the dependencies of a page looks at their end time puts them together calculates an e-tag and Hopefully that'll enable caching to work seamlessly I already caught a couple cases where caching with Car set an Apache sometimes doesn't do the right thing where it doesn't keep it as UTF-8 or not But if you run into more of those issues, please let me know a Couple other things one is the there's a new accessibility tag Which yeah, this is great Which is being used to track accessibility issues in the BTS For anybody else who has a specific issue that a Project wide tag would be useful as opposed to a user tag which only is used in a small group Please let owner at bugs.demi.org know give us a list of bugs and a Proposal for what the tag is going to be used for and then try to keep after me to actually create it Because it's very easy for me to see this and go. Oh, yeah, that's a great idea I'm not in the ready at that moment to do it, but if I don't get back to you. Let me know keep keep after me Another tag that's my personal tag that I created is the newcomer tag Made an announcement a while ago, but I'd like to highlight it again Please use this tag if you have a bug that's suitable for somebody's first Contribution to Debian If you don't need to do anything else, you just tag it and hopefully we'll you know identify some more issues That'll be good for first-time contributors One more thing that I just wanted to highlight is that user categories are now selectable So that means that let's see if I can do this So way down here, this is bugs in FTP master Some are down here. We're down here now. You can Select all the and there's some other stuff some documentation for local Debugs, which I'm going to show you in a second and Documentation about how versioning in multiple packages actually works in the BTS So if any of those sound interesting to you, let me know And feel free to jump in okay, so how can you help me out? So all of the source code for the BTS is now linked from the bottom of all the web pages. Yeah Yeah Yeah, they are Yes, the links are HTTP. Yeah, they should actually all be HBS even my own website now is HBS So yeah, you could tell this I haven't updated all this yet So the upstream branches Exactly the code that's running on Debbie's BTS is in the Debian branch So if you want to know exactly what's happening That's what this is right here the upstream Debugs branch is in the master branch And they're also checked out So if for some reason you don't want to use get you can actually see the checked out versions in those directories as well If you want to track whatever craziness I'm doing My personal branches are on my website which you can see but I try to push all of them to the master and Debugs Branches, but if you want to see all the craziness that I'm doing it's there We have a mailing list On IRC we're in the Debugs and Debbie and Bugs channel. I'm Don Delcaro everywhere. You can find me So feel free to in the Debugs channel ask any question or ask for help or if you want to contribute to anything Track me down there Okay, so I'm gonna attempt to show you how to use local Debugs eventually I'm gonna make an upload to Experimental and unstable with a version of this that works There's a version there that doesn't work that's been there for forever But the version and get actually works. So I'll show you how to do that really quick Okay, let's let's try this out. Maybe it'll work Okay, so this is the demo so we'll just get clone The the repo So you can run that We'll just assume that I'd run it because I've already run it before but anyway, you can run get clone Etc. Then I'll enter the Debugs directory So this is all of Debugs source code And the thing that we're gonna play with is called local Debugs Since we're running it out of the local directory. Well, we need to give pearl the Pearl library include option to include the local directory in the search tree. So that's what that dash I dot thing is doing And then we can run local Debugs and I'll just run help really quick just to show you the options that it has and so what this little utility does is it runs a Script that can download bugs from the BTS using our sync and then run all the CGI scripts For you to show all the bugs that it knows about locally So if there's anything that you want to do with the CGI scripts or anything that's user visible You can use local Debugs to make those modifications and try it out. So By default it's going to download all RC bugs and all bugs that you've Corresponded with and all bugs that you are a maintainer of Assuming you have the debi mail environmental variable set in your shell If you don't There's a little file called Debugs bugs to get that it'll create that you can specify bugs packages or Severities that you're interested in getting and so this is just a set That's saying that I want all the bugs in bugs.debin.org in Debugs These two bugs, which I just picked randomly all the bugs in scowl, which is the in US word list Or sorry, it's the English word list and RC bugs for example I can then run local Debugs mirror I might let this complete, but this will run our sync to download all the bugs Which will take it a little bit as well as some of the meta data it needs in order to actually serve the CGI I can then run Debugs demon And that'll start a little web-serving demon running on local host that will serve the CGI scripts And now I can run search bugs debbin.org and in theory Here I have my little local Debugs bug report which shows all the bugs in bugs at debbin.org So you can see all the bugs there Which is pretty cool. So then if we wanted to modify this Let's I don't know. I don't know if this is gonna work, but let's try. I didn't think about doing this before So okay, here's the package report, which is a CGI script that actually does all this stuff Let's do something stupid Let me see report Okay, so I'm gonna change report to feature logs here, okay for no particular reason So I've done that Now I'm gonna stop the demon with the stop I'll start it Now run the search again now Now it's the Well, thank you. Oh, yeah, let me see cuz I thought I did the package report. Let's see Yeah feature report This is why I should have tested this before. Oh well Anyway in theory that should work. So you should be able to edit and see what's going on there So anyway, so that's local Debugs that's how you can test out changes that you make to the CGI or any of those features and then submit patches upstream that I can incorporate So that I'd like to thank the other members of the team Bars Barsen and Colin Watson all the emeritus developers of the BTS who are responsible for the the current design and Hopefully you all will come and join us at some point in the future So that I'll take any questions or comments or discussion that you all have Thank you So offer you from dropping all the file based back end and having everything only in the database So my plan is not to drop the file based back end at least for a while And the reason why is because the file base back end is mature It's it's pretty robust. It's super simple and So that that's why I'm not planning on doing that partly also because I don't have enough band with myself to go through and and make sure that a database only system is bulletproof and And and me for me breaking the BTS so that I'm blocking all of your work is something that I just can't do I don't have the time to to be able to You know stand in the way of all you developing. So that's why I haven't done it I suppose at some point if it became robust enough and The parts to move all of it into the database work really well then yeah, that could be a future But it's not a plan that I have these look these local Debaks actually the same which runs on the Debian servers or Okay. Yeah, I mean the the CGI scripts are exactly the same all local Debugs. This is a little Thing that runs a local web Web browser and runs are sync for you. I mean you could do everything it does yourself It just was a little wrapper to make it easy. Nice. Thanks One one's quite stupid thing that has bothered me on the on the bugs Debian org website is this CGI been part of you of the URL, how open are you to implement Apache reverse proxies so that when you type bugs Debian org Slash one two three four five the URL doesn't change. So the copy paste is beautiful everywhere. Yeah, actually what I'd love to have is a a mod pearl or dancer or something that just Handles the one two three four five and Normally kicks out HTML, but if you says accepts Jason kicks you Jason instead. Yeah, no, I'm I definitely want that It just is a matter of finding available time. I mean the redirects work But yeah, we could probably even just do the reverse proxy just to make it seamless and patches go to you or to the essay patches go to me the DSA has an awesome script that a lot of the services use that you can modify Your own services Apache configuration and reload it yourself because you have pseudo to run one command, which just does an RCS With the config file, which is pretty cool. So So I have a tiny question you said you created the tag for newcomers And I was wondering if you defined in a documentation what was suitable for This user tag. Oh, yeah, so the tags are documented I can sense server control. I always forget exactly where the list is, but yeah, it's listed in where all the tags are listed Let's see tags Their meetings here we go. Thank you That area so that's the current thing if somebody has a better idea for wording for this, I'm totally open That's the current definition for newcomer. I made a little blog post But I I'm telling you all about it because I think it should be more popular. I hope you all will help make it more popular Have a question regarding the interface it currently the BTS interacts with email, but I think a lot of the Newcomers contributors from outside of Demian consider email to BTS Like I'm unusable. Is there a way To implement our stuff and have you considered that or in the same area as you don't have the time? Yeah, so I mean If you'd asked me this question, maybe six or seven years ago I would have told you that no email is the only real way we want to use it as a filter but but I've Thank you, but I've started to I mean I've learned Over time that you know what what works for me isn't necessarily what works for new contributors And so what would be helpful is yeah implementation that did this ideally with an email roundtrip Just to say hey, you're a real person not a spam bot or somebody who wants to use the BTS to increase your website's reputation, but I mean with that simple account sort of circle then enabling web Modification and submission would be great even just making a HTTPS report book interface so that report book doesn't have to try to get around the lack of Email that outgoing email from a machine that just got set up would be simple So yeah, so if somebody like like a very discreet task could be just to Write a CGI or something that could accept reports from a pork bug Turn it into an email that then all it did is forward it to you know one person it got it Yeah, yeah, yeah, that's the report I want to send and that was it that would be that would be tremendous and wonderful And I would accept such a patch Just a very simple question, but might become more complex afterwards. How huge is that box of CGI? The sorry the CGI part of that box. How huge it's actually not that big the real hard part is the all the modules behind it that make It figure out which bugs are present at which version the Transitive properties and all that the yeah, the reason I ask is because I've been playing around with modules Which is a modern pearl web framework? And it makes giving you an alternate version an HTML version or a JSON version or whatever depending on what the users asks Extremely simple. Yeah, so a free implementing that small part that is the web front and in modules Not that much work then that might be a way to do that. Yeah, or or dancer or yeah Yeah, I totally agree So I mean I'm trying to keep up with what the current state of goodness is for pearl web Things and I'll pick one unless somebody beats me to it, which would be great. I mean I have no problem helping to facilitate other people writing these sorts of So I have I have a couple of questions one is I Missed the the local debugs. Is that using the flat files of the database? That's using flat files Okay, the other is what's the current performance of the database against the full? Corpus is it? Is it considerably faster than flat file is right now? For the queries that it's running. Yes But the full the full database for example does not have all the mails and attachments. It just knows Certain things about the mails like the message ID the date the subject stuff like that who did it But it doesn't have any of the you know the 30 Megabyte core file that somebody attached for example isn't in the database. Does that sort of answer? Yeah, yeah, I'm just wondering The the current system is kind of hard to do discovery with if you're looking for something in particular And you're in your cruising through it waiting that three or four or five seconds every time is difficult If something could tell you how many messages there are which ones are RC and things like that a Lot faster it'd be useful Yeah, so the the database is actually pretty quick I mean the those huge joins that I ran to do the counting all took less than about five seconds to return And that's significantly more complicated than anything that the current interface is able to do. Okay. Thanks. So yeah, it's pretty performant So kind of an ecosystem question So I know the the GNU project has adopted the bugs So I was wondering if there are other users that you're aware of and whether you think that I mean that potentially Users community of users of the bugs can be a way to increase the bug the bus factor of the project Which right now it seems to be a pretty bad spot. Yeah Yeah, I'm The GNU project is using it. I'm not aware of anybody else who's using it at that level I know a couple people have set up individual instances, but yeah, it's sort of an unfortunate thing too is I when I Help the new project get their debugs instance started I didn't think about the community model that I should be working on It's a total blind site for me being a scientist I'm used to working in very small groups and not thinking about you know sustainability and community development And so that's something that I need to work on is trying to bring them back but yeah Just to comment about the database part One way to gain confidence is actually work correctly would be to put a dump of this and a dump of UDD in the Same post-racial instance and do cross queries that cross both database like looking at Well comparing the idea of both systems for each bug. Yeah, I agree. Yeah, that would be good That's something that I mean I have to admit I kind of siloed my development And I partly because UDD was moving so much more quickly than I was but but yeah We should definitely collaborate more between UDD and Debugs Any other questions or comments feel free to If you don't want to be on camera. Oh, go ahead. Sorry So are you also open to having a web interface that's able to actually modify with Debugs like setting tags closing