 You know all kinds of different tools and things, but I really haven't been doing anything on it in a year and a half So I might not be the right person to talk about you know So is this are we talking specifically about We're talking specifically about Debbie and bugs not just bug not distributed bug talkers in general Or that's what you're interested in both both aspects. I mean, I'm specifically interested in In Debbie and bugs, but I'm also interested in the problem set in general because they both are integrated Yeah, so the the the big thing I see about well, I Feel like they're quite different problems since Managing a single project of source code versus The entirety of Debian is different things, but it just occurred to me while I was sitting here that For Debbie and bugs We kind of already have a distributed way of Distributing them which is the package management system. So could we make a package that is Open bugs I mean, I don't know. I mean, so this is that it would just be a single one directional Thing and what it would but we're looking at more is more of a way of Subsetting different bugs and enabling them to Change sets to be transferred between them reconciled merged how to reconcile state between all the different bug trackers It seems like I mean It's a really that seems like a really hard problem to solve if you're not sharing a some sort of repository that is Distributed well you would be because I mean at some level you're working with other people on the same set of bugs so But what if but what but what's what's wrong with what's wrong with having the I mean the email system be continually continued to be used for Submitting and are manipulating the bugs But then the just all of the information about the current status of the bug be available in like a package I mean, so there's nothing wrong per se with that But that's just a method of sinking back the changes via email But you still have all the conflicts and everything else that's going on So I mean these are all sort of what's going on with Why this is an issue why it would be interesting to be able to do it and also I mean to share the changes with upstreams Etc. So so can can somebody give an overview of? What were some of the ideas that were thrown out so it was like is there an idea of maintaining a? something like a git repository that would That would control the status of current open bugs or something like that Maybe Christine you want to talk a little bit. Sorry Yeah, so I mean I don't want to make you repeat your talk here in the box So sorry, what was your? SD Yeah, yeah, that's 1130. What was your specific question or? Okay, I think I guess we've talked about some different things one thing is sort of like a standardized method for like Passing data back and forth between different bug trackers. So like at this point it's gonna be There are lots of different bug trackers out there like people are probably not gonna stop using them But if we had some standard method to query those bug trackers and get the the data out of them and talk back and forth then we could write our own tools that use that data and Allow you to modify it locally and pass it back and forth, but so past data between different But what different bug trackers different bug trackers of upstream like like debugs launch pad? bugzilla Okay, everyone everyone has their own different bug tracker and they're pretty invested in those different but those are all those are all upstream issues not Debian specific issues Right, but that seems like I Mean yeah, okay I so I can imagine that there are lots of different ways you could break it down like you could break down just worried about making Debian bugs distributed you can worry about Making the the bugs for a specific upstream project distributed or you could do some sort of Meta thing where you're trying to Make a distributed layer on top of all of the upstream bug trackers that seems like a Way more ambitious. I mean maybe that's a useful thing to do, but it seems pretty ambitious I mean, I think eventually we do want all Yeah, go ahead. Sorry. First of all, you've got disconnected. I think so I See more than you see and everyone else and I see some changes from other people awesome Yeah, and about bug tracking. So What we have already marks that? It's important for Debian users to see what other People discovered outside of Debian many bugs reported in debut and they're not just about deployment of And problems with Debian packaging but with issues of upstream right and quite often They're already known upstream or somewhere else if there was a way to kind of pulled all that information together That would have been terrific, right because then you report bug you have a little I think if it's already distributed then It's kind of just one step aside, which Oh But but that's what when we'll talk about is D. I guess that's the whole purpose of it That you can first of all sync with other bug trackers and keep all together information I'm not sure how merging would occur and how forwarding kind of back to a remote will occur But that's the whole idea that you just kind of keep this information together. I would be very curious to hear how somebody suggests putting a Distributed bug tracking layer on top of a centralized bug tracker. Well, I mean it's it'd be quite simple in the case of the BTS You just provide a standardized way, but we weren't but I thought that specifically it wasn't the BTS Well, but that's an example of a centralized bug tracker Right, but we have control over the BTS sure, but but so do all the upstreams. Yeah, Joey If you're interested in doing distributed bug tracking over systems that you don't have control over you have the option of scraping and then there's the option of doing some completely distributed thing where the upstream BTS doesn't have to know About the bugs and just link it with your bugs somehow And I've been trying to think for quite a while the way to do this and I haven't really come up with anything I'm about two years. So I've kind of given up on that I'm just I just think that syncing and scraping and things that SD you're doing are the right way or the only way at the moment Yeah, I mean the other thing is is that if we want an example of how you take a distributed system and make an interface with Centralized systems and get SVN, right? I mean that's the same problem if the SVN server doesn't know anything at all about the fact that you're trying to do something Distributed and you write a conversion layer So I guess beyond that the other aspect is how do we do conflict resolution? And how do we expose a? Centralized layer or an abstraction of the states of bugs that are upstream and not Unfortunately, once I try to get back online, I can show what's going on with the Gobi, but One of the things that for me I at least I assume the state that you care about for upstream bugs is whether the upstream bug has a patch in Upstream whether the upstream bug has been fixed already by an upload of a new version whether the upstream bug So hopefully this will come back up So the the question is whether the bug is fixed where the bug has a patch Whether the bug is still open and whether upstream has it marked as they don't want to look at it Whether it's not a bug or won't fix I think That's for a while. I'm thinking those are the smallest set of Federated changes that you want to change and is that sort of reasonable with what you think Christine is that about right? Yeah, that sounds good So how is SD doing with regards to scraping and or plugins and upstream bug trackers? I mean, is there a standard now or you just still scraping everything so most of the Bridges to upstream bug trackers and SD use like some sort of like querying interface like Debugs has so Some other places some other things have like a rest interface In some cases like track we're doing some really crazy hacky thing that involves scraping Like it's unfortunate that this tends to be a kind of a lot of work because you need to get the data that you want and Sometimes the the upstream tracker doesn't give you that in a nice way So that's why I was talking about the whole like standardized thing. I know Lars and Don and I talked about this last year a little bit So if we had like a standardized way to query all this data, then we would have to write only one bridge instead of like And just just out of curiosity. Are you are we talking just about tracking upstream bugs or actually modifying them? I mean at the first stage is tracking is right helpful But it would be ideal to be able to do all the above So I mean I think in order to even consider being able to modify them in an distributed way You have to know what the state is. I think that's state one Once we get to that point that we can consider replaying changes and stuff like that As I mean, you'll probably talk more about right right. That's definitely the like the pie in the sky goal But like read only pulling down data is the first step So has anybody worked with some of the bug trackers that are more tightly integrated with VCS systems, so I know there's a couple that that worked that I personally haven't worked with them And I was sort of wondering if somebody here had done that and found out how useful they were So I didn't have to try it out myself So can somebody speak to that if they play with them? I mean I have a fair amount of experience using track with SVN is it is that the kind of integration that you're talking about exactly so, yeah, I mean it It it works. Well, it's it's nice for end users who just because it provides relatively simple web linking between the the revision states That fix a bug or if you put in comments and you can you can point to source code you can point to you know change sets from the revision so It's handy. I don't I mean you said that track was actually particularly hard to scrape. I can imagine I Mean there's there's RSS feeds, but that's about and I don't think they they contain any real detailed state Great the current the current thing just like does something crazy with like its web forms. I didn't write it so there there actually is Track will produce RSS feeds which might be slightly more intelligible than arbitrary scraping of HTML, but I don't think they include, you know detailed state in the in the RSS. Sure And I mean I find that I find it useful, but it's more useful from a sort of user interface perspective I don't think track has particularly good Ability to bind bug fixes with particular revision sets. It's like it's in the it's in the common history or something like that I don't know how easy that would be to figure it out Um, so it just occurred to me while that was mentioned that There's a thing called scraper wiki, which is a general solution to this class of problem where you have a set of Information available on various bits of the web not necessarily in the same format And what you want to do is coagulate that into some kind of consistent database so that you can display and interrogate that So that is exactly this problem so scraper wiki is Both the site and the mechanism so you go and write a scraper for a particular page and Everybody does that for whichever thing they have to deal with and then that's collected together and then you can write views of the data you collected on the same place, so Maybe we could use scraper wiki to do this thing of scraping various places if that's the only way of getting the data It's not the best way of getting data by a long chalk, but a standard place exists to do this and it's really rather cool I just thought I'd point out well first As far as things that just use a version control system and put bugs in it I count I count something like 12 or so listed the URL up there I've only looked at a couple of them. I never really found one that I liked I personally just use a key wiki and put the bugs in there and that way I have them in but that's very non You don't get to have another scraper for that But the other point I wanted to make is that there actually is one big distributed bug tracking system out there That is in wide use which is the CV identifiers because You know it has a plethora of different distributions and things different people reporting security holes and They use science assistant IDs, you know, and that it's it's very basic That's sort of the current state of the art in some sense For a really really distributed system between a lot of people who are never going to cooperate any other way That's true. Okay with that also is there The other things that I was looking at as well are the bug tracking systems Which are directly tied to like a distributed versioning system. So in the case of Yeah, exactly like virtuoso or some of the other ones that are directly in Distributed VCS and then enable you to merge back changing Okay, it's a wiki. Sorry So is anybody used any of those that? Tie directly to any of the distributor book trackers, okay So I guess I'm gonna have to try to play with that and figure out how those work We're doing so how many of you work? When away where you're offline a lot where it's hard for you to get back and connect to the VTS Well, not for Debbie and work. Yes, but for you know, my icky wicky type work and several other things now It's all in that so I just commit to get so it works fine, but For Debbie and it's obviously an issue Okay, so there's at least ten hands in the audience and we have I think about 15 or 20 people here So at least half the people to some serious offline work. Okay, so this is going to be useful Does SD currently also export the comments or is it primarily state? Right now my debug sync polls state comments That's pretty alpha, but I'll talk about it at 1130 Okay, but is that and so SD in general is pulling comments. So, okay Okay, so those were sorts of the main questions that I wanted to get at one of the secondary things is how to actually go about storing this So Lars and I'll try to Talk as if I was Lars about what exactly he was looking for in a distributed bug tracker What he basically wanted is something that looked like a mailbox So you have a mail or a mail directory which has a bunch of series of comments in it Which are pulled from all over the planet. So the upstream bugs that relates to this bug is there the Fedora The gentoo comment of the bug the launchpad bug is there the Debian bug is there that all relates to the same bug So you can see at a glance all the comments You can then using your mail reader or something similar or a specialized tool or whatever write your current Work on that bug your patch set to this mailbox or whatever Run some sort of tool that then pushes all of the chain sets that you've made to a centralized place that you happen to work with Which may be Debugs? Then make those changes Possibly doing conflict resolution and or refusing to apply states that have already changed underneath you And then in the reverse Updating all the bugs that you're interested in with everything that's happening in the cloud So we sort of been talking about this for a couple years now I think and neither Lars nor myself have actually managed to have enough time to seriously implement any of these projects so Does anybody I mean is that something that you all would find useful or? And is somebody interested in working more on this with us So it sounds like What most of what you're describing can just be handled with mail What to some extent, but I mean The pulling all the bugs in a way that is actually easy from all the upstream bug trackers that are around So but if you just had a I mean if you just had something that turned Something that just turned a particular upstream bug tracker into mail to a mailing list Yeah, but then you'd have to be subscribed to it and you'd have to deal with all that Well, you have to be subscribed to it if you want to track it you're subscribed That's the same thing is saying you're subscribed to it, right? Yeah, but then you also have to have been subscribed at the beginning and It doesn't handle you can joining and leaving a bug particularly elegantly. So you can sync You know mail mail orders or well Yeah, so so now you're back to the case where you have the same problem where before you were actually Subscribing to the bug using mailing list But if you wanted if you just wanted to if you wanted to subscribe to a bug that you were not previously subscribed to the first State would just be to sync the inbox and then and then and or sync the inbox I will tell you subscribe to the list for that bug and then you would have the past state of the bug And then you would be receiving the new states Yeah, and so that would be one implementation and my Idea anyways that that just syncing repeatedly would be a better way But if somebody I mean implements it so it's easy that you can say hey for bug X you just drop this Proc mail bit in that automatically figures out which bugs you're interested in subscribe to these sets of mailing lists and Magically all the bugs that you care about will be in the right place and it sinks down initially That would at least be an initial or if you didn't want to if you didn't want to receive the mail then I mean then if like for instance if the bugs in the BTS were available as a Inbox that you could just download then that would be similar to what you're talking about. Yeah, Ellen They are so The I mean you can download currently you can download a mailbox for a bug One of the things that's missing though is you can't very easily download mailboxes for a whole fleet of bugs I mean directly in the BTS you can obviously write tools to do that So that's all there. So what about the idea of just turning the upstream bugs into? Milders or whatever that were similar to what the BTS is like and then people could just Synced whatever the all of the mailders that they're interested in yeah, that would solve the sharing part of that problem But I mean then on top of that though you still have the issue of state and tracking that so In addition to having the common sense is one part of this you also need some sort of format to share the state So there's some work. I guess that Helios Helios I've got that right is doing with the RDF format Which is really really complicated. It's hard for me to understand what I was reading it But the idea is that all bug trackers will have This standard metadata that they're exporting so that it'll make things like what Christine is doing with SD Easier, but it'll also enable you assuming that you can store this metadata on disk And it's actually complete with regards to the features that the BTS has for example in Debugs That you could set and see the state and you can also then presumably track the changes in that file in any sort of Virgin tracker you wanted to and see how they've changed over time how you've changed them and then Perhaps turn those chain sets back into whatever appropriate Chain system is needed to be made. I mean, I assume it would be amazing if the BTS For example could handle giving a diff or the new change set that you wanted to apply and Would just apply it the changes between two different RDF schemas for example or something like that I don't know if RDF is the right format for this to be in but It's at least one that people are sort of playing with now So to extend the analogy you could when if the system that's turning the upstream bug tracker into males Could turn the state into something similar to what the controls control states, right? Right, so one way that the BTS does this currently is if there's a one of the options for the mailboxes is a Let me pull that up for you just second So hopefully this is working. So one of the options right now is this thing called a status inbox and literally in the first message It contains a thing that looks like a control command So let's see if I can assuming it's still working. It doesn't seem to be working anyway, but if it was working properly it has as the first message a The current status of the bug with the thing that looks like a control mail so you can could Literally just make an edit to that control mail and send the whole thing back to BTS if you wanted to the Debugs now currently Knows to ignore control options that are no options. So if your control option doesn't change anything it just ignores it So it does currently support that to at least some degree So that would be one idea of a way of embedding the chainset and a way to Share it back. So are there any other things that I'm missing or? Things that would be good to discuss or problems that you guys have specifically with when you're working offline I mean, I think if we can first for starters share the state. I think that's the most critical thing Then if we can share the comments, that's the second most critical thing Then if we can replay the state I think that may be most critical thing number three, and then if we can sanely merge and Or replay comments that you've made that would be most critical thing number four I think if we can do three and four Which is sort of I get I agree kind of pie in the sky, but we sort of solve this problem of Working in on the same issue using different bug trackers because they work better for you But in a distributed fashion so you can be offline online doesn't matter working in your own little web space And I think the more standardized Hopefully if we can get this standardized between at least more of the big players. So if Debian can do it if launchpad does it if bugzilla does it for example any of the bugzillas do it If SD is able to do it Then I think we may have enough of Enough momentum at that point that all of the other bug trackers will say yes Shrack will do it then because okay everybody else is doing this and we'll have enough Momentum to then to then make it happen So other than the Okay, so I have another question or comment that I think we are Discussing two things that are related but also a bit different one is working offline and the other one is merging or Relating bugs between different bug trackers and for the second thing I'm asking myself Do we really want to just treat the same the bug about the same issue in the upstream back tracker and in the Distribution back tracker as one and the same bug or should there be somehow the Different that you can see that's what upstream is doing on the buck And that's what Debian is doing on the buck because there may be a combination of a packaging issue And an upstream issue in the same buck or something like this Yeah, that's a good point So I don't yet know and have a good idea how to differentiate between the case where it's purely an upstream bug That also happens to be tracked in Debian and the case where it's a combination So or or as sometimes often happens, it's a bug that may be upstream, but it is solved One way in Debian in one way. I mean it could be solved in Debian by one way or possibly upstream stone Don't our comments, right? so The I admittedly have somewhat of a weird perspective on this because of the number of packages for which I'm both in both Debian maintainer and upstream but To me that's an instance of the general case of why I want a bug tracking system integrated with the VCS because to meet them from my perspective the package in Debian is a branch of upstream and If the bug is fixed in Debian one way in an upstream a different way Then you have a bug fixed two different ways on two different branches, which is a problem that I may also have an upstream Entirely in isolation of Debian. So it what I really wanted to be able to synchronize those bugs In such a way that when I merge a new upstream release, I merge the bug state From upstream into into Debian Because by and large the bugs bug states should be following the code and if there are weird cases Then I can always change that after the fact and this actually brings up a secondary issue that I sort of thought about as well Is how to relate Particular bugs and their state back to versions in a distributed bug tracking system Like how did to connect it back to what's going on and get because clearly you want to know that this bug was fixed in such-and-such a git commit and then it is fixed presumably in all descendants that also include that commit and not fixed in anything before that so I mean this sort of issue of tracking and how do you know that? Yeah, and how do you know in which cases the bug was fixed where and also just even the history and the patch stack that you're operating with Yeah, and for super special bonus points the harder part the harder problem But the really cool idea would be is if you could cherry-pick the fixing commit and have that also cherry-pick the bug state Which is a harder problem because it breaks your because it get then doesn't have a clear line of development But would be neat. Yeah, exactly Yeah, I mean, and I think one of these issues is one of the things that I would love to be able to do in Debugs is to relate particular commits to a particular bug and Also particular commits to a particular version In Debian so that I know okay. Yeah, this is I mean so you can instead of just having the way version tracking works Now where you have this version is a descendant to the one before you also have this commit or the state of your Repository is a descendant of the one below But sort of weird is that the way you would do that is different in every single version tracking Well, not totally different, but in a lot of version tracking systems. It's different And so that's something that needs to be thought about Yeah, if you if I recall correctly last year in Gassar's you presented something like an offline mode for Debugs. Are you still working on this? So it's actually in the archive. It's called Debugs the package name is Debugs dash local and the Command is local Debugs So the command name. Yeah, and so it exists. It's basically an exact copy of BTS Running on your local system for bugs that you care about so it only downloads the bugs that presumably you care about like bugs You maintain bugs you emailed or corresponded with bugs You submitted which is obviously a subset of bugs you've corresponded with And RC bugs but a fault and you can of course expand that by adding arbitrary bug lists arbitrary packages anything that you care about And so but that's really just for Debian and it only really It's kind of clunky and slow and it looks exactly like a BTS So you basically get the web interface to BTS on your machine It does synchronize your changes local changes up to the BTS So yes, because that works by you sending a mail So it doesn't have to do anything to do the synchronous Yeah, but the problem with it as it exists right now is it doesn't make Chain those changes that you've sent out in a mail to your local copy So you have to queue up your copies your changes then wait for them to round trip Which is obviously not optimal Yeah So I mean some way to make it have it make local changes and then overwrite those changes after they've gone in that would be really awesome and Yeah, I don't know if I'm going to be able to do that any time in the next couple years So but if somebody thinks that's really cool that would be brilliant. I would love to accept the patch that did that So is anyone using it here? I think it just got in a usable state just recently because I've been lazy and If you're installing a package make sure you're installing the Experimental one version not the experimental zero version. They both can be made to work, but it's more difficult with the experimental zero version Hopefully it's processed through the mirrors Okay, well, I uploaded the one and it got accepted. I should probably check and see why it hasn't been pushed out Cool, and it's it's working For certain values of work Anybody else? Okay, so it's sort of gotten at some of the things that I was concerned and interested in talking about Is there anything in this area that we think we've missed that I should be wherever? you know so I really like the idea of of Distributing the bug states via the package manager. I think that's kind of cool But as you said one thing I didn't think about was the Incorporating your changes right away But if you if you could get the upstream bugs Into packages in a similar way that DebBug's local is that covers a lot of the space that you were describing It seems to me Yeah, yeah, so I mean and I think with some of the work that's being done at that with SD That that may be that something that can be done I just honestly a part of the purpose of me standing up here and Trying to organize this was so that I could learn about what the state was everything without spending the time to go out and track down What everybody's been doing? I'm very very lazy so Totally hogging the microphone So I was gonna comment on the when when Me and people I had worked with before I had looked at distributed bug trackers one of the things that we Came away with was that The the UI is totally non-intuitive and weird for people who are not developers and And So that's why we avoid that's sort of why we had decided for various reasons to avoid using those Integrated things even though we I think as developers we would really like to do that But you know for our users that are not developers Submitting a bug via a commit to a git repository is just not is completely impossible So getting back to your question about having tried those integrated things, right? Okay, so yes, so that is something honestly that I hadn't thought about but quite seems to be I mean I would like to not have to worry about users In that regard I assume too in a lot of those cases what happens is people send a Message to the mailing list or something and then people actually just commit it themselves, right? But that doesn't allow them to easily track the state and stuff like that I mean to some extent though providing a Getting converting a user input into a commit to a git repository is something that Joey has done an icky-wicky I mean you can do that. It's the fact that it's a get commit under the hook doesn't mean that you can't put a UI Yes, that's true But none none of the none of the projects that we had looked at had anything like that So yeah, we could have Bolted something on to the top. Yeah, I think that's an immaturity problem in the field as opposed to a problem We're a basic underlying architecture. Yeah, I agree. I agree Anything else that I'm missing? obviously, there's Joey's been running a Distributed bugs mailing list where some of these issues have been discussed a little bit. It's not as active I think is either of us would like So but any of you are interested in this that would be one place to Sign up. I know everybody who's also interested in this should go to Christine's talk later So you can hear more about that. Are there any final questions or comments or anything before I? put this away and Go and get some more water. Maybe I should be drinking instead of talking Okay, well, thank you all for waking up very early in the morning and actually tracking down where we were after This talk it bounced around from all possible positions from being scheduled at the same time that I was talking to the same time That Joey was talking to now, so thank you all for coming and Talking and cluing me into some of the things that are going on in distributed bug tracking