meetings-archive.debian.net/.../Bug_triaging_and_bug_closing_by_Solveig.webm

Hi

thanks to be here and

I hope some of you will find it interesting but

most of you already

know it, probably

So, that's a talk about

bug triaging and closing.

I'm Solveig, here are my contact info.

I use free software since

ten years and

I focus especially on

privacy issues

I contribute to Tails

which is a Debian derivative

and

I went to last DebConf and enjoyed it very much

and started triaging bugs

because I'm no

coder, but

there are many ways to contribute to Debian

So, bug triaging

It's

a very small task but it helps Debian as a whole

So, on the

So, that's where you can see

the Debian bug tracking system, where, here

you can enter a bug number and search for it by number

Lots of maintainers have lots of work and don't

deal with all their bug reports

Some high popularity

packages

get a lot of bug reports

like the kernel, or

firefox (iceweasel)

and

sometimes

maintainers, for any reason, don't have time to deal with all their bug reports

So, some of them just

hang out in the bug tracking system without

being dealt with

So,

when you

triage them,

you make sure that they are in a state where

something can be done with them

It's

The maintainers are sure they have up to date

bug reports, so that they

see better what they can do

and

the users searching for

bugs similar to theirs

can find them

and so the maintainers have more time to

fix actually those that they can fix

and

you want to triage bugs

because it's easy

you don't need to code

you don't need to do system administration

you just need to know how to read

and write e-mails

[laughter]

It's rewarding, because

maintainers, most of them,

are really happy when you help them

Submitters also

are glad to be pinged about their bugs, so

you got lots of nice feedback

and it's fun

you read about

software you have no idea it did exist

you don't get,

even after reading, what they're supposed to do

and you really don't undersand while somebody

coded them

That's

crazy, that's

[laughter]

and, of course, it saves kittens

[applause]

There are many different

operations you can perform

on the bug reports

Those are two of the

most useful

documentation pages

the wiki page about bug triage

and the server control commands

which are quite

exotic, I mean, that's a huge page

with many commands to send to the

server control and

really lots of things to do, to tell them

the most useful for the

Well, those are highly used

You can

try to reproduce bug reports

I'm going to detail afterwards

You can tag bug reports when they are unreproducible

you can merge bugs

forward them upstream

and deal with upstream

and deal with submitters

and, I nearly forgot, you can

close bugs, which is really the best part

So, reproducing them

Sometimes, you get bug reports that have not been touched in years

and

probably they are fixed, or maybe not, but

in doubt

it will probably just wait there and nobody will

touch the bug report because

there's a high probability it doesn't apply anymore

so you can test if it still applies

There are also new bug reports

that are only one person reported

so, if they're not tagged

"confirmed"

or "pending"

and if you can

[mic out of battery]

If new bug reports have been confirmed yet,

you can

try and see if you can reproduce them

and if yes, confirm them

If you can reproduce

old bugs or new bugs

not confirmed yet

then you write to "nnn"

so, that's for the bug number

@bugs.debian.org

and tag them

That's the first of the strange commands

So, "found" the number of the bug

version number

you confirm which version

and you tag it

"confirmed", and "thanks", because

server control is very polite

so if you don't thank it

each time you

make a command, it's upset

Another way to

triage a bug is to

try to reproduce it

and, let's say it didn't work

If you can't reproduce it and it's fixed

then we'll see later you can close it

If you can't reproduce it but

you're not sure it's fixed

because maybe it's because you don't have the same

configuration as the submitter

or

maybe you didn't

you're not sure you followed the same steps

to

try it

If you're not sure, then you

tag "unreproducible"

or "moreinfo"

and it

lets the submitter know

and the maintainer that

not everybody finds the bug

which can be an information

Sometimes, you could have to merge them

that's especially true for the new bugs because

it's where they stay forever

duplicates

That's

Putting them on the same package

and with the same severity and state is

different operations

it's detailed in the documentation

and, at the end, you

merge

That's funny

All the messages are gonna be

put together, so

sometimes you have to search for a while, and

there can be more than two bugs

fusionned

So, sometimes it's really

not fusionned, merged

After a while, sometimes there can be

three or four

if people

keep opening the same one

So, that's sometimes funny

An other way is to report,

to forward reports upstream

because

Debian is mainly packages

that are not developped for Debian but upstream

