1
00:00:05,351 --> 00:00:06,936
I'm Solveig.

2
00:00:07,961 --> 00:00:10,115
Here you have my contact info.

3
00:00:12,555 --> 00:00:18,888
I use Free Software and especially Debian
since quite some time now

4
00:00:19,130 --> 00:00:22,095
and I also contribute to Tails

5
00:00:22,502 --> 00:00:28,640
so my interests are in privacy…

6
00:00:44,255 --> 00:00:47,336
No? Yes? Do you hear me?

7
00:00:53,360 --> 00:00:56,690
I do some non-developer things

8
00:00:56,690 --> 00:01:03,401
and in Debian I found a way to contribute
without coding

9
00:01:03,881 --> 00:01:07,147
or maintaining packages which is to
triage bugs.

10
00:01:11,703 --> 00:01:14,582
Bug triaging, it helps,

11
00:01:15,484 --> 00:01:21,999
it's kind of non visible but it helps
Debian as a whole

12
00:01:22,195 --> 00:01:26,907
because maintainers don't always
have the time to deal

13
00:01:26,907 --> 00:01:28,371
with all their bug reports,

14
00:01:28,614 --> 00:01:31,499
some packages have a lot of
bug reports,

15
00:01:31,824 --> 00:01:35,968
like the kernel or Xorg.

16
00:01:39,700 --> 00:01:44,822
Also, it's a good way to improve the
package quality.

17
00:01:45,147 --> 00:01:50,306
When some packages have a lot of
bugs open against them,

18
00:01:51,974 --> 00:01:57,051
it can make it harder for the maintainers
to know which ones are

19
00:01:57,051 --> 00:02:03,136
solvable, actionable, and they can get a bit
over their head.

20
00:02:04,483 --> 00:02:10,541
So when you triage bugs, you help
everybody have a better experience

21
00:02:10,541 --> 00:02:11,839
with Debian.

22
00:02:13,584 --> 00:02:15,694
So, you want to do it.

23
00:02:17,406 --> 00:02:18,856
First, it's easy.

24
00:02:19,028 --> 00:02:22,966
You don't need to learn any new tool
supposing you already know

25
00:02:22,966 --> 00:02:25,320
how to read and write e-mail.

26
00:02:26,552 --> 00:02:32,029
So that's a low threshold to start.

27
00:02:33,288 --> 00:02:38,290
It's very rewarding, the maintainers are
happy when you help them,

28
00:02:38,290 --> 00:02:41,450
even if you don't touch their packages,

29
00:02:41,450 --> 00:02:49,433
if you sort their bugs, they'll be happy
and the users who submitted them

30
00:02:49,433 --> 00:02:51,382
will be happy that somebody looked
at them

31
00:02:51,993 --> 00:02:55,613
so it can be very joyful.

32
00:02:57,526 --> 00:03:03,451
Also, you search random bugs for packages
you don't necessarily know,

33
00:03:04,181 --> 00:03:07,793
so you learn about a lot of software
in Debian and

34
00:03:07,793 --> 00:03:12,069
some of them are really really surprising
and you…

35
00:03:12,759 --> 00:03:16,457
"Wha? What does this do?" and that's kind
of fun.

36
00:03:17,836 --> 00:03:19,868
And of course, it saves kittens.

37
00:03:25,747 --> 00:03:29,244
On this page, there's a…

38
00:03:30,710 --> 00:03:36,154
The bug triage page is a howto page
I made some years ago, with tips

39
00:03:36,968 --> 00:03:43,148
and this part, especially, has a list
of teams that added themselves

40
00:03:43,148 --> 00:03:47,170
so that they want you to help
sort their bugs.

41
00:03:48,873 --> 00:03:51,956
Those are the teams I worked with,
they're really really nice,

42
00:03:52,884 --> 00:03:54,270
they don't bite.

43
00:03:56,546 --> 00:03:59,031
They will let you know if you did an error,

44
00:03:59,031 --> 00:04:02,603
they will answer your questions,
you can work together.

45
00:04:04,831 --> 00:04:07,763
I don't recommend closing random bugs.

