Learn how to triage bugs

Talk given by Solveig at Debconf18
https://meetings-archive.debian.net/pub/debian-meetings/2018/DebConf18/2018-07-30/learn-how-to-triage-bugs.webm

I'm Solveig.

Here you have my contact info.

I use Free Software and especially Debian
since quite some time now

and I also contribute to Tails

so my interests are in privacy…

No? Yes? Do you hear me?

I do some non-developer things

and in Debian I found a way to contribute
without coding

or maintaining packages which is to
triage bugs.

Bug triaging, it helps,

it's kind of non visible but it helps
Debian as a whole

because maintainers don't always
have the time to deal

with all their bug reports,

some packages have a lot of
bug reports,

like the kernel or Xorg.

Also, it's a good way to improve the
package quality.

When some packages have a lot of
bugs open against them,

it can make it harder for the maintainers
to know which ones are

solvable, actionable, and they can get a bit
over their head.

So when you triage bugs, you help
everybody have a better experience

with Debian.

So, you want to do it.

First, it's easy.

You don't need to learn any new tool
supposing you already know

how to read and write e-mail.

So that's a low threshold to start.

It's very rewarding, the maintainers are
happy when you help them,

even if you don't touch their packages,

if you sort their bugs, they'll be happy
and the users who submitted them

will be happy that somebody looked
at them

so it can be very joyful.

Also, you search random bugs for packages
you don't necessarily know,

so you learn about a lot of software
in Debian and

some of them are really really surprising
and you…

"Wha? What does this do?" and that's kind
of fun.

And of course, it saves kittens.

On this page, there's a…

The bug triage page is a howto page
I made some years ago, with tips

and this part, especially, has a list
of teams that added themselves

so that they want you to help
sort their bugs.

Those are the teams I worked with,
they're really really nice,

they don't bite.

They will let you know if you did an error,

they will answer your questions,
you can work together.

I don't recommend closing random bugs.

If you go and touch packages from people
you have not warned

or who are not willing to have somebody
touch their bugs,

you might have backfire.

To start, I think it's good to go packages
that you know people are happy

if you help with.

The first tool to triage bugs is UDD.

I don't know if you've ever tried it,
the interface is really great.

Here, I can show you.

Here, that's UDD.

So it's a bit arid like this, but

it allows you to select many many
types of packages,

we can see that later.

Then you can choose a team or
other criteria

and when you're happy about
your criteria, you search.

It will give you a list of packages
corresponding to your criteria

and you can select some more info
you want listed here.

So, that's UDD search.

I usually ignore the bug reports that
somebody has searched in the last year.

Probably somebody else will look at them,

let's look at those that are lost
in the limbos.

I select wontfix, moreinfo, upstream or
unreproducible.

Those are those that probably you can do
something on.

And then you chose a team, preferably
one of those that is listed

in the page we saw before.

Once you'll have selected a bug and
something to do on it,

you'll have to document what you do.

Because you can change many many stuff
on the bug,

you send the commands to
[e-mail]

but it's always nice to put a small
a small sentence, or 2 or 3

to say what made you conclude that is
the right change.

Also make sure the e-mail where you do
the commands is sent

to everybody interested, because
by default it only sends it

to the maintainer and the submitter
in some cases.

So if other people answered the bug
report saying

"Hey, I have the bug too" or if upstream
came by to explain something,

it's good to see all of those who
interacted on the bug report and

put them all in copy.

Ideally, people can receive the e-mail,
read what you're saying and

don't have to go back to the bug page
to read it again.

So that you should sum up the thread
if it was long and have them know everything.

If you do massive triage, you should have
a few generic messages

so you keep the messages and just
replace the words as needed.

It saves you a lot of time.

Also, it allows you to put a lot of
nice things in your generic e-mail

that people are always happy to read
without more effort.

You know, add a little "Thanks for
submitting the bug" or

"That was a very interesting discussion"
or something like that.

Let's keep the positive energy flowing.

There are many ways to triage.

One of them is trying to reproduce
bug reports.

