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 control@bugs.debian.org
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.