46
00:04:08,164 --> 00:04:12,840
If you go and touch packages from people
you have not warned

47
00:04:12,840 --> 00:04:17,077
or who are not willing to have somebody
touch their bugs,

48
00:04:17,077 --> 00:04:20,445
you might have backfire.

49
00:04:22,517 --> 00:04:28,290
To start, I think it's good to go packages
that you know people are happy

50
00:04:28,290 --> 00:04:29,419
if you help with.

51
00:04:35,230 --> 00:04:38,479
The first tool to triage bugs is UDD.

52
00:04:39,660 --> 00:04:47,294
I don't know if you've ever tried it,
the interface is really great.

53
00:04:55,801 --> 00:04:57,777
Here, I can show you.

54
00:05:02,151 --> 00:05:04,112
Here, that's UDD.

55
00:05:06,546 --> 00:05:08,504
So it's a bit arid like this, but

56
00:05:13,561 --> 00:05:21,687
it allows you to select many many
types of packages,

57
00:05:23,107 --> 00:05:25,667
we can see that later.

58
00:05:26,114 --> 00:05:31,595
Then you can choose a team or
other criteria

59
00:05:32,694 --> 00:05:38,021
and when you're happy about
your criteria, you search.

60
00:05:39,403 --> 00:05:45,049
It will give you a list of packages
corresponding to your criteria

61
00:05:46,556 --> 00:05:51,306
and you can select some more info
you want listed here.

62
00:05:53,718 --> 00:05:55,628
So, that's UDD search.

63
00:06:02,455 --> 00:06:08,505
I usually ignore the bug reports that
somebody has searched in the last year.

64
00:06:11,874 --> 00:06:14,147
Probably somebody else will look at them,

65
00:06:14,147 --> 00:06:18,005
let's look at those that are lost
in the limbos.

66
00:06:19,225 --> 00:06:23,694
I select wontfix, moreinfo, upstream or
unreproducible.

67
00:06:23,978 --> 00:06:27,593
Those are those that probably you can do
something on.

68
00:06:29,708 --> 00:06:33,774
And then you chose a team, preferably
one of those that is listed

69
00:06:33,774 --> 00:06:35,890
in the page we saw before.

70
00:06:45,329 --> 00:06:50,247
Once you'll have selected a bug and
something to do on it,

71
00:06:50,247 --> 00:06:52,523
you'll have to document what you do.

72
00:06:57,072 --> 00:07:00,399
Because you can change many many stuff
on the bug,

73
00:07:00,399 --> 00:07:07,108
you send the commands to
control@bugs.debian.org

74
00:07:07,352 --> 00:07:12,433
but it's always nice to put a small
a small sentence, or 2 or 3

75
00:07:12,433 --> 00:07:17,547
to say what made you conclude that is
the right change.

76
00:07:21,935 --> 00:07:26,161
Also make sure the e-mail where you do
the commands is sent

77
00:07:26,161 --> 00:07:31,811
to everybody interested, because
by default it only sends it

78
00:07:31,811 --> 00:07:35,995
to the maintainer and the submitter
in some cases.

79
00:07:36,889 --> 00:07:39,897
So if other people answered the bug
report saying

80
00:07:39,897 --> 00:07:47,612
"Hey, I have the bug too" or if upstream
came by to explain something,

81
00:07:47,612 --> 00:07:52,811
it's good to see all of those who
interacted on the bug report and

82
00:07:52,811 --> 00:07:55,448
put them all in copy.

83
00:08:01,225 --> 00:08:08,050
Ideally, people can receive the e-mail,
read what you're saying and

84
00:08:08,050 --> 00:08:11,788
don't have to go back to the bug page
to read it again.

85
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.

86
00:08:28,821 --> 00:08:35,239
If you do massive triage, you should have
a few generic messages

87
00:08:35,239 --> 00:08:40,605
so you keep the messages and just
replace the words as needed.

88
00:08:41,454 --> 00:08:43,531
It saves you a lot of time.

89
00:08:44,827 --> 00:08:50,519
Also, it allows you to put a lot of
nice things in your generic e-mail