and only Debian packaged

so, if there's a bug

occurring in Debian,

in most cases it occurs

upstream

so you can search

the upstream bug tracker to see

if they have similar reports

If they do

sometimes they also have

a workaround or

sometimes

upstream says they won't fix it

because they don't consider it a bug or

When it's the case, then

the information should be

put in the Debian

bugtracker

and

if

the bug already exists in upstream, then

Debian bug tracker should know it

so you have to tell it to the BTS

That's also a command, I

fucked my

the way to show it, but, ok

that's the command

so, "forwarded", the bug number

in Debian

and the bug number upstream

and "thanks" again, because it's always polite

There are other things you can do with upstream

Sometimes

they don't have the bug report

but it's

obviously a bug of them

so

if you can reproduce

the bug, you should

open a bug upstream

which is

most of the time a pain in the ass

because you have to register an account

or find

their bug tracker or any way

That's fun

So, it saves time to the maintainer

and the submitter

sees more chances to see it solved at some point also

If you open

the bug in the upstream bug tracker and you

have to do

to mark it as forwarded as we just saw

Sometimes, upstream says it's fixed

and then you should

say to Debian bug tracker that it's fixed upstream

you have to say in which version

and

maybe the maintainer will update

his package to

give the fixed version

and sometimes there's a patch upstream

that has not been applied

so you can also review

and/or test it

and tell them if it works

or not

If it works

you can also

bring it to the Debian bug tracking system and

tag the bug "patch"

There's also work with submitters

there's a high percentage of bugs

that are tagged "moreinfo"

Somebody

told us

"It doesn't work" and

we need to know how it doesn't work

Sometimes

there has been a new version packaged

and maybe the bug occurs, maybe not

you have to know

or somebody said

"I'll test with this version or this setup"

and/or say "I'll report it upstream" and

nothing happened

and sometimes

it stays in this

"waiting for information" situation

for a long time

I wrote

a year or a release

because that's what I consider

starting being a long time

I found some, I closed some that were

not touched since more than ten years, that's

record

You can help

you can send an e-mail to the

person whose input is needed

so, sometimes

the submitter, sometimes the

maintainer, sometimes upstream

sometimes

somebody else

saying

"You said you would do that" or

"Can you still reproduce it?"

because

so that the bug report become

gets in a state where we see

what's the current status and

what should be done

So, the tricky part is

don't

close random bugs

As we'll see later, it can be dangerous

You can search for packages

that have a lot of bug reports

and ask the maintainer if

help is welcome, or

you can find a nice team

Debian is centered with

composed of plenty of teams

Most of them are really welcoming

to new contributors

because they need help

and

those I met are nice

and in a team, you're sure there's

plenty of packages, so

plenty of bugs to triage

and people to answer questions

I've

triaged bugs from

perl team, games team

X strike force

they're all very nice

I recommend them to you

I

tried, but I didn't get

really understood anything, but

if you do understand anything

kernel bugs

need work too

On the documentation about bug triage

I added a section about

teams that welcome help

So, if you're in a team

that needs triaging, add yourself there

If you want to triage

look there

who wants help

and you don't need to understand

anything about what they do to

triage there bugs

I mean,

Perl... I don't code

so Perl is... and

X strike force is like

not really written in english

but

Ok, games, I could

try to reproduce them

some of them

the others, really not, but

sometime, you really can see the status

of a bug without understanding what it's about

You see that if somebody asked

for info a year ago,

it has to be pinged

or

considered that there's not gonna be any

even if you don't understand what the bug is

you can see what the status

of the bug is

A fabulous tool

is ultimate Debian database bug search

It looks like this

Please ignore that

So, you select

which version

you can add many filters

bug types

Well, actually it also includes the teams here

and when you're done, you search

That's

really useful

As you see, my

it doesn't look like it should

Criteria for bugs that have been lost

If you ignore those that have been touched

or created in the last year

and you select

either "wontfix" or "moreinfo"

or "upstream" or "unreproducible"

then you choose a team

and

you're gonna find lots of lost bugs

then you can start reading them

and see what's their status

If they are unreproducible

if the bug

has been fixed, actually

Well,

either the new version fixes the bug or

Anyway, the bug has been fixed

because it's a configuration thing anyway

it doesn't happen anymore

you can close it

So, that's the bug number again