In the UDD we saw earlier, if you select
'unreproducible'

Oh no… those that don't have the tag
'confirmed',

these are bugs that one person submitted
but nobody knows if they're really

still up to date or if it's just, somebody
submitted it but…

If it's confirmed, there's more chance
that the maintainer will look at them.

If they're really old, maybe they have been
corrected and nobody bothered

to close the bug.

If they're new, maybe you should have
them too, so see if it's the case.

If it's the case, you write to this adress

the 'nnn' is the number of the bug and
you add the tag 'confirmed'

That's how we interact with control@b.d.o

All the bug tracking is on a e-mail
interface

'found bugnumber versionnumber'

that's a command that control will
recognize,

you give the bug number and what version
you're running.

You add the tag 'confirmed'.

Since you found it, you're 2, so it's
confirmed.

And 'thanks', you always have to end
your e-mails to control with 'thanks'

or 'thank you' or whatever variation
of it you want.

The control is a very very polite beast
and likes you to be the same.

If you don't put politeness, it won't work.

Actually it's to tell them that the commands
are done, but

let's be polite also with machines.

If the bug was not confirmed, you tried
to reproduce it and you couldn't.

You could add the tag 'unreproducible' or
'moreinfo'

So, depending if you're quite sure that…
if you're not the first saying

"I can't reproduce it" or if you're sure
you have exactly the same setup as

the original submitter,

then you should put 'unreproducible'.

If it might be reproducible for other
people, but just not you,

then you should ask 'moreinfo' so that
the original submitter gives

more details on how to reproduce their bug

And it also requires you to be polite
at the end of the command.

An other very useful thing is to forward
them upstream.

Some upstream follow the Debian bug tracker

but a lot of them don't.

Maybe somebody reported the issue in
the Debian bug tracker but

upstream is not aware of it

and most Debian maintainers are not
gonna solve the bug themselves,

they're more probably gonna wait for it
to be corrected upstream,

so we need the bug to go back to where
it will be corrected

In a lot of cases, it can be because
upstream considers it not a bug,

so won't fix it, so let's say it on the
Debian bug too

or maybe upstream is not aware of
the bug so…

Ok, that's very tiny…

At least you have all.

Here you have the command to add
the upstream bug tracker number.

"forwarded bugnumber", you put the URL
in the upstream's bug tracker

and then you say thanks again.

So that's what I was saying before, you
can also report it upstream

if it hasn't been already.

Sometimes, the upstream bug tracker
is more up to date,

so in upstream it's fixed, so it's good
to let know to the Debian bug tracker

and add the tag 'fixedupstream'

and it's good to say in which version
so that the maintainer may be

motivated to update to the new version.

In lot of cases, the bug reports are tagged
'moreinfo', which is

somebody said "It doesn't work", which,
sorry for you, but there's no chance

it's gonna be fixed with that.

So in lots of cases, the bug is tagged
'moreinfo' to say

"This bug does not give enough info
to be solved"

Or sometimes, the maintainer
packages a new version

and you think probably the bug is
solved,

and you also need to ask the original
submitter if they still have the bug

Or somebody said "Oh I'm gonna do some
test next weekend" and it's 2 years later

and you're not sure they actually did
the test they were saying they would do.

So, info were asked and it feels like
the bug is hanging.

In those cases, it's helpful, sometimes,
to send an e-mail to the person who said

"I'm gonna do something" or who needs to
answer if they still have the bug

and saying "Hey! that's a gentle ping"

"You said you would test" or "Can you still
reproduce a bug?"

so that you can update the status of the
bug on the bug tracker.

It's good to wait, like, a good amount of
time before bothering people

about this kind of thing.

I usually wait one year, like I told you,
probably shorter might be good,

but it's good also not to harass people,
they have a life.

Sometimes, the bugs have been tagged
'moreinfo' or 'wontfix' for a long time

The info is not given, or it's unlikely
that somebody else wants

this 'non-bug' fixed.

Different teams have different policies
but most of them will be happy

