WEBVTT 00:00:05.351 --> 00:00:06.936 I'm Solveig. 00:00:07.961 --> 00:00:10.115 Here you have my contact info. 00:00:12.555 --> 00:00:18.888 I use Free Software and especially Debian since quite some time now 00:00:19.130 --> 00:00:22.095 and I also contribute to Tails 00:00:22.502 --> 00:00:28.640 so my interests are in privacy… 00:00:44.255 --> 00:00:47.336 No? Yes? Do you hear me? 00:00:53.360 --> 00:00:56.690 I do some non-developer things 00:00:56.690 --> 00:01:03.401 and in Debian I found a way to contribute without coding 00:01:03.881 --> 00:01:07.147 or maintaining packages which is to triage bugs. 00:01:11.703 --> 00:01:14.582 Bug triaging, it helps, 00:01:15.484 --> 00:01:21.999 it's kind of non visible but it helps Debian as a whole 00:01:22.195 --> 00:01:26.907 because maintainers don't always have the time to deal 00:01:26.907 --> 00:01:28.371 with all their bug reports, 00:01:28.614 --> 00:01:31.499 some packages have a lot of bug reports, 00:01:31.824 --> 00:01:35.968 like the kernel or Xorg. 00:01:39.700 --> 00:01:44.822 Also, it's a good way to improve the package quality. 00:01:45.147 --> 00:01:50.306 When some packages have a lot of bugs open against them, 00:01:51.974 --> 00:01:57.051 it can make it harder for the maintainers to know which ones are 00:01:57.051 --> 00:02:03.136 solvable, actionable, and they can get a bit over their head. 00:02:04.483 --> 00:02:10.541 So when you triage bugs, you help everybody have a better experience 00:02:10.541 --> 00:02:11.839 with Debian. 00:02:13.584 --> 00:02:15.694 So, you want to do it. 00:02:17.406 --> 00:02:18.856 First, it's easy. 00:02:19.028 --> 00:02:22.966 You don't need to learn any new tool supposing you already know 00:02:22.966 --> 00:02:25.320 how to read and write e-mail. 00:02:26.552 --> 00:02:32.029 So that's a low threshold to start. 00:02:33.288 --> 00:02:38.290 It's very rewarding, the maintainers are happy when you help them, 00:02:38.290 --> 00:02:41.450 even if you don't touch their packages, 00:02:41.450 --> 00:02:49.433 if you sort their bugs, they'll be happy and the users who submitted them 00:02:49.433 --> 00:02:51.382 will be happy that somebody looked at them 00:02:51.993 --> 00:02:55.613 so it can be very joyful. 00:02:57.526 --> 00:03:03.451 Also, you search random bugs for packages you don't necessarily know, 00:03:04.181 --> 00:03:07.793 so you learn about a lot of software in Debian and 00:03:07.793 --> 00:03:12.069 some of them are really really surprising and you… 00:03:12.759 --> 00:03:16.457 "Wha? What does this do?" and that's kind of fun. 00:03:17.836 --> 00:03:19.868 And of course, it saves kittens. 00:03:25.747 --> 00:03:29.244 On this page, there's a… 00:03:30.710 --> 00:03:36.154 The bug triage page is a howto page I made some years ago, with tips 00:03:36.968 --> 00:03:43.148 and this part, especially, has a list of teams that added themselves 00:03:43.148 --> 00:03:47.170 so that they want you to help sort their bugs. 00:03:48.873 --> 00:03:51.956 Those are the teams I worked with, they're really really nice, 00:03:52.884 --> 00:03:54.270 they don't bite. 00:03:56.546 --> 00:03:59.031 They will let you know if you did an error, 00:03:59.031 --> 00:04:02.603 they will answer your questions, you can work together. 00:04:04.831 --> 00:04:07.763 I don't recommend closing random bugs. 00:04:08.164 --> 00:04:12.840 If you go and touch packages from people you have not warned 00:04:12.840 --> 00:04:17.077 or who are not willing to have somebody touch their bugs, 00:04:17.077 --> 00:04:20.445 you might have backfire. 00:04:22.517 --> 00:04:28.290 To start, I think it's good to go packages that you know people are happy 00:04:28.290 --> 00:04:29.419 if you help with. 00:04:35.230 --> 00:04:38.479 The first tool to triage bugs is UDD. 00:04:39.660 --> 00:04:47.294 I don't know if you've ever tried it, the interface is really great. 00:04:55.801 --> 00:04:57.777 Here, I can show you. 00:05:02.151 --> 00:05:04.112 Here, that's UDD. 00:05:06.546 --> 00:05:08.504 So it's a bit arid like this, but 00:05:13.561 --> 00:05:21.687 it allows you to select many many types of packages, 00:05:23.107 --> 00:05:25.667 we can see that later. 00:05:26.114 --> 00:05:31.595 Then you can choose a team or other criteria 00:05:32.694 --> 00:05:38.021 and when you're happy about your criteria, you search. 00:05:39.403 --> 00:05:45.049 It will give you a list of packages corresponding to your criteria 00:05:46.556 --> 00:05:51.306 and you can select some more info you want listed here. 00:05:53.718 --> 00:05:55.628 So, that's UDD search. 00:06:02.455 --> 00:06:08.505 I usually ignore the bug reports that somebody has searched in the last year. 00:06:11.874 --> 00:06:14.147 Probably somebody else will look at them, 00:06:14.147 --> 00:06:18.005 let's look at those that are lost in the limbos. 00:06:19.225 --> 00:06:23.694 I select wontfix, moreinfo, upstream or unreproducible. 00:06:23.978 --> 00:06:27.593 Those are those that probably you can do something on. 00:06:29.708 --> 00:06:33.774 And then you chose a team, preferably one of those that is listed 00:06:33.774 --> 00:06:35.890 in the page we saw before. 00:06:45.329 --> 00:06:50.247 Once you'll have selected a bug and something to do on it, 00:06:50.247 --> 00:06:52.523 you'll have to document what you do. 00:06:57.072 --> 00:07:00.399 Because you can change many many stuff on the bug, 00:07:00.399 --> 00:07:07.108 you send the commands to control@bugs.debian.org 00:07:07.352 --> 00:07:12.433 but it's always nice to put a small a small sentence, or 2 or 3 00:07:12.433 --> 00:07:17.547 to say what made you conclude that is the right change. 00:07:21.935 --> 00:07:26.161 Also make sure the e-mail where you do the commands is sent 00:07:26.161 --> 00:07:31.811 to everybody interested, because by default it only sends it 00:07:31.811 --> 00:07:35.995 to the maintainer and the submitter in some cases. 00:07:36.889 --> 00:07:39.897 So if other people answered the bug report saying 00:07:39.897 --> 00:07:47.612 "Hey, I have the bug too" or if upstream came by to explain something, 00:07:47.612 --> 00:07:52.811 it's good to see all of those who interacted on the bug report and 00:07:52.811 --> 00:07:55.448 put them all in copy. 00:08:01.225 --> 00:08:08.050 Ideally, people can receive the e-mail, read what you're saying and 00:08:08.050 --> 00:08:11.788 don't have to go back to the bug page to read it again. 00:08:12.716 --> 00:08:19.958 So that you should sum up the thread if it was long and have them know everything. 00:08:28.821 --> 00:08:35.239 If you do massive triage, you should have a few generic messages 00:08:35.239 --> 00:08:40.605 so you keep the messages and just replace the words as needed. 00:08:41.454 --> 00:08:43.531 It saves you a lot of time. 00:08:44.827 --> 00:08:50.519 Also, it allows you to put a lot of nice things in your generic e-mail 00:08:50.519 --> 00:08:53.724 that people are always happy to read without more effort. 00:08:54.608 --> 00:08:58.237 You know, add a little "Thanks for submitting the bug" or 00:08:58.237 --> 00:09:04.339 "That was a very interesting discussion" or something like that. 00:09:06.084 --> 00:09:10.153 Let's keep the positive energy flowing. 00:09:13.001 --> 00:09:17.838 There are many ways to triage. 00:09:18.366 --> 00:09:21.417 One of them is trying to reproduce bug reports. 00:09:22.065 --> 00:09:26.169 In the UDD we saw earlier, if you select 'unreproducible' 00:09:26.453 --> 00:09:30.113 Oh no… those that don't have the tag 'confirmed', 00:09:30.878 --> 00:09:36.526 these are bugs that one person submitted but nobody knows if they're really 00:09:36.526 --> 00:09:42.217 still up to date or if it's just, somebody submitted it but… 00:09:43.755 --> 00:09:48.158 If it's confirmed, there's more chance that the maintainer will look at them. 00:09:50.344 --> 00:09:54.092 If they're really old, maybe they have been corrected and nobody bothered 00:09:54.092 --> 00:09:55.434 to close the bug. 00:09:57.181 --> 00:10:03.233 If they're new, maybe you should have them too, so see if it's the case. 00:10:04.252 --> 00:10:06.973 If it's the case, you write to this adress 00:10:06.973 --> 00:10:15.755 the 'nnn' is the number of the bug and you add the tag 'confirmed' 00:10:17.455 --> 00:10:22.550 That's how we interact with control@b.d.o 00:10:23.883 --> 00:10:29.825 All the bug tracking is on a e-mail interface 00:10:31.247 --> 00:10:33.764 'found bugnumber versionnumber' 00:10:36.164 --> 00:10:40.102 that's a command that control will recognize, 00:10:40.386 --> 00:10:43.226 you give the bug number and what version you're running. 00:10:44.361 --> 00:10:47.696 You add the tag 'confirmed'. 00:10:48.267 --> 00:10:50.666 Since you found it, you're 2, so it's confirmed. 00:10:51.073 --> 00:10:56.391 And 'thanks', you always have to end your e-mails to control with 'thanks' 00:10:56.391 --> 00:10:59.810 or 'thank you' or whatever variation of it you want. 00:11:00.782 --> 00:11:06.233 The control is a very very polite beast and likes you to be the same. 00:11:07.861 --> 00:11:11.928 If you don't put politeness, it won't work. 00:11:13.383 --> 00:11:16.803 Actually it's to tell them that the commands are done, but 00:11:16.803 --> 00:11:19.969 let's be polite also with machines. 00:11:26.598 --> 00:11:35.176 If the bug was not confirmed, you tried to reproduce it and you couldn't. 00:11:37.450 --> 00:11:44.280 You could add the tag 'unreproducible' or 'moreinfo' 00:11:44.598 --> 00:11:49.891 So, depending if you're quite sure that… if you're not the first saying 00:11:49.891 --> 00:11:54.743 "I can't reproduce it" or if you're sure you have exactly the same setup as 00:11:54.743 --> 00:11:56.091 the original submitter, 00:11:56.091 --> 00:11:58.556 then you should put 'unreproducible'. 00:11:59.624 --> 00:12:05.230 If it might be reproducible for other people, but just not you, 00:12:05.230 --> 00:12:10.754 then you should ask 'moreinfo' so that the original submitter gives 00:12:10.754 --> 00:12:12.989 more details on how to reproduce their bug 00:12:15.111 --> 00:12:19.339 And it also requires you to be polite at the end of the command. 00:12:22.634 --> 00:12:25.597 An other very useful thing is to forward them upstream. 00:12:26.369 --> 00:12:30.922 Some upstream follow the Debian bug tracker 00:12:30.922 --> 00:12:32.971 but a lot of them don't. 00:12:35.762 --> 00:12:39.099 Maybe somebody reported the issue in the Debian bug tracker but 00:12:39.099 --> 00:12:40.764 upstream is not aware of it 00:12:41.410 --> 00:12:47.311 and most Debian maintainers are not gonna solve the bug themselves, 00:12:47.595 --> 00:12:50.847 they're more probably gonna wait for it to be corrected upstream, 00:12:50.847 --> 00:12:54.513 so we need the bug to go back to where it will be corrected 00:13:00.853 --> 00:13:07.448 In a lot of cases, it can be because upstream considers it not a bug, 00:13:07.855 --> 00:13:11.135 so won't fix it, so let's say it on the Debian bug too 00:13:14.516 --> 00:13:18.856 or maybe upstream is not aware of the bug so… 00:13:22.935 --> 00:13:27.318 Ok, that's very tiny… 00:13:30.486 --> 00:13:32.109 At least you have all. 00:13:33.491 --> 00:13:38.534 Here you have the command to add the upstream bug tracker number. 00:13:38.901 --> 00:13:43.742 "forwarded bugnumber", you put the URL in the upstream's bug tracker 00:13:45.327 --> 00:13:47.763 and then you say thanks again. 00:13:59.939 --> 00:14:06.579 So that's what I was saying before, you can also report it upstream 00:14:06.783 --> 00:14:09.019 if it hasn't been already. 00:14:14.506 --> 00:14:17.760 Sometimes, the upstream bug tracker is more up to date, 00:14:18.452 --> 00:14:23.327 so in upstream it's fixed, so it's good to let know to the Debian bug tracker 00:14:24.142 --> 00:14:27.106 and add the tag 'fixedupstream' 00:14:28.164 --> 00:14:35.521 and it's good to say in which version so that the maintainer may be 00:14:35.521 --> 00:14:39.053 motivated to update to the new version. 00:14:52.641 --> 00:14:58.090 In lot of cases, the bug reports are tagged 'moreinfo', which is 00:14:58.090 --> 00:15:04.884 somebody said "It doesn't work", which, sorry for you, but there's no chance 00:15:04.884 --> 00:15:07.201 it's gonna be fixed with that. 00:15:08.096 --> 00:15:12.727 So in lots of cases, the bug is tagged 'moreinfo' to say 00:15:12.727 --> 00:15:16.670 "This bug does not give enough info to be solved" 00:15:19.796 --> 00:15:23.624 Or sometimes, the maintainer packages a new version 00:15:23.624 --> 00:15:26.842 and you think probably the bug is solved, 00:15:27.573 --> 00:15:31.601 and you also need to ask the original submitter if they still have the bug 00:15:33.347 --> 00:15:38.833 Or somebody said "Oh I'm gonna do some test next weekend" and it's 2 years later 00:15:39.819 --> 00:15:44.006 and you're not sure they actually did the test they were saying they would do. 00:15:45.792 --> 00:15:52.042 So, info were asked and it feels like the bug is hanging. 00:15:55.620 --> 00:16:03.945 In those cases, it's helpful, sometimes, to send an e-mail to the person who said 00:16:03.945 --> 00:16:09.586 "I'm gonna do something" or who needs to answer if they still have the bug 00:16:11.091 --> 00:16:15.683 and saying "Hey! that's a gentle ping" 00:16:16.617 --> 00:16:19.544 "You said you would test" or "Can you still reproduce a bug?" 00:16:20.842 --> 00:16:24.866 so that you can update the status of the bug on the bug tracker. 00:16:34.129 --> 00:16:41.375 It's good to wait, like, a good amount of time before bothering people 00:16:41.731 --> 00:16:43.163 about this kind of thing. 00:16:43.852 --> 00:16:48.400 I usually wait one year, like I told you, probably shorter might be good, 00:16:48.684 --> 00:16:53.973 but it's good also not to harass people, they have a life. 00:16:58.237 --> 00:17:03.969 Sometimes, the bugs have been tagged 'moreinfo' or 'wontfix' for a long time 00:17:07.673 --> 00:17:17.416 The info is not given, or it's unlikely that somebody else wants 00:17:17.416 --> 00:17:19.938 this 'non-bug' fixed. 00:17:23.267 --> 00:17:26.843 Different teams have different policies but most of them will be happy 00:17:26.843 --> 00:17:30.826 if you close the bugs that nobody is gonna do anything about. 00:17:33.223 --> 00:17:38.669 If the bug was tagged 'moreinfo' more than a year ago and 00:17:38.669 --> 00:17:43.686 nobody answered to give more info, or if a major release came out and 00:17:43.686 --> 00:17:48.889 probably the bug is fixed but the original submitter doesn't answer 00:17:48.889 --> 00:17:54.743 then it's good to close them, in most cases, depending on the team. 00:17:56.603 --> 00:17:58.609 But it's good to ping them before you close 00:17:58.770 --> 00:18:03.967 give them a reasonable amount of time to try to test it again. 00:18:12.614 --> 00:18:14.523 Ok, we don't have the bottom of the page. 00:18:16.345 --> 00:18:18.431 The command to… 00:18:25.547 --> 00:18:36.115 The command to close a bug is to write to -done@control.b.d.o 00:18:38.788 --> 00:18:41.017 Maybe I shouldn't have done that. 00:18:47.085 --> 00:18:54.935 And closing the bugs is kind of one of the most satisfying things to do. 00:18:59.120 --> 00:19:04.729 Sometimes, I speak with my maintainer friends and I say 00:19:04.729 --> 00:19:08.393 "Hey, I closed 25 bugs today" and they're kind of jealous because 00:19:08.466 --> 00:19:11.798 when you have to actually work on the bugs to close them, 00:19:11.798 --> 00:19:14.628 you can rarely fix 25 in one day. 00:19:15.572 --> 00:19:18.873 So it's kind of the perks of doing bug triaging. 00:19:19.523 --> 00:19:26.558 You know, "less bugs on the bug tracker, I'm very efficient today." 00:19:28.229 --> 00:19:32.416 But don't close random stuff, but when you find useless stuff to close, 00:19:32.416 --> 00:19:33.962 it feels good. 00:19:44.084 --> 00:19:44.935 Where am I? 00:19:57.127 --> 00:20:00.340 We missed the last sentence earlier. 00:20:01.318 --> 00:20:06.477 When trying to reproduce a bug, you should pay particularly attention to 00:20:06.477 --> 00:20:07.939 the games team. 00:20:08.297 --> 00:20:14.440 You know, like, people open bug reports against the game team and then 00:20:14.440 --> 00:20:19.599 Oh no, you have to install a bunch of games to try to reproduce bugs, 00:20:20.166 --> 00:20:26.058 you know, but for work, so you install a lot of games and 00:20:26.058 --> 00:20:32.475 you try to see if they're buggy, so that's also another perk of triaging bugs, 00:20:32.719 --> 00:20:36.784 you get to try all the latest games. 00:20:40.476 --> 00:20:44.866 An other thing is when people open a bug and didn't check if there was 00:20:44.866 --> 00:20:46.047 already one open. 00:20:46.893 --> 00:20:51.824 It ends up being 2 reports for the same bug. 00:20:52.765 --> 00:20:59.635 It's good to merge them so that's clearer. 00:21:01.138 --> 00:21:04.915 The 2 bug reports must be on the same package, with the same severity 00:21:04.915 --> 00:21:06.417 and the same state, 00:21:07.106 --> 00:21:11.126 otherwise you can't merge, so you have to send first the commands to do that, 00:21:11.411 --> 00:21:17.388 like I showed before, and at the end you tell the bug tracker to merge. 00:21:23.680 --> 00:21:25.792 So, that we've seen. 00:21:39.649 --> 00:21:41.068 You can… 00:21:51.844 --> 00:21:55.508 Ok, you can't really see the… 00:21:57.413 --> 00:22:05.064 So, I was giving an example of my standard message I paste when I close a bug 00:22:06.004 --> 00:22:09.300 and we don't see the end, but I'm gonna do it from memory, it says 00:22:09.300 --> 00:22:14.380 "Hi! I'm closing this bug, since it was tagged 'moreinfo' for years 00:22:14.380 --> 00:22:20.397 without answer. If you still experience the issue, please feel free to reopen it 00:22:20.397 --> 00:22:24.003 or ask me to do it" because some people don't know how to reopen a bug 00:22:24.213 --> 00:22:25.839 that has been archived. 00:22:28.600 --> 00:22:33.148 So that's a very standard message, no nothing, it's not very long. 00:22:34.092 --> 00:22:42.630 That is good to have a model so that you can just paste, with niceness in it. 00:22:45.344 --> 00:22:47.305 If you're not sure about a bug report, 00:22:47.305 --> 00:22:51.125 you read through it and you're still not sure what to do 00:22:51.360 --> 00:22:54.864 because, let's be clear, I don't always understand what the issue is. 00:22:55.392 --> 00:22:59.005 What you need to understand to triage is what the status of the bug report is. 00:23:00.508 --> 00:23:02.092 I triaged bugs for the kernel. 00:23:03.637 --> 00:23:07.621 I don't understand anything about the kernel, like most human beings 00:23:07.621 --> 00:23:13.424 but, without understanding the bug report, you can understand if somebody asks 00:23:13.424 --> 00:23:15.219 for info and nobody provided it 00:23:15.708 --> 00:23:22.316 or, for example, for the kernel, all the bug reports that were for the nouveau driver 00:23:22.316 --> 00:23:23.668 that is not supported anymore, 00:23:24.074 --> 00:23:28.668 it was possible to close them because nobody cared anymore. 00:23:30.092 --> 00:23:33.223 So you don't necessarily need to understand what the bug is about 00:23:33.223 --> 00:23:35.339 to do something about the bug report 00:23:37.086 --> 00:23:41.303 but sometimes it's a bit more complicated, you're not sure 00:23:41.303 --> 00:23:44.746 just close the bug report, move to the next one 00:23:45.202 --> 00:23:50.439 There's probably an other one that's, you know, low hanging 00:23:50.439 --> 00:23:52.266 take the easy stuff. 00:23:54.136 --> 00:23:59.709 Because if you do something wrong, or if you bother the maintainer to ask 00:23:59.709 --> 00:24:03.371 what should be done, then you're not really helping, 00:24:03.696 --> 00:24:08.326 you might be taking time from them that would be best invested somewhere else. 00:24:12.805 --> 00:24:16.681 Small warning, there are some people who really don't like you touching 00:24:16.926 --> 00:24:18.186 their bug reports. 00:24:19.930 --> 00:24:23.786 I wish you not to encounter them. 00:24:24.275 --> 00:24:33.094 I you do, just either ignore them or ask the maintainers of the package you're triaging 00:24:33.379 --> 00:24:38.539 to step in and help or you can also contact the anti-harassment team. 00:24:40.124 --> 00:24:46.508 But it's very rare and most of Debian people are very nice people 00:24:47.726 --> 00:24:51.549 and they'll be happy to cooperate and discuss with you 00:24:51.994 --> 00:24:57.854 and bug triaging is fun and rewarding and easy. 00:25:01.061 --> 00:25:05.704 Those are the links to the things that are useful to triage. 00:25:06.151 --> 00:25:07.896 The first one is… 00:25:18.951 --> 00:25:22.000 Ok, the first one is bad, I'll correct it. 00:25:24.843 --> 00:25:30.450 The second one is how to triage with all the different commands 00:25:30.450 --> 00:25:32.358 that are useful. 00:25:32.967 --> 00:25:36.908 The third one is server control, 00:25:40.801 --> 00:25:44.502 a reminder of all the different instructions you can send to server control 00:25:44.706 --> 00:25:48.044 which is the way to interact with a bug report. 00:25:48.644 --> 00:25:55.626 The last one is about only closing and you don't interact with control, 00:25:55.960 --> 00:26:01.694 you write to bugnumber-done, so that's a different e-mail destination. 00:26:07.190 --> 00:26:14.059 So, the idea was to have a workshop, so this was the explanation part and now 00:26:14.059 --> 00:26:18.939 let's close some bugs, or sort them, maybe.