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

99:59:59.999 --> 99:59:59.999
If it might be reproducible for other
people, but just not you,

99:59:59.999 --> 99:59:59.999
then you should ask 'moreinfo' so that
the original submitter gives

99:59:59.999 --> 99:59:59.999
more details on how to reproduce their bug

99:59:59.999 --> 99:59:59.999
And it also requires you to be polite
at the end of the command.

99:59:59.999 --> 99:59:59.999
An other very useful thing is to forward
them upstream.

99:59:59.999 --> 99:59:59.999
Some upstream follow the Debian bug tracker

99:59:59.999 --> 99:59:59.999
but a lot of them don't.

99:59:59.999 --> 99:59:59.999
Maybe somebody reported the issue in
the Debian bug tracker but

99:59:59.999 --> 99:59:59.999
upstream is not aware of it

99:59:59.999 --> 99:59:59.999
and most Debian maintainers are not
gonna solve the bug themselves,

99:59:59.999 --> 99:59:59.999
they're more probably gonna wait for it
to be corrected upstream,

99:59:59.999 --> 99:59:59.999
so we need the bug to go back to where
it will be corrected

99:59:59.999 --> 99:59:59.999
In a lot of cases, it can be because
upstream considers it not a bug,

99:59:59.999 --> 99:59:59.999
so won't fix it, so let's say it on the
Debian bug too

99:59:59.999 --> 99:59:59.999
or maybe upstream is not aware of
the bug so…

99:59:59.999 --> 99:59:59.999
Ok, that's very tiny…

99:59:59.999 --> 99:59:59.999
At least you have all.

99:59:59.999 --> 99:59:59.999
Here you have the command to add
the upstream bug tracker number.

99:59:59.999 --> 99:59:59.999
"forwarded bugnumber", you put the URL
in the upstream's bug tracker

99:59:59.999 --> 99:59:59.999
and then you say thanks again.

99:59:59.999 --> 99:59:59.999
So that's what I was saying before, you
can also report it upstream

99:59:59.999 --> 99:59:59.999
if it hasn't been already.

99:59:59.999 --> 99:59:59.999
Sometimes, the upstream bug tracker
is more up to date,

99:59:59.999 --> 99:59:59.999
so in upstream it's fixed, so it's good
to let know to the Debian bug tracker

99:59:59.999 --> 99:59:59.999
and add the tag 'fixedupstream'

99:59:59.999 --> 99:59:59.999
and it's good to say in which version
so that the maintainer may be

99:59:59.999 --> 99:59:59.999
motivated to update to the new version.

99:59:59.999 --> 99:59:59.999
In lot of cases, the bug reports are tagged
'moreinfo', which is

99:59:59.999 --> 99:59:59.999
somebody said "It doesn't work", which,
sorry for you, but there's no chance

99:59:59.999 --> 99:59:59.999
it's gonna be fixed with that.

99:59:59.999 --> 99:59:59.999
So in lots of cases, the bug is tagged
'moreinfo' to say

99:59:59.999 --> 99:59:59.999
"This bug does not give enough info
to be solved"

99:59:59.999 --> 99:59:59.999
Or sometimes, the maintainer
packages a new version

99:59:59.999 --> 99:59:59.999
and you think probably the bug is
solved,

99:59:59.999 --> 99:59:59.999
and you also need to ask the original
submitter if they still have the bug

99:59:59.999 --> 99:59:59.999
Or somebody said "Oh I'm gonna to some
fix next weekend" and it's 2 years later

99:59:59.999 --> 99:59:59.999
and you're not sure they actually did
the test they were saying they would do.

99:59:59.999 --> 99:59:59.999
So, info were asked and it feels like
the bug is hanging.

99:59:59.999 --> 99:59:59.999
In those cases, it's helpful, sometimes,
to send an e-mail to the person who said

99:59:59.999 --> 99:59:59.999
"I'm gonna do something" or who needs to
answer if they still have the bug

99:59:59.999 --> 99:59:59.999
and saying "Hey! that's a gentle ping"

99:59:59.999 --> 99:59:59.999
"You said you would test" or "Can you still
reproduce a bug?"

99:59:59.999 --> 99:59:59.999
so that you can update the status of the
bug on the bug tracker.

99:59:59.999 --> 99:59:59.999
It's good to wait, like, a good amount of
time before bothering people

99:59:59.999 --> 99:59:59.999
about this kind of thing.