if you close the bugs that nobody is gonna
do anything about.

If the bug was tagged 'moreinfo' more than
a year ago and

nobody answered to give more info, or if
a major release came out and

probably the bug is fixed but the original
submitter doesn't answer

then it's good to close them, in most
cases, depending on the team.

But it's good to ping them before you
close

give them a reasonable amount of time
to try to test it again.

Ok, we don't have the bottom of the page.

The command to…

The command to close a bug is to write to
-done@control.b.d.o

Maybe I shouldn't have done that.

And closing the bugs is kind of one of
the most satisfying things to do.

Sometimes, I speak with my maintainer
friends and I say

"Hey, I closed 25 bugs today" and they're
kind of jealous because

when you have to actually work on the bugs
to close them,

you can rarely fix 25 in one day.

So it's kind of the perks of doing
bug triaging.

You know, "less bugs on the bug tracker,
I'm very efficient today."

But don't close random stuff, but when
you find useless stuff to close,

it feels good.

Where am I?

We missed the last sentence earlier.

When trying to reproduce a bug, you
should pay particularly attention to

the games team.

You know, like, people open bug reports
against the game team and then

Oh no, you have to install a bunch of
games to try to reproduce bugs,

you know, but for work, so you install
a lot of games and

you try to see if they're buggy, so that's
also another perk of triaging bugs,

you get to try all the latest games.

An other thing is when people open a bug
and didn't check if there was

already one open.

It ends up being 2 reports for the same bug.

It's good to merge them so that's clearer.

The 2 bug reports must be on the same
package, with the same severity

and the same state,

otherwise you can't merge, so you have
to send first the commands to do that,

like I showed before, and at the end you
tell the bug tracker to merge.

So, that we've seen.

You can…

Ok, you can't really see the…

So, I was giving an example of my standard
message I paste when I close a bug

and we don't see the end, but I'm gonna
do it from memory, it says

"Hi! I'm closing this bug, since it was
tagged 'moreinfo' for years

without answer. If you still experience
the issue, please feel free to reopen it

or ask me to do it" because some people
don't know how to reopen a bug

that has been archived.

So that's a very standard message,
no nothing, it's not very long.

That is good to have a model so that
you can just paste, with niceness in it.

If you're not sure about a bug report,

you read through it and you're still
not sure what to do

because, let's be clear, I don't always
understand what the issue is.

What you need to understand to triage
is what the status of the bug report is.

I triaged bugs for the kernel.

I don't understand anything about
the kernel, like most human beings

but, without understanding the bug report,
you can understand if somebody asks

for info and nobody provided it

or, for example, for the kernel, all the
bug reports that were for the nouveau driver

that is not supported anymore,

it was possible to close them because
nobody cared anymore.

So you don't necessarily need to understand
what the bug is about

to do something about the bug report

but sometimes it's a bit more complicated,
you're not sure

just close the bug report, move to the
next one

There's probably an other one that's,
you know, low hanging

take the easy stuff.

Because if you do something wrong, or
if you bother the maintainer to ask

what should be done, then you're not
really helping,

you might be taking time from them that
would be best invested somewhere else.

Small warning, there are some people who
really don't like you touching

their bug reports.

I wish you not to encounter them.

I you do, just either ignore them or ask
the maintainers of the package you're triaging

to step in and help or you can also
contact the anti-harassment team.

But it's very rare and most of Debian
people are very nice people

and they'll be happy to cooperate and
discuss with you

and bug triaging is fun and rewarding
and easy.

Those are the links to the things that
are useful to triage.

The first one is…

Ok, the first one is bad, I'll correct it.

The second one is how to triage with
all the different commands

that are useful.

The third one is server control,

a reminder of all the different instructions
you can send to server control

which is the way to interact with
a bug report.

The last one is about only closing and
you don't interact with control,

you write to bugnumber-done, so that's
a different e-mail destination.

So, the idea was to have a workshop,
so this was the explanation part and now

let's close some bugs, or sort them,
maybe.