90
00:08:50,519 --> 00:08:53,724
that people are always happy to read
without more effort.

91
00:08:54,608 --> 00:08:58,237
You know, add a little "Thanks for
submitting the bug" or

92
00:08:58,237 --> 00:09:04,339
"That was a very interesting discussion"
or something like that.

93
00:09:06,084 --> 00:09:10,153
Let's keep the positive energy flowing.

94
00:09:13,001 --> 00:09:17,838
There are many ways to triage.

95
00:09:18,366 --> 00:09:21,417
One of them is trying to reproduce
bug reports.

96
00:09:22,065 --> 00:09:26,169
In the UDD we saw earlier, if you select
'unreproducible'

97
00:09:26,453 --> 00:09:30,113
Oh no… those that don't have the tag
'confirmed',

98
00:09:30,878 --> 00:09:36,526
these are bugs that one person submitted
but nobody knows if they're really

99
00:09:36,526 --> 00:09:42,217
still up to date or if it's just, somebody
submitted it but…

100
00:09:43,755 --> 00:09:48,158
If it's confirmed, there's more chance
that the maintainer will look at them.

101
00:09:50,344 --> 00:09:54,092
If they're really old, maybe they have been
corrected and nobody bothered

102
00:09:54,092 --> 00:09:55,434
to close the bug.

103
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.

104
00:10:04,252 --> 00:10:06,973
If it's the case, you write to this adress

105
00:10:06,973 --> 00:10:15,755
the 'nnn' is the number of the bug and
you add the tag 'confirmed'

106
00:10:17,455 --> 00:10:22,550
That's how we interact with control@b.d.o

107
00:10:23,883 --> 00:10:29,825
All the bug tracking is on a e-mail
interface

108
00:10:31,247 --> 00:10:33,764
'found bugnumber versionnumber'

109
00:10:36,164 --> 00:10:40,102
that's a command that control will
recognize,

110
00:10:40,386 --> 00:10:43,226
you give the bug number and what version
you're running.

111
00:10:44,361 --> 00:10:47,696
You add the tag 'confirmed'.

112
00:10:48,267 --> 00:10:50,666
Since you found it, you're 2, so it's
confirmed.

113
00:10:51,073 --> 00:10:56,391
And 'thanks', you always have to end
your e-mails to control with 'thanks'

114
00:10:56,391 --> 00:10:59,810
or 'thank you' or whatever variation
of it you want.

115
00:11:00,782 --> 00:11:06,233
The control is a very very polite beast
and likes you to be the same.

116
00:11:07,861 --> 00:11:11,928
If you don't put politeness, it won't work.

117
00:11:13,383 --> 00:11:16,803
Actually it's to tell them that the commands
are done, but

118
00:11:16,803 --> 00:11:19,969
let's be polite also with machines.

119
00:11:26,598 --> 00:11:35,176
If the bug was not confirmed, you tried
to reproduce it and you couldn't.

120
00:11:37,450 --> 00:11:44,280
You could add the tag 'unreproducible' or
'moreinfo'

121
00:11:44,598 --> 00:11:49,891
So, depending if you're quite sure that…
if you're not the first saying

122
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

123
00:11:54,743 --> 00:11:56,091
the original submitter,

124
00:11:56,091 --> 00:11:58,556
then you should put 'unreproducible'.

125
00:11:59,624 --> 00:12:05,230
If it might be reproducible for other
people, but just not you,

126
00:12:05,230 --> 00:12:10,754
then you should ask 'moreinfo' so that
the original submitter gives

127
00:12:10,754 --> 00:12:12,989
more details on how to reproduce their bug

128
00:12:15,111 --> 00:12:19,339
And it also requires you to be polite
at the end of the command.

129
00:12:22,634 --> 00:12:25,597
An other very useful thing is to forward
them upstream.

130
00:12:26,369 --> 00:12:30,922
Some upstream follow the Debian bug tracker

131
00:12:30,922 --> 00:12:32,971
but a lot of them don't.