"[e-mail]"

and you have to put

in which version it has been fixed

so, maybe it has been fixed

in the meantime

but, at least, say

"this current version, I'm sure it's fixed"

so that the BTS knows

which version it affects and

most of all, which versions are not affected

There's a nice documentation page about that

closing bug reports is only

sending one e-mail to

"[e-mail]"

That was for "unreproducible"

Ok, "moreinfo" or "wontfix"

For those

you have to make sure with a team

or the maintainer what

is there policy, because

some people want to keep them all

open forever

and some "wontfix" should

anyway stay open because

if there are functionalities or

bugs that are

often requested, then

it would be silly to close it

then have somebody reopen it soon

but, lots of

bugs that are tagged "moreinfo"

and never got info back

or are tagged "wontfix"

should just be closed because there's no work

that's gonna happen to them

There are no

guidelines on the documentation about that

so I decided arbitrarily

one year after

the submitter was pinged and didn't answer

we could maybe consider that

missing submitter

Maybe it could be shorter, but

People could be angry also because it's also

great contribution to report bugs and that should

not be deleted

lightly

If you're sure that the bug is

really no use to anyone

then, just the same

number "-done"

with the explanation, of course

So, an example

We're gonna do the search

"wontfix"

not touched in the last year, perl

Include "wontfix"

ignore

created or modified in the last

year or so

and let's see those of the perl team

All those bugs

from different packages

but they're all

they all respond to the same criteria

and we can sort them

by the last time they were modified

lots of them have been forgotten for some years

and, well, the

next step is to start reading the reports

since I did prepare a little bit

even if not much

I selected one, so

there's one that can be read

and I won't read it

completely with you today, but

you see that

the conclusion is

upstream considered it's not a bug

it was told in

2010

so

there has been time

to let people know

[laughter]

and it's closed upstream

so, that's the bug report upstream

where upstream says

"It does according to the man page"

"closing"

So, upstream closed it

we should do the same

So, I did it

and I

won't show you now, so I

sent this e-mail

just before I came in

to -done

subject:

we use a bug

report

subject, so that people

know what it's about

and I precise that I'm closing it

and then, that's my standard message

"Hi, I'm closing this bug since it was

tagged unreproducible for some

years without answer

If you have new reasons to point

out this problem, please feel free

to reopen or ask me to do it"

That's because not all submitters

know all the subtleties

of the control server

and not all of them

know how to reopen a bug

so asking them to reopen

a bug can be

a little bit to much, so

if I closed it

and it was not a good idea, they can

ask me to reopen it, so

nobody becomes lost in the way

Sometimes, there are bug reports where

probably it should be

closed or merged

or something, but you're not

completely sure

There no hurry, most of them

are waiting since a while anyway

so just take

some days, weeks, months

or years

as it happens, and

maybe next time you

open this bug report, it will be

way clearer what you should do with it

because more experience or

clearer mind that day

You can also

ask for opinions from

the maintainers if they are

willing to help or to

other friends or

team members

Warning

that's the point

earlier about not closing random bugs

if the maintainer doesn't have

time to triage his bugs

or her bugs, they don't

necessarily have time to

explain to you

in which case they want it closed or not

That's why it's good to

work in a team because

that's more likely you have somebody available

to help you, in doubt

Another important part is

say what you're doing

because

if people don't understand what

you're doing, they

might react badly

Make sure everybody

get the information they need

because if you're closing a bug

then the submitter gets

the information

but if you add a

tag, they don't, and

other people that answered the

bug report saying they

also got the problem, don't

get the information

so sometimes

sometimes you have to check who

provided input to the bug report

and make sure you copy them to the

mails you're sending so that they

get information

Don't write a novel

when you close or triage bugs

but give all information

so that people can understand

what you're doing, so that they have

a little bit of context and don't need

to read the whole thread

to know why you're doing it, so

in the example I gave earlier

I copy the subject

of the bug report so that they know

what was a bug report and I say

its status

that's why I take this decision, so

they have an idea what's happening

and

you can have generic messages

you don't need to innovate

each time so that you just copy and

paste and

maybe change a few words

and

since you just copy-paste

it doesn't take more time, so

write a few nice words

it helps

[laughter and applause]

Beware, there be dragons

I stopped closing bugs the last

two months because I closed one from

