 Christine Spong is going to talk about distributed bug tracking in Dubian, using SD, bug tracker. So, let's go. All right. Okay. So, I want you to probably add the distributed bug tracking bot this morning if you are awake. So, what I'm going to talk about here is a specific tool that I've been working on that allows you to integrate with Debugs, our bug tracking system, and to do some distributed bug tracking stuff using this tool and allowing you to integrate with the bugs that we have in our Debugs system. So, just as an overview of what I'm going to talk about, first I'm going to do a super brief introduction to distributed bug tracking just in case you're not aware of what this is all about. Then I'm going to talk about how it applies to Dubian, and I'm going to introduce the tool that I've been working on and show you guys the state of the integration work that I've done to integrate Debugs with this tool. And then I'm going to mention some ways that you can help. And feel free to interrupt the questions along the way. All right. So, super quick. Distributed bug tracking. So, most bug trackers you guys are familiar with are centralized bug trackers, some examples, Google code, GitHub. Those are hosted examples. There are also things that you can run on your own like Track, RT, Bugzilla, and of course, Debugs, which we all use. And so all of these bug trackers have basically one location where all the bugs live. And in order to interact with the bug tracker, you go to that location or you send email to the server and it processes your email and updates this one location. Example, here is Debugs. This is where all the Debian bugs live. But we live in the future now and centralized is just not cool. And there are also some issues that centralized systems give us that can be solved by changing the way we look at things. So, it's a future. Networking is, of course, everywhere. Dis, never fail. Even if they did, we'd have perfect backups. And of course, system administrators are not evil. Life is good. Unfortunately, that's not quite the way things work in practice. So, I don't know about you, but whenever I actually need to get online in some location that's not involving a wire, it doesn't work. And there's also latency. Things are slow. You get disconnected. Hardware can fail. We can lose data. And we also have to think about who to trust. So, if we're using something that involves hosting our data on someone else's server, we have to wonder if we can trust these people and if they're going to suddenly stop service and not allow us to have access to our data anymore. So, bug tracking is a network service as well. So, you probably, you might have gone to Evan Moglin's talk. So, all the issues that people are talking about about cloud computing, they all apply to bug tracking. And so, we can take a distributed approach and we can use that to solve some of these problems. So, as they apply to Debian, some of these issues don't really apply. Well, we run our own servers. I hope we trust Don. He's not on DSA, but he does tweak the mail server configuration and spam stuff, I think. So, that's not a big deal. We've been running our own bug trackers since 1998 or earlier. And we still haven't lost all the bug data into a black hole due to some horrible fire. But we also have some issues that apply to Debian and this is a project that are more specific than just general cloud computing. We don't want to have centralized trackers. For example, our bug tracker was written in 1998 and it's a little crafty in some ways. And we are distros. So, we have bugs that are reported against Debian and there are also basically almost every package that we have that's not Debian specific also has an upstream bug tracker where people also report other issues. So, sometimes we even are the upstream and we have people that have a project that they're working on that they have an upstream bug tracker for and that person is also the Debian package. And that person now has to deal with two different bug tracking systems in order to basically take care of their software. So, there might be other distributions that package the software. So, the software has users that are not Debian users. So, it makes sense to have an upstream project page and upstream bug tracker. But then we also want to have our nice Debugs that's available for every single package and every Debian user knows how to report bugs really easily. So, one of our big goals is to be able to take these different sources and merge all the bugs into a single source. So, a package maintainer or a software maintainer can get a single view of all the bugs that apply to their package and not have to run around to like three different bug trackers and like link back and forth in their heads. And it's just really a pain to look at all these different sources separately. And another goal is that the bug tracker should be simple. It should get out of your way. People don't really want to track bugs. We want to make good software. So, I really hate interacting with bug trackers and they all kind of suck in their own way. So, we want to make something that gets out of your way and that you don't think about, that you don't hate interacting with so that we can do this stuff that needs to be done and get onto the fun part. So, one way that I've been working on to sort of address some of these problems is with this tool called SD. So, I started working on SD in summer 2008. I was working for a company called Best Practical and my boss Jesse likes to hire people to work on his pet projects and not like actual work. So, SD is basically, it's a distributed bug tracker. It's built on top of a thing called Profit which is a peer-to-peer database that basically it stores property key value pairs and it has capabilities to synchronize back and forth in a peer-to-peer fashion. So, you can have a person with like a database that's Profit and you have another person. You can like pull from that person. You can publish to some location that that person can get to and you can pull back. It has the features to be able to publish your location to like an avahi local network thing and you can discover those. So, it's got a bunch of cool features. It's got a website. It's right here. That's an interesting website. So, how it works basically all the just like a distributed version control system. You have all your data that's kept locally. In this case it's in a database. And I just mentioned how you can sync back and forth. All right. So, I'm going to show you guys like a brief demo of just sort of vanilla SD. It even tells me that it's right here. Okay. So, what we want to do. So, you have to tell it where to find your repository. So, we're going to... Okay. So, we're going to have a database in a practical test. So, we're going to initialize. Okay. Sure. Let's edit our database settings. So, when you start a new database it's configurable. So, you can say like devconf test database. Okay. And then... All right. So, then we can do... Okay. So, we don't have any bugs yet. But we can make a new one. It'll bring up a nice editor that can allow you to go, hey, I did make the fonts bigger. Do you want them bigger still? Okay. I'm going to leave them as they are because it might get too wide if I make them any bigger. Okay. And... All right. You can describe the bug better here. And then you save the file and then it creates your new bug. SD calls them tickets. Chrissy. Chrissy. Can you please make bigger fonts? Because in the stream people can see them. All right. Sure. Bigger still? I don't think it wants to go any bigger. I don't know. Okay. Well, we'll leave it as it is. All right. What was I doing? Okay. So, now you can see our new bug. SD also has like a shell. So, you can just fire it up like that. And then you can do like list tickets. And you can say like... You can show all the data. So, you have the metadata and then there's comments. I guess that's here. And then it will show the changes that have been made to this bug. So, you can also edit. Let's say you want to make it open. All right. Owned by me. And then you can see. So, it's configurable. You can make it display whatever fields you want in the summary line. Right now, it's grouped by milestones that are configured. You don't have to use milestones if you don't want to. We can also add like new comments. And there's also... There's a web server front end. So, we can go to here. You can show open tickets. And here's our bug. So, basically, you have the back end. You have a choice of front ends. I really hate the web. So, I use the command line. And that's pretty cool. All right. So, I mentioned already, I kind of hate all bug trackers that are paying. But I almost like SD. It's getting there. It's kind of fun to use it. And that's good because we want to not want to run away from our bug tracker. So, the way I've been looking at things, there are basically two main use cases that I see for using SD with Debian. So, first, there's a case where you're just the Debian maintainer. You're not involved upstream. You're not, like, super interested in upstream's bugs. Maybe you just want to use SD as another interface for interacting with the Debian bugs. Maybe you have a Debian specific package. So, you can use SD to basically query the bug tracking system, pull down all the bugs that you want. You can put them in the same database. You can just basically get a listing of all your bugs. And you can see them locally in a different interface. So, there's, like, an example of a query right here that would pull down everything that you maintain. Don't try that right now. It will actually work. Like, there's a bug where sometimes, there's, like, one of my packages has a bug that, in its log, has an entry that doesn't have a timestamp and that makes it crash. So, I need to fix that. So, I've been developing on a local version of Debugs, which is why it's localhostnotbugs.debian.org. All right. On the second case basically is where you want to, so, say you're involved in upstream, you're, like, a very good package maintainer, you may contribute upstream and you want to take upstream bugs and your Debian bugs and combine them into the same view, the same location. So, you can do that with SD. So, you could, you can have either two different centralized bug trackers that you interact with. So, there's no limit to how many different places you can pull from in an SD repository. So, you can pull from, say, Debian. You can pull from, say, like, a bugzilla instance anywhere. Actually, there's not actually bugzilla integration yet, but in theory. So, you can have those both in the same repository and then you can see them all at the same time. This could even end up being extended to, say, pull from Fedora and you could put all that in the same repository. And in the future, it could be, it could do some sort of, like, linking bugs together so you can see which ones are associated and things like that. All right. So, I've been working on this for a few weeks now. I kind of hoped to get it to a more mature state by this point, but I forgot that Debugs is made of email. So, at this point, there's, like, pretty alpha read-only support. I have it working to pull bugs from certain packages. There are some edge cases where the bug logs are giving you strange data and I don't handle that correctly yet. So, basically, it's going to support all the queries that the SOAP interface supports. So, like, my goal is to have development for the queries going into the SOAP interface and not into the client because, well, first of all, the SOAP interface is what has, like, first-class access to all the bug logs. And second of all, I don't want to, I don't want to be doing, like, a lot of parsing of data on the client side because I would prefer, like, Debugs to be able to change and still give me the same data. So, I've had to, like, do some hacking on, like, a local version of Debugs in order to get that working. The history is currently incomplete. One thing about Debugs is that we've had this sort of incremental upgrading over time. So, like, the data in the bug logs is not always the same depending on how old the bug log is. So, like, over time, we've started recording more different things. Nowadays, we record when an action is taken as, like, a result of a control command. Back in the day, we only recorded the emails. So now, there are some cases where you can get a nice, like, a nice differencing of the properties of the state of the bug just from the bug log. It doesn't support all the commands yet. So the history is a little incomplete. And at this point, we're just skipping things that we don't have the right data for. And that could be a lot better. It depends on patch Debugs. I wrote this new soap call called Get Machine Readable Bug Log. There's an old sub-call called Get Bug Log. And that will return all the messages. But I, as I said earlier, I prefer something, like, a bit more structured. That makes it a lot easier to develop on the client side and do a differencing when you want to have an entire history of the bug. Okay, so now I'm going to show you this. I'm going to show you, here's, this is a Perl command line. And so here's any, sorry, what's that? More fonts. Okay, this also gets kind of, okay. White background. Okay, I could do that. Thanks, guys. Okay, okay. Is it good now? All right, I'm not going to touch it anymore. Okay, so we can have a different soap query. And that will return, basically, it looks like this. Let me try to find a good part. So things will look like, have an entry number. And then, like, a parsed version of the queries. The data in the bug logs is a little unfortunate. Anyway, I expect to keep working on making what Debugs will give us better. That will make it a lot easier to do client-side stuff. Right. Okay. Here, okay. So what I'm going to do now is I'm going to show a clone of some data from my, so I'm running local Debugs just to get the mirrored data. And then I have a, like, a soap demon running. So I have a local soap server. Okay. This should work. Oh, wait. Okay, this isn't usually this noisy, but I have a lot of debugging output on right now. Okay, and then we can do, so that should pull all the bugs related to SD. It might only do open ones, I'm not sure, by default. And here, we can see the bugs that I have. All right, and you can see, wait, that's not right. I want to go. Right. Okay. I'm going to see some bugs here. And then we can go back. I'm going to see some bugs there. It might even be the same number of bugs. And then we can take a look at some of them. Okay. So we're recording the Debian bug number as the Debian ID. And also some other information. This is, it's not very complete right now. I hacked this up in, like, the past three days. And so you can see we have comments. Here's the initial comment from when it was reported. And then here's another one. It looks kind of a little hacky with the emails. But we can definitely change the display pretty easily. And so here I replied. And then there's this other email. Oh, wow, that got closed. As you can see, it didn't actually close the bug properly. But there's progress to be made in the future. Then we have some history, which is kind of incomplete. But it shows at least the beginning of it. Yeah. So you can configure SD to, as to what properties you want it to show by default. In this case, I've just been, like, turning on the option that says display everything that's on this bug. Because you might want to have some, like, hidden properties or things like that. So it doesn't necessarily display everything at once, but you can tell it to. Which was easier for the purposes of this demo. So it just displays all the properties that are set on this bug. Okay. And then I can say, let's go back to this. I don't want to do that. And so then later on, you can do a pull. And in this case, usually you have to tell pull where to pull from. You can also do minus, minus all. And that will pull from every single place you pulled from before. And that should have done nothing. Cool. I think it worked. Okay. So as you see, it kind of works. We definitely have a start. The history thing is going to be challenging. Just because we need to do a bunch of server-side work on Debugs. And I'm not sure we're ever going to have older bugs be first-class citizens. Because the log data is not super complete. But we can definitely make things better going forward, which is good. Okay. So we have a start. This is definitely not where we want to be eventually. But there's a lot of work that we can do. So what we want to have is we want to have the full history available locally. We want to have all the data you would see when you go to bugs.debin.org slash whatever bug number. You want to be able to look at that locally. Because the point of this is to give you an alternative interface that you don't have to combine with the existing web interface. You don't have to look at your stuff locally and then look at it on the actual bugs. Because that would be silly. We want to have full read-write support eventually. This is going to be tricky. So either, did anyone know that summer of code person who's supposed to be working on read-write-soap? Is he working on that? Cool. Sorry, what's the status? You might want to repeat that. I don't think anyone else heard you. It is almost complete. I think he will polish in the next week and then we will see if we can integrate it into the box if Don is happy with the page. Great. I'm glad I didn't start working on this any earlier because I might have tried to do some stupid thing with email. That makes me super happy. That will make things a lot easier. That's exciting. I thought it would be kind of difficult because Debugs is not very synchronous. Cool. He said that it's actually quite easy to do, which is great. But someone should get Daniel and Mike. He seems anxious to say something. I hate the web as much as you do, I think. Great. I also hate email, but I kind of think that email actually has some advantages here with the asynchronousity. In particular, if I'm doing this work offline, it would be nice to be able to queue it and send it back through my mail transfer agent. It seems like you're at sort of a disadvantage with Soap unless you're talking about having things. Can you explain why the Soap interface is preferable to email for you? I just think it would be a lot less of a pain to implement because when you do email, you have to send the emails and then you need to mark in some way that you have these local change sets that you're going to see again when you pull. I just think it would be kind of a pain. I guess there's probably some advantage to having this queue up all these emails. Are you going to queue these changes? I want to be able to work offline. This is exciting because it offers these great opportunities. You're saying that you would stage stuff locally and then it would be SD's responsibility to figure out when to push. Then because Soap is synchronous, it could say, okay, we've actually done this one. We don't have to wait for an indeterminate amount of time for a round trip. Currently, you would say, just like if you say how to get repository, you work locally and then when you're back online, you say push and it pushes. That's what you would do now. You could work up something. I don't think I would want to have it. SD doesn't run persistently, so you can check the network whatever. You would want to just push it manually. I'm not sure what you're aiming for. I guess I just wanted to make sure that I didn't have to be online in order to use SD. Oh, absolutely. You're going to make local changes. They just won't be synchronized back until you tell it to synchronize back. Okay, thanks. Okay. Anyone else? There's a guy over here. Well, originally asked like three months ago, I guess, I asked upstream, is there anyone who works on Debian bug tracking system integration in SD? So it's really nice. At that point, they said, do we someone? But I don't know who. So they can give me any references. Who said this? Okay, okay. But they might be listening to us. I'm the right person to ask. So it's really great to see it going. Yeah, definitely. And now I forgot what I wanted to ask. Also, with email, what is convenient for me, that I can see which bugs I've already seen. Let's say there is a list of open bugs. I see. So you can mark things as red, essentially. Which I usually don't want to see. I know that they're open bugs. Then second question. And this is more critical in terms of, let's say, he fetched bugs for our package. I fetched bugs with identical ID in terms of SD. Will they be in your system at this point? Because there is SD tag for every bug. Not tag, but identity. There is Debian identity. So you're saying that if you pulled some bugs from Debian and someone else pulled some bugs from Debian, what would happen if you tried to merge? Yeah, because I can add his remote SD to mine, and that's the whole idea of distributing. Currently, it wouldn't recognize that they're the same, because every time you pull from the bugs, it assigns a Uyrid. So is that under your control? It's probably possible to do something, because we have the bug numbers. So there's definitely a room for doing something there. Right now, it would just duplicate them. I would think they're different. Because it's not looking at the general model, it's not looking at this attribute called the bug number of the Debian bug. So that's one of the things, and then I would be really thrilled to see how merge would work. Yeah, yeah, yeah. I'm glad you brought that up, because one of the things I want to get out of talking to all of you is what sorts of things would make this more useful for people and what sorts of things we should be looking to work on in the future? Great. Do you have a look and relay the question? Okay. The SD database, is it the kind of thing that you could store in a version control system and merge across branches, or is it really kind of its own separate thing that needs to be its own separate database? I think you probably wouldn't want to. So there are several different backends. There's a file system backend, there's a SQLite backend, which is the default. There used to be a subversion backend, which was incredibly slow and no one uses anymore. I'm not... What would you be looking to get out of that? One of the... What would be nice to do is combine this kind of a system with the ability to do the distributed bug tracking type thing, where if I close a bug on a feature branch, and then I merge that feature branch into master, I merge my bug state into master's bug state, so now it knows that the bug is now fixed on a master branch, and if I then merge that into Debian, then it knows that I'm fixing the bug in Debian, that kind of thing. And a lot of the systems that do that, they do that in part by storing the bug tracking data inside Git, so when you do Git branch merge, you merge your bug tracking data. Right. So SD was kind of intentionally separated from a version control system. I didn't write the actual backend, but my friend Jesse, he definitely looked at the whole bugs in the version control system type system, and I think his conclusion was that you have to do a bunch of hacks to get the UI right, to do merging right with... Because you basically have a bunch of properties, and like, Diffing is not always the right solution there, and it's kind of klugey. You could definitely do, like, commit, like, tracking of what commits fix something through, like, properties on bugs. You would... It would probably get a little complicated, but I'm not sure... I'm not sure it would be... It's just like a different set of problems than you have when you have the actually in the... in the VCS itself. Yeah, I suppose I would have tackled inside the VCS, I would probably would have... I would have tackled that with a custom merge handler, because then it knows what the format of the file looks like, and it can do a smart merge, which would get around a lot of the Diffing problems. Yeah. You could probably write some sort of get backend if you wanted to. Like, the backend is pluggable. I think I'm probably not going to do that anytime soon, but feel free to play around. Have you considered making a... a data extractor that uses... that goes and looks at the VCS and says, oh, this bug is closed over here and then pulls that back into SD? Sorry. I'm not sure what the actual question was. Are you talking about... I'm making... Just like SD can go talk to the WNBTS, make it go talk to Git and say, oh, okay, this bug is closed in this commit, and then record that back to SD. Oh, I see. And you could probably do that. I haven't, like, super thought about it. I mean, like, you can write... write lots of different things to integrate with SD. So my comment was... to Joey was, you mean parsing the change log? Like, one thing I have done is, like, made a commit hook that you can, like, say closes this bug. It's, like, not quite the same thing. But you can do a bunch of different things. Like, I really... I've pushed my question as the bug report against SD. Could you demonstrate online that you're getting it? I'm not sure if it was accepted already, but... So you just filed this bug report? Yes. I've got confirmation. Did you got the bug number? Not yet. Not yet. I mean, we should wait a few minutes. I'm not sure if it'll be there yet. We can look. I actually want to go here. I just want to see if it's there. I don't trust my code. Should do a wish list. Not yet. I think it's probably not there yet. Okay. I'll just... You can bug me again later. Oh, wait. There we go. Okay. I don't remember what's next. Okay. So in, like, the beautiful future, we want to be able to pull bugs from every single source related to a piece of software, work on them locally, link them together, and I have all this fancy integration stuff, and then be able to push them back to the sources they came from. And that would be amazing. So there are a few things that are going to be tricky about getting there. It'll probably take a while. One thing that I talked about is making Debugs record better log data. One thing... So recently, they started recording in, like, HTML comments whenever something changes in the state of a bug. But it doesn't cover all the different commands right now. There are a bunch of different things that don't do that yet. Like, these are the ones that I saw when I was just working on writing things. It's probably not a complete list. But that would probably be, like, a relatively easy, like, task that doesn't require you to know everything about everything if someone wants to, like, look at Debugs and finish this up. As I mentioned again earlier, Gracefully falling back for older bugs that don't have the right data. And one thing that we don't have yet in SD that would be very useful is that so right now, when you do a push, it wants to push all the change sets that you have in your local database. And so if you don't want to have all your different sources basically synchronized with each other, that could be a problem. So say I only want to sync my Debian bugs back to Debian. We're going to need to do some more work to implement that in SD because it doesn't yet support saying, like, only push back the bugs that I got from, like, this URL or this server. Because you probably don't want all your upstream bugs to go back to Debian. And again, like, we were discussing earlier in the bof. It would be nice. So basically right now you have to write, like, a module for every single bug tracker that you want to talk to. Like, there's one for RT, there's one for track, there's one for Debugs, and a bunch of other different things. And that's kind of a pain. It's not like a huge amount of code. It's like, I don't know, six or maybe a few more functions that's basically converting the history and the bug data into SD's format. And if we didn't have to deal with a different API for every single bug tracker, that would be a lot easier. So I made a list of things that people can do to help if they're interested. SD could use more contributors. Like, the people that work on it are super busy people. If you want to do, like, UI work, or if you want to implement stuff that is not yet implemented, there's like a huge list of bugs, features in the SD repository. I love saying that. So that's useful. Like, how to write foreign replica. That's what SD calls them. It's a foreign replica. So it has like a replica, which is the SD native format. And then foreign replicas are these other things that it talks to. It's not very well documented as to how to write these. So I kind of, like, if no one else does this, I will do it eventually, that would be useful because that will help other people to be able to write more interfaces. That's also some cleanup and work that can probably happen on Debugs. One thing I found was that because I wanted to return structured data, I wanted to reuse a lot of the code that Debugs uses for parsing the initial emails. And some of that is not like in places that's very good to reuse. Like, there's some code in the process script. And the process script is like a thousand lines of this like pearl that looks like 15 years old. I noticed that rewrite process is on Don's to-do list. I'm going to continue to nag Don. Anyway, it would be great to have some of that me move to like libraries that like say I could just call that function instead of copy pasting things that shouldn't be copy pasted. Again, completing the Debugs action recording, it would be nice to have some tests for this new soap method otherwise someone's probably going to break it accidentally. Like we were talking about in the buff, there are a lot of complicated issues that come up after you get the easy part done. Like, how do you merge things between bug trackers? How do you deal with the social issues that different projects have different standards for like what status is used? I was going to talk about this earlier. And the whole like getting a standardized API that's kind of a big project and I don't think we're going to solve it anytime soon but people should be thinking about it. People, that's really useful to get some ideas going there. Here's where to get the code. There's basically two different parts that I wrote and then there's also Debugs local. So, to get it running, you need to probably use Debugs local to create a local mirror unless you're creating a full mirror. You want to have some bug data locally in order to do development. Like, eventually when this stuff is actually deployed on bugs.dev.org, you won't need that. That's not the case right now and I expect it to be probably a few more months before I have things in a state where I want them to be live. And then there's a bizarre branch which is of Debugs and then the Debugs integration for SD is on a branch in the Git repo for SD. And if you have anything you want to talk about or you want to help, you have ideas, you want to pester me about anything, here's how to get in touch with me. And that's all I have. I'll take questions. It's there. You want me to test this? All right. I hope this is not embarrassing. Oh, it's not there. Oh, right. That's true. I think this is kind of a problem because I uninstalled Debugs local because I didn't feel like making it work to override my local copies of the pearl modules or the system ones. I could reinstall it if you guys really want me to. Right now there are ones for RT HiveMinder which is like a to-do list web service from Best Practical. Lighthouse? I don't actually know what that is. I don't know. These are like basically things that someone had the interest in writing one for. There was like really bad support for that line. Someone should fix that. Track. Not Debugs. One thing that's missing that would be really useful is Bugzilla. I think someone was concerned that lots of people have very hacked up instances of Bugzilla so they might not all be the same. But we don't have any support for Bugzilla yet. I think those are the major ones. I I'm not aware of anyone working on Bugzilla right now. Okay. Okay. Oh yeah, right. GitHub and Google Code. I always forget about those. Let's try this. This might take a while. My disk is really slow. Yeah, yeah. Anyone else have anything else they want to talk about while we're waiting? Someone got a mic in there? Questions from IRC about standardized API. There is already OSLC-CM. Oh yeah. Someone reported a bug on that recently. I haven't looked at it yet. So you answered. The question was ever heard of it. So you answered. Okay. I will definitely look at that. The bug is in my queue somewhere. Another question. There are programs with SD back end. So more user friendly maybe front end for SD. Someone's asking. Well, the question sounds BTS program with this deep back end. Oh, I see. Like the BTS script. Like, I'm not sure. So, Oh, I see. So someone is asking if it would be possible to like make BTS interact with SD instead of like sending email or like creating the soap interface. It was just maybe more user friendly interface and on top of it interfacing with SD database for a box. And there is another kind of visualist sometimes there is precedence information in time but also in the threat of the bug report, right? People report reply to different things. Either SD encapsulates that notion of a threat. So we could easily go through the history but not just by the date of the discussion. Right, so we could do some sort of threading based on message IDs. There's no UI for it yet. I would definitely put that on the like interesting things to look at. It's a good idea. All right. Is that right? I think. Is that a question in the back or are you just holding up something that I can't read? Oh, and about back end to use bts.dash and box show with SD back end. So we have already exported into a mailbox from the bug tracker. So maybe you could somehow just get from there, I guess. Yeah, I'm not super familiar with how BTS works. I've used it a bit. Could it be possible to transfer Debian Box to upstream bug trackers with SD? You could, you can definitely especially once we get like partial push you should be able to pull from one source and then push it to a different source. Okay? I don't know if this is going to finish before you run out of time. Also then the question about is SD having enough semantical information in the fields to encapsulate all the information from other bug trackers. Let's say with github the bug tracker is really having loose notion of let's say you can just attach tags which can have different meaning like tag milestone one or maybe it's about doc or web which has similar notion as D but milestones are different. So is there and maybe other bug trackers they have even further different fields. So how much SD can encapsulate information from other? So it's easy to record arbitrary information on a bug it's harder to know what to display because since you're you're integrating things from a lot of different sources you need to have like some common set of statuses so basically like all the different bridges right now convert from upstream to the local you can save additional information it's probably going to be a little hard to make the UI completely uniform you can definitely you can configure things if you're using things in like a certain way so if I was using Debugs just for my Debian packages I would probably like have different settings than if I was using it for Debugs plus upstream because that's like integrating two different things it's like a hard problem we should think about it some more unfortunately we are out of time so thank you very much Christine I'll try to pull this bug later it should be a fun test