132
00:12:35,762 --> 00:12:39,099
Maybe somebody reported the issue in
the Debian bug tracker but

133
00:12:39,099 --> 00:12:40,764
upstream is not aware of it

134
00:12:41,410 --> 00:12:47,311
and most Debian maintainers are not
gonna solve the bug themselves,

135
00:12:47,595 --> 00:12:50,847
they're more probably gonna wait for it
to be corrected upstream,

136
00:12:50,847 --> 00:12:54,513
so we need the bug to go back to where
it will be corrected

137
00:13:00,853 --> 00:13:07,448
In a lot of cases, it can be because
upstream considers it not a bug,

138
00:13:07,855 --> 00:13:11,135
so won't fix it, so let's say it on the
Debian bug too

139
00:13:14,516 --> 00:13:18,856
or maybe upstream is not aware of
the bug so…

140
00:13:22,935 --> 00:13:27,318
Ok, that's very tiny…

141
00:13:30,486 --> 00:13:32,109
At least you have all.

142
00:13:33,491 --> 00:13:38,534
Here you have the command to add
the upstream bug tracker number.

143
00:13:38,901 --> 00:13:43,742
"forwarded bugnumber", you put the URL
in the upstream's bug tracker

144
00:13:45,327 --> 00:13:47,763
and then you say thanks again.

145
00:13:59,939 --> 00:14:06,579
So that's what I was saying before, you
can also report it upstream

146
00:14:06,783 --> 00:14:09,019
if it hasn't been already.

147
00:14:14,506 --> 00:14:17,760
Sometimes, the upstream bug tracker
is more up to date,

148
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

149
00:14:24,142 --> 00:14:27,106
and add the tag 'fixedupstream'

150
00:14:28,164 --> 00:14:35,521
and it's good to say in which version
so that the maintainer may be

151
00:14:35,521 --> 00:14:39,053
motivated to update to the new version.

152
00:14:52,641 --> 00:14:58,090
In lot of cases, the bug reports are tagged
'moreinfo', which is

153
00:14:58,090 --> 00:15:04,884
somebody said "It doesn't work", which,
sorry for you, but there's no chance

154
00:15:04,884 --> 00:15:07,201
it's gonna be fixed with that.

155
00:15:08,096 --> 00:15:12,727
So in lots of cases, the bug is tagged
'moreinfo' to say

156
00:15:12,727 --> 00:15:16,670
"This bug does not give enough info
to be solved"

157
00:15:19,796 --> 00:15:23,624
Or sometimes, the maintainer
packages a new version

158
00:15:23,624 --> 00:15:26,842
and you think probably the bug is
solved,

159
00:15:27,573 --> 00:15:31,601
and you also need to ask the original
submitter if they still have the bug

160
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

161
00:15:39,819 --> 00:15:44,006
and you're not sure they actually did
the test they were saying they would do.

162
00:15:45,792 --> 00:15:52,042
So, info were asked and it feels like
the bug is hanging.

163
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

164
00:16:03,945 --> 00:16:09,586
"I'm gonna do something" or who needs to
answer if they still have the bug

165
00:16:11,091 --> 00:16:15,683
and saying "Hey! that's a gentle ping"

166
00:16:16,617 --> 00:16:19,544
"You said you would test" or "Can you still
reproduce a bug?"

167
00:16:20,842 --> 00:16:24,866
so that you can update the status of the
bug on the bug tracker.

168
00:16:34,129 --> 00:16:41,375
It's good to wait, like, a good amount of
time before bothering people

169
00:16:41,731 --> 00:16:43,163
about this kind of thing.

170
00:16:43,852 --> 00:16:48,400
I usually wait one year, like I told you,
probably shorter might be good,

171
00:16:48,684 --> 00:16:53,973
but it's good also not to harass people,
they have a life.

172
00:16:58,237 --> 00:17:03,969
Sometimes, the bugs have been tagged
'moreinfo' or 'wontfix' for a long time

173
00:17:07,673 --> 00:17:17,416
The info is not given, or it's unlikely
that somebody else wants

174
00:17:17,416 --> 00:17:19,938
this 'non-bug' fixed.