99:59:59.999 --> 99:59:59.999
I usually wait one year, like I told you,
probably shorter might be good,

99:59:59.999 --> 99:59:59.999
but it's good also not to harass people,
they have a life.

99:59:59.999 --> 99:59:59.999
Sometimes, the bugs have been tagged
'moreinfo' or 'wontfix' for a long time

99:59:59.999 --> 99:59:59.999
The info is not given, or it's unlikely
that somebody else wants

99:59:59.999 --> 99:59:59.999
this 'non-bug' fixed.

99:59:59.999 --> 99:59:59.999
Different teams have different policies
but most of them will be happy

99:59:59.999 --> 99:59:59.999
if you close the bugs that nobody is gonna
do anything about.

99:59:59.999 --> 99:59:59.999
If the bug was tagged 'moreinfo' more than
a year ago and

99:59:59.999 --> 99:59:59.999
nobody answered to give more info, or if
a major release came out and

99:59:59.999 --> 99:59:59.999
probably the bug is fixed but the original
submitter doesn't answer

99:59:59.999 --> 99:59:59.999
then it's good to close them, in most
cases, depending on the team.

99:59:59.999 --> 99:59:59.999
But it's good to ping them before you
close

99:59:59.999 --> 99:59:59.999
give them a reasonable amount of time
to try to test it again.

99:59:59.999 --> 99:59:59.999
Ok, we don't have the bottom of the page.

99:59:59.999 --> 99:59:59.999
The command to…

99:59:59.999 --> 99:59:59.999
The command to close a bug is to write to
-done@control.b.d.o

99:59:59.999 --> 99:59:59.999
Maybe I shouldn't have done that.

99:59:59.999 --> 99:59:59.999
And closing the bugs is kind of one of
the most satisfying things to do.

99:59:59.999 --> 99:59:59.999
Sometimes, I speak with my maintainer
friends and I say

99:59:59.999 --> 99:59:59.999
"Hey, I closed 25 bugs today" and they're
kind of jealous because

99:59:59.999 --> 99:59:59.999
when you have to actually work on the bugs
to close them,

99:59:59.999 --> 99:59:59.999
you can rarely fix 25 in one day.

99:59:59.999 --> 99:59:59.999
So it's kind of the perks of doing
bug triaging.

99:59:59.999 --> 99:59:59.999
You know, less bugs on the bug tracker,
I'm very efficient today.

99:59:59.999 --> 99:59:59.999
But don't close random stuff, but when
you find useless stuff to close,

99:59:59.999 --> 99:59:59.999
it feels good.

99:59:59.999 --> 99:59:59.999
Where am I?

99:59:59.999 --> 99:59:59.999
We missed the last sentence earlier.

99:59:59.999 --> 99:59:59.999
When trying to reproduce a bug, you
should pay particularly attention to

99:59:59.999 --> 99:59:59.999
the games team.

99:59:59.999 --> 99:59:59.999
You know, like, people open bug reports
against the game team and then

99:59:59.999 --> 99:59:59.999
Oh no, you have to install a bunch of
games to try to reproduce bugs,

99:59:59.999 --> 99:59:59.999
you know, but for work, so you install
a lot of games and

99:59:59.999 --> 99:59:59.999
you try to see if they're buggy, so that's
also another perk of triaging bugs,

99:59:59.999 --> 99:59:59.999
you get to try all the latest games.

99:59:59.999 --> 99:59:59.999
An other thing is when people open a bug
and didn't check if there was

99:59:59.999 --> 99:59:59.999
already one open.

99:59:59.999 --> 99:59:59.999
It ends up being 2 reports for the same bug.

99:59:59.999 --> 99:59:59.999
It's good to merge them so that's clearer.

99:59:59.999 --> 99:59:59.999
The 2 bug reports must be on the same
package, with the same severity

99:59:59.999 --> 99:59:59.999
and the same state,

99:59:59.999 --> 99:59:59.999
otherwise you can't merge, so you have
to send first the commands to do that,

99:59:59.999 --> 99:59:59.999
like I showed before, and at the end you
tell the bug tracker to merge.

99:59:59.999 --> 99:59:59.999
So, that we've seen.

99:59:59.999 --> 99:59:59.999
You can…

99:59:59.999 --> 99:59:59.999
Ok, you can't really see the…

99:59:59.999 --> 99:59:59.999
So, I was giving an example of my standard
message I paste when I close a bug

