WEBVTT

99:59:59.999 --> 99:59:59.999
I'm Solveig.

99:59:59.999 --> 99:59:59.999
Here you have my contact info.

99:59:59.999 --> 99:59:59.999
I use Free Software and especially Debian
since quite some time now

99:59:59.999 --> 99:59:59.999
and I also contribute to Tails

99:59:59.999 --> 99:59:59.999
so my interests are in privacy…

99:59:59.999 --> 99:59:59.999
No? Yes? Do you hear me?

99:59:59.999 --> 99:59:59.999
I do some non-developer things

99:59:59.999 --> 99:59:59.999
and in Debian I found a way to contribute
without coding

99:59:59.999 --> 99:59:59.999
or maintaining packages which is to
triage bugs.

99:59:59.999 --> 99:59:59.999
Bug triaging, it helps,

99:59:59.999 --> 99:59:59.999
it's kind of non visible but it helps
Debian as a whole

99:59:59.999 --> 99:59:59.999
because maintainers don't always
have the time to deal

99:59:59.999 --> 99:59:59.999
with all their bug reports,

99:59:59.999 --> 99:59:59.999
some packages have a lot of
bug reports,

99:59:59.999 --> 99:59:59.999
like the kernel or Xorg.

99:59:59.999 --> 99:59:59.999
Also, it's a good way to improve the
package quality.

99:59:59.999 --> 99:59:59.999
When some packages have a lot of
bugs open against them,

99:59:59.999 --> 99:59:59.999
it can make it harder for the maintainers
to know which ones are

99:59:59.999 --> 99:59:59.999
solvable, actionable, and they can get a bit
over their head.

99:59:59.999 --> 99:59:59.999
So when you triage bugs, you help
everybody have a better experience

99:59:59.999 --> 99:59:59.999
with Debian.

99:59:59.999 --> 99:59:59.999
So, you want to do it.

99:59:59.999 --> 99:59:59.999
First, it's easy.

99:59:59.999 --> 99:59:59.999
You don't need to learn any new tool
supposing you already know

99:59:59.999 --> 99:59:59.999
how to read and write e-mail.

99:59:59.999 --> 99:59:59.999
So that's a low threshold to start.

99:59:59.999 --> 99:59:59.999
It's very rewarding, the maintainers are
happy when you help them,

99:59:59.999 --> 99:59:59.999
even if you don't touch their packages,

99:59:59.999 --> 99:59:59.999
if you sort their bugs, they'll be happy
and the users who submitted them

99:59:59.999 --> 99:59:59.999
will be happy that somebody looked
at them

99:59:59.999 --> 99:59:59.999
so it can be very joyful.

99:59:59.999 --> 99:59:59.999
Also, you search random bugs for packages
you don't necessarily know,

99:59:59.999 --> 99:59:59.999
so you learn about a lot of software
in Debian and

99:59:59.999 --> 99:59:59.999
some of them are really really surprising
and you…

99:59:59.999 --> 99:59:59.999
"Wha? What does this do?" and that's kind
of fun.

99:59:59.999 --> 99:59:59.999
And of course, it saves kittens.

99:59:59.999 --> 99:59:59.999
On this page, there's a…

99:59:59.999 --> 99:59:59.999
The bug triage page is a howto page
I made some years ago, with tips

99:59:59.999 --> 99:59:59.999
and this part, especially, has a list
of teams that added themselves

99:59:59.999 --> 99:59:59.999
so that they want you to help
sort their bugs.

99:59:59.999 --> 99:59:59.999
Those are the teams I worked with,
they're really really nice,

99:59:59.999 --> 99:59:59.999
they don't bite.

99:59:59.999 --> 99:59:59.999
They will let you know if you did an error,

99:59:59.999 --> 99:59:59.999
they will answer your questions,
you can work together.

99:59:59.999 --> 99:59:59.999
I don't recommend closing random bugs.

99:59:59.999 --> 99:59:59.999
If you go and touch packages from people
you have not warned

99:59:59.999 --> 99:59:59.999
or who are not willing to have somebody
touch their bugs,

99:59:59.999 --> 99:59:59.999
you might have backfire.

99:59:59.999 --> 99:59:59.999
To start, I think it's good to go packages
that you know people are happy

99:59:59.999 --> 99:59:59.999
if you help with.

99:59:59.999 --> 99:59:59.999
The first tool to triage bugs is UDD.

99:59:59.999 --> 99:59:59.999
I don't know if you've ever tried it,
the interface is really great.

99:59:59.999 --> 99:59:59.999
Here, that's UDD.

99:59:59.999 --> 99:59:59.999
So it's a bit arid like this, but

99:59:59.999 --> 99:59:59.999
it allows you to select many many
types of packages,

99:59:59.999 --> 99:59:59.999
we can see that later.

99:59:59.999 --> 99:59:59.999
Then you can choose a team or
other criteria

99:59:59.999 --> 99:59:59.999
and when you're happy about
your criteria, you search.

99:59:59.999 --> 99:59:59.999
It will give you a list of packages
corresponding to your criteria

99:59:59.999 --> 99:59:59.999
and you can select some more info
you want listed here.

99:59:59.999 --> 99:59:59.999
So, that's UDD search.

99:59:59.999 --> 99:59:59.999
I usually ignore the bug reports that
somebody has searched in the last year.

99:59:59.999 --> 99:59:59.999
Probably somebody else will look at them,

99:59:59.999 --> 99:59:59.999
let's look at those that are lost
in the limbos.