175
00:17:23,267 --> 00:17:26,843
Different teams have different policies
but most of them will be happy

176
00:17:26,843 --> 00:17:30,826
if you close the bugs that nobody is gonna
do anything about.

177
00:17:33,223 --> 00:17:38,669
If the bug was tagged 'moreinfo' more than
a year ago and

178
00:17:38,669 --> 00:17:43,686
nobody answered to give more info, or if
a major release came out and

179
00:17:43,686 --> 00:17:48,889
probably the bug is fixed but the original
submitter doesn't answer

180
00:17:48,889 --> 00:17:54,743
then it's good to close them, in most
cases, depending on the team.

181
00:17:56,603 --> 00:17:58,609
But it's good to ping them before you
close

182
00:17:58,770 --> 00:18:03,967
give them a reasonable amount of time
to try to test it again.

183
00:18:12,614 --> 00:18:14,523
Ok, we don't have the bottom of the page.

184
00:18:16,345 --> 00:18:18,431
The command to…

185
00:18:25,547 --> 00:18:36,115
The command to close a bug is to write to
-done@control.b.d.o

186
00:18:38,788 --> 00:18:41,017
Maybe I shouldn't have done that.

187
00:18:47,085 --> 00:18:54,935
And closing the bugs is kind of one of
the most satisfying things to do.

188
00:18:59,120 --> 00:19:04,729
Sometimes, I speak with my maintainer
friends and I say

189
00:19:04,729 --> 00:19:08,393
"Hey, I closed 25 bugs today" and they're
kind of jealous because

190
00:19:08,466 --> 00:19:11,798
when you have to actually work on the bugs
to close them,

191
00:19:11,798 --> 00:19:14,628
you can rarely fix 25 in one day.

192
00:19:15,572 --> 00:19:18,873
So it's kind of the perks of doing
bug triaging.

193
00:19:19,523 --> 00:19:26,558
You know, "less bugs on the bug tracker,
I'm very efficient today."

194
00:19:28,229 --> 00:19:32,416
But don't close random stuff, but when
you find useless stuff to close,

195
00:19:32,416 --> 00:19:33,962
it feels good.

196
00:19:44,084 --> 00:19:44,935
Where am I?

197
00:19:57,127 --> 00:20:00,340
We missed the last sentence earlier.

198
00:20:01,318 --> 00:20:06,477
When trying to reproduce a bug, you
should pay particularly attention to

199
00:20:06,477 --> 00:20:07,939
the games team.

200
00:20:08,297 --> 00:20:14,440
You know, like, people open bug reports
against the game team and then

201
00:20:14,440 --> 00:20:19,599
Oh no, you have to install a bunch of
games to try to reproduce bugs,

202
00:20:20,166 --> 00:20:26,058
you know, but for work, so you install
a lot of games and

203
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,

204
00:20:32,719 --> 00:20:36,784
you get to try all the latest games.

205
00:20:40,476 --> 00:20:44,866
An other thing is when people open a bug
and didn't check if there was

206
00:20:44,866 --> 00:20:46,047
already one open.

207
00:20:46,893 --> 00:20:51,824
It ends up being 2 reports for the same bug.

208
00:20:52,765 --> 00:20:59,635
It's good to merge them so that's clearer.

209
00:21:01,138 --> 00:21:04,915
The 2 bug reports must be on the same
package, with the same severity

210
00:21:04,915 --> 00:21:06,417
and the same state,

211
00:21:07,106 --> 00:21:11,126
otherwise you can't merge, so you have
to send first the commands to do that,

212
00:21:11,411 --> 00:21:17,388
like I showed before, and at the end you
tell the bug tracker to merge.

213
00:21:23,680 --> 00:21:25,792
So, that we've seen.

214
00:21:39,649 --> 00:21:41,068
You can…

215
00:21:51,844 --> 00:21:55,508
Ok, you can't really see the…

216
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

217
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

218
00:22:09,300 --> 00:22:14,380
"Hi! I'm closing this bug, since it was
tagged 'moreinfo' for years