99:59:59.999 --> 99:59:59.999
and we don't see the end, but I'm gonna
do it from memory, it says

99:59:59.999 --> 99:59:59.999
"Hi! I'm closing this bug, since it was
tagged 'moreinfo' for years

99:59:59.999 --> 99:59:59.999
without answer. If you still experience
the issue, please feel free to reopen it

99:59:59.999 --> 99:59:59.999
or ask me to do it" because some people
don't know how to reopen a bug

99:59:59.999 --> 99:59:59.999
that has been archived.

99:59:59.999 --> 99:59:59.999
So that's a very standard message,
no nothing, it's not very long.

99:59:59.999 --> 99:59:59.999
That is good to have a model so that
you can just paste, with niceness in it.

99:59:59.999 --> 99:59:59.999
If you're not sure about a bug report,

99:59:59.999 --> 99:59:59.999
you read through it and you're still
not sure what to do

99:59:59.999 --> 99:59:59.999
because, let's be clear, I don't always
understand what the issue is.

99:59:59.999 --> 99:59:59.999
What you need to understand to triage
is what the status of the bug report is.

99:59:59.999 --> 99:59:59.999
I triaged bugs for the kernel.

99:59:59.999 --> 99:59:59.999
I don't understand anything about
the kernel, like most human beings

99:59:59.999 --> 99:59:59.999
but, without understanding the bug report,
you can understand if somebody asks

99:59:59.999 --> 99:59:59.999
for info and nobody provided it

99:59:59.999 --> 99:59:59.999
or, for example, for the kernel, all the
bug reports that were for the nouveau driver

99:59:59.999 --> 99:59:59.999
that is not supported anymore,

99:59:59.999 --> 99:59:59.999
it was possible to close them because
nobody cared anymore.

99:59:59.999 --> 99:59:59.999
So you don't necessarily need to understand
what the bug is about

99:59:59.999 --> 99:59:59.999
to do something about the bug report

99:59:59.999 --> 99:59:59.999
but sometimes it's a bit more complicated,
you're not sure

99:59:59.999 --> 99:59:59.999
just close the bug report, move to the
next one

99:59:59.999 --> 99:59:59.999
There's probably an other one that's,
you know, low hanging

99:59:59.999 --> 99:59:59.999
take the easy stuff.

99:59:59.999 --> 99:59:59.999
Because if you do something wrong, or
if you bother the maintainer to ask

99:59:59.999 --> 99:59:59.999
what should be done, then you're not
really helping,

99:59:59.999 --> 99:59:59.999
you might be taking time from them that
would be best invested somewhere else.

99:59:59.999 --> 99:59:59.999
Small warning, there are some people who
really don't like you touching

99:59:59.999 --> 99:59:59.999
their bug reports.

99:59:59.999 --> 99:59:59.999
I wish you not to encounter them.

99:59:59.999 --> 99:59:59.999
I you do, just either ignore them or ask
the maintainers of the package you're triaging

99:59:59.999 --> 99:59:59.999
to step in and help or you can also
contact the anti-harassment team.

99:59:59.999 --> 99:59:59.999
But it's very rare and most of Debian
people are very nice people

99:59:59.999 --> 99:59:59.999
and they'll be happy to cooperate and
discuss with you

99:59:59.999 --> 99:59:59.999
and bug triaging is fun and rewarding
and easy.

99:59:59.999 --> 99:59:59.999
Those are the links to the things that
are useful to triage.

99:59:59.999 --> 99:59:59.999
The first one is…

99:59:59.999 --> 99:59:59.999
Ok, the first one is bad, I'll correct it.

99:59:59.999 --> 99:59:59.999
The second one is how to triage with
all the different commands

99:59:59.999 --> 99:59:59.999
that are useful.

99:59:59.999 --> 99:59:59.999
The third one is server control,

99:59:59.999 --> 99:59:59.999
a reminder of all the different instructions
you can send to server control

99:59:59.999 --> 99:59:59.999
which is the way to interact with
a bug report.

99:59:59.999 --> 99:59:59.999
The last one is about only closing and
you don't interact with control,

99:59:59.999 --> 99:59:59.999
you write to bugnumber-done, so that's
a different e-mail destination.

99:59:59.999 --> 99:59:59.999
So, the idea was to have a workshop,
so this was the explanation part and now

99:59:59.999 --> 99:59:59.999
let's close some bugs, or sort them,
maybe.