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
"done@bugs.debian.org"
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
"done@bugs.debian.org"
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]