219
00:22:14,380 --> 00:22:20,397
without answer. If you still experience
the issue, please feel free to reopen it

220
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

221
00:22:24,213 --> 00:22:25,839
that has been archived.

222
00:22:28,600 --> 00:22:33,148
So that's a very standard message,
no nothing, it's not very long.

223
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.

224
00:22:45,344 --> 00:22:47,305
If you're not sure about a bug report,

225
00:22:47,305 --> 00:22:51,125
you read through it and you're still
not sure what to do

226
00:22:51,360 --> 00:22:54,864
because, let's be clear, I don't always
understand what the issue is.

227
00:22:55,392 --> 00:22:59,005
What you need to understand to triage
is what the status of the bug report is.

228
00:23:00,508 --> 00:23:02,092
I triaged bugs for the kernel.

229
00:23:03,637 --> 00:23:07,621
I don't understand anything about
the kernel, like most human beings

230
00:23:07,621 --> 00:23:13,424
but, without understanding the bug report,
you can understand if somebody asks

231
00:23:13,424 --> 00:23:15,219
for info and nobody provided it

232
00:23:15,708 --> 00:23:22,316
or, for example, for the kernel, all the
bug reports that were for the nouveau driver

233
00:23:22,316 --> 00:23:23,668
that is not supported anymore,

234
00:23:24,074 --> 00:23:28,668
it was possible to close them because
nobody cared anymore.

235
00:23:30,092 --> 00:23:33,223
So you don't necessarily need to understand
what the bug is about

236
00:23:33,223 --> 00:23:35,339
to do something about the bug report

237
00:23:37,086 --> 00:23:41,303
but sometimes it's a bit more complicated,
you're not sure

238
00:23:41,303 --> 00:23:44,746
just close the bug report, move to the
next one

239
00:23:45,202 --> 00:23:50,439
There's probably an other one that's,
you know, low hanging

240
00:23:50,439 --> 00:23:52,266
take the easy stuff.

241
00:23:54,136 --> 00:23:59,709
Because if you do something wrong, or
if you bother the maintainer to ask

242
00:23:59,709 --> 00:24:03,371
what should be done, then you're not
really helping,

243
00:24:03,696 --> 00:24:08,326
you might be taking time from them that
would be best invested somewhere else.

244
00:24:12,805 --> 00:24:16,681
Small warning, there are some people who
really don't like you touching

245
00:24:16,926 --> 00:24:18,186
their bug reports.

246
00:24:19,930 --> 00:24:23,786
I wish you not to encounter them.

247
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

248
00:24:33,379 --> 00:24:38,539
to step in and help or you can also
contact the anti-harassment team.

249
00:24:40,124 --> 00:24:46,508
But it's very rare and most of Debian
people are very nice people

250
00:24:47,726 --> 00:24:51,549
and they'll be happy to cooperate and
discuss with you

251
00:24:51,994 --> 00:24:57,854
and bug triaging is fun and rewarding
and easy.

252
00:25:01,061 --> 00:25:05,704
Those are the links to the things that
are useful to triage.

253
00:25:06,151 --> 00:25:07,896
The first one is…

254
00:25:18,951 --> 00:25:22,000
Ok, the first one is bad, I'll correct it.

255
00:25:24,843 --> 00:25:30,450
The second one is how to triage with
all the different commands

256
00:25:30,450 --> 00:25:32,358
that are useful.

257
00:25:32,967 --> 00:25:36,908
The third one is server control,

258
00:25:40,801 --> 00:25:44,502
a reminder of all the different instructions
you can send to server control

259
00:25:44,706 --> 00:25:48,044
which is the way to interact with
a bug report.

260
00:25:48,644 --> 00:25:55,626
The last one is about only closing and
you don't interact with control,

261
00:25:55,960 --> 00:26:01,694
you write to bugnumber-done, so that's
a different e-mail destination.

262
00:26:07,190 --> 00:26:14,059
So, the idea was to have a workshop,
so this was the explanation part and now

263
00:26:14,059 --> 00:26:18,939
let's close some bugs, or sort them,
maybe.