Ian Jackson

and it was a bad idea

and

it was such a bad idea

I lost my enthusiasm

for a few months

if you meet a bug by Ian Jackson

if everything seems

like it should be closed

or tagged, maybe

just close your tab

ignore it

just, it doesn't exist

you know

you certainly have

better things to do with you life

you do, really

I have to be frank, that's

that's him, but

there are probably others out there

but keep on

There are also very very nice people

in Debian, some that

with whom you can work

and talk and that are

helpful and nice

and welcoming

and remember: bug triaging is fun

and rewarding and easy

Well, once you started

That's it.

[applause]

Do you have questions?

I guess not, but

[Q] Hi, do you have

some other real life stories

of your adventures in bug fixing?

[laughter]

[A] Ok, I didn't

I should have open them, I

closed a bug that was

more than ten years old

That was something fun

Some submitters wrote

to me, asking for me to reopen

them, so it's not just a

technical proposition

It does

It is useful to propose to reopen for them

Lots of people thanked me, actually, which

is always nice

My maintainer friends are sometimes

jealous when I can say

"I closed 20 bugs today"

[laughter]

and they painfully closed one

I'll keep you... up to date

with new bug triaging stories

[Q] From IRC, from Peyaro

What to do with bugs tagged "patch" with a

patch sent as last message but

no response from the maintainer?

[A] You watch if the maintainer is active

in his packages

if he is, then

try to ping him again

and again

if he's not responsive

to anything, then

you should declare him

"missing in action"

You have to write to them

Well if they don't do their job properly

you can propose to help

or find somebody else to

make a non-maintainer upload

I guess

but

triaging is meant

to help maintainers so

you don't

It's not the right place to

start nagging them about the fact that

they don't do their work properly

They probably have reasons to

[Indistinctible question]

[Q] In the games team if there's a game with a bug

you send it to the mailing list, you send it to

the latest

uploader

???

contact with

[A] When I want to do what?

[Q] When you find a bug

in a package that is

maintained by a team

by a person

Can you hear me?

What a difference!

[Q] When you

are dealing with a bug that is not

maintained by just one person

but by a team

what do you usually do, you

you contact the mailing list of that

team, you contact the last uploader

[A] I put the team

in copy and not just

the uploader because

the uploader, if

the uploader belongs to a team

then they're gonna

see the e-mail on the team list

and sometimes, other are

dealing with a package also, so

[Q] Would it make sense to have

at least in some teams

some person

devolute to interfacing with the bugs and stuff

[A] I think

it's useful if teams

list themselves as welcoming

bug triagers

and if they can provide a

reference person it might

be helpful too

That's how I

started in each team, because I

was sure I had one person who would

answer my question and

tell me nicely if I fucked up

I was kind of scared to be

beaten

Yeah, it's probably useful for teams to say

"We welcome triagers and here's the person who's

willing to deal with them"

[Q] How do you do that? In a web page?

In the wiki?

just maybe a wiki page or something like that

On the bug triage documentation

I added the

teams that welcome help, so that

but games is already listed there

I listed the ones

I had experimented

But, yeah

I haven't written a contact person

because

[Q] I was thinking that maybe

thinking aloud

that maybe it would be a good entry point

for someone who wanted to join the games team

and wasn't a developer

to help triaging

bugs in that

I mean, we have a lot of games, and

[A] I have a good excuse to install

all the games on my computer because I

was trying to reproduce bugs

[Q] Exactly!

[A] I think, well

I didn't want to join teams

I'm glad to help from outside

but I think it's a good way because

you get to see

very different packages

[Q] I would mean someone more specialized

I'm talking about the games team

I could be talking about the ??? team

or the perl team

someone who's

who knows more or less

who's more specialized in the kind of

packaging the team is doing

but also is not a developer or it's not

working that closely as a developer

but could be, I mean, the place where a specialized

I don't mean as part of the

bug triaging team

I could be speaking about the fonts team

Someone inside a team that

wants to work on that

[A] That's also funny because when you do

bug triaging you also get to

read all the exchange

on the bug, so you also

kind of discover the

developers of the team

You see how they react, how they

answer to bug reports

what information they want

their level of patience

So, if you want to start contributing to

a team, that's also a good way to get

to know the people you're gonna

work with

Last one?

No. Then, there's time for a pause

[applause]