99:59:59.999 --> 99:59:59.999
I select wontfix, moreinfo, upstream or
unreproducible.

99:59:59.999 --> 99:59:59.999
Those are those that probably you can do
something on.

99:59:59.999 --> 99:59:59.999
And then you chose a team, preferably
one of those that is listed

99:59:59.999 --> 99:59:59.999
in the page we saw before.

99:59:59.999 --> 99:59:59.999
Once you'll have selected a bug and
something to do on it,

99:59:59.999 --> 99:59:59.999
you'll have to document what you do.

99:59:59.999 --> 99:59:59.999
Because you can change many many stuff
on the bug,

99:59:59.999 --> 99:59:59.999
you send the commands to
control@bugs.debian.org

99:59:59.999 --> 99:59:59.999
but it's always nice to put a small
a small sentence, or 2 or 3

99:59:59.999 --> 99:59:59.999
to say what made you conclude that is
the right change.

99:59:59.999 --> 99:59:59.999
Also make sure the e-mail where you do
the commands is sent

99:59:59.999 --> 99:59:59.999
to everybody interested, because
by default it only sends it

99:59:59.999 --> 99:59:59.999
to the maintainer and the submitter
in some cases.

99:59:59.999 --> 99:59:59.999
So if other people answered the bug
report saying

99:59:59.999 --> 99:59:59.999
"Hey, I have the bug too" or if upstream
came by to explain something,

99:59:59.999 --> 99:59:59.999
it's good to see all of those who
interacted on the bug report and

99:59:59.999 --> 99:59:59.999
put them all in copy.

99:59:59.999 --> 99:59:59.999
Ideally, people can receive the e-mail,
read what you're saying and

99:59:59.999 --> 99:59:59.999
don't have to go back to the bug page
to read it again.

99:59:59.999 --> 99:59:59.999
So that you should sum up the thread
if it was long and have them know everything.

99:59:59.999 --> 99:59:59.999
If you do massive triage, you should have
a few generic messages

99:59:59.999 --> 99:59:59.999
so you keep the messages and just
replace the words as needed.

99:59:59.999 --> 99:59:59.999
It saves you a lot of time.

99:59:59.999 --> 99:59:59.999
Also, it allows you to put a lot of
nice things in your generic e-mail

99:59:59.999 --> 99:59:59.999
that people are always happy to read
without more effort.

99:59:59.999 --> 99:59:59.999
You know, add a little "Thanks for
submitting the bug" or

99:59:59.999 --> 99:59:59.999
"That was a very interesting discussion"
or something like that.

99:59:59.999 --> 99:59:59.999
Let's keep the positive energy flowing.

99:59:59.999 --> 99:59:59.999
There are many ways to triage.

99:59:59.999 --> 99:59:59.999
One of them is trying to reproduce
bug reports.

99:59:59.999 --> 99:59:59.999
In the UDD we saw earlier, if you select
'unreproducible'

99:59:59.999 --> 99:59:59.999
Oh no… those that don't have the tag
'confirmed',

99:59:59.999 --> 99:59:59.999
these are bugs that one person submitted
but nobody knows if they're really

99:59:59.999 --> 99:59:59.999
still up to date or if it's just, somebody
submitted it but…

99:59:59.999 --> 99:59:59.999
If it's confirmed, there's more chance
that the maintainer will look at them.

99:59:59.999 --> 99:59:59.999
If they're really old, maybe they have been
corrected and nobody bothered

99:59:59.999 --> 99:59:59.999
to close the bug.

99:59:59.999 --> 99:59:59.999
If they're new, maybe you should have
them too, so see if it's the case.

99:59:59.999 --> 99:59:59.999
If it's the case, you write to this adress

99:59:59.999 --> 99:59:59.999
the 'nnn' is the number of the bug and
you add the tag 'confirmed'

99:59:59.999 --> 99:59:59.999
That's how we interact with control@b.d.o

99:59:59.999 --> 99:59:59.999
All the bug tracking is on a e-mail
interface

99:59:59.999 --> 99:59:59.999
'found bugnumber versionnumber'

99:59:59.999 --> 99:59:59.999
that's a command that control will
recognize,

99:59:59.999 --> 99:59:59.999
you give the bug number and what version
you're running.

99:59:59.999 --> 99:59:59.999
You add the tag 'confirmed'.

99:59:59.999 --> 99:59:59.999
Since you found it, you're 2, so it's
confirmed.

99:59:59.999 --> 99:59:59.999
And 'thanks', you always have to end
your e-mails to control with 'thanks'

99:59:59.999 --> 99:59:59.999
or 'thank you' or whatever variation
of it you want.

99:59:59.999 --> 99:59:59.999
The control is a very very polite beast
and likes you to be the same.

99:59:59.999 --> 99:59:59.999
If you don't put politeness, it won't work.

99:59:59.999 --> 99:59:59.999
Actually it's to tell them that the commands
are done, but

99:59:59.999 --> 99:59:59.999
let's be polite also with machines.

99:59:59.999 --> 99:59:59.999
If the bug was not confirmed, you tried
to reproduce it and you couldn't.

99:59:59.999 --> 99:59:59.999
You could add the tag 'unreproducible' or
'moreinfo'

99:59:59.999 --> 99:59:59.999
So, depending if you're quite sure that…
if you're not the first saying

99:59:59.999 --> 99:59:59.999
"I can't reproduce it" or if you're sure
you have exactly the same setup as

99:59:59.999 --> 99:59:59.999
the original submitter,

99:59:59.999 --> 99:59:59.999
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.