Return to Video

Learn how to triage bugs

  • 0:05 - 0:07
    I'm Solveig.
  • 0:08 - 0:10
    Here you have my contact info.
  • 0:13 - 0:19
    I use Free Software and especially Debian
    since quite some time now
  • 0:19 - 0:22
    and I also contribute to Tails
  • 0:23 - 0:29
    so my interests are in privacy…
  • 0:44 - 0:47
    No? Yes? Do you hear me?
  • 0:53 - 0:57
    I do some non-developer things
  • 0:57 - 1:03
    and in Debian I found a way to contribute
    without coding
  • 1:04 - 1:07
    or maintaining packages which is to
    triage bugs.
  • 1:12 - 1:15
    Bug triaging, it helps,
  • 1:15 - 1:22
    it's kind of non visible but it helps
    Debian as a whole
  • 1:22 - 1:27
    because maintainers don't always
    have the time to deal
  • 1:27 - 1:28
    with all their bug reports,
  • 1:29 - 1:31
    some packages have a lot of
    bug reports,
  • 1:32 - 1:36
    like the kernel or Xorg.
  • 1:40 - 1:45
    Also, it's a good way to improve the
    package quality.
  • 1:45 - 1:50
    When some packages have a lot of
    bugs open against them,
  • 1:52 - 1:57
    it can make it harder for the maintainers
    to know which ones are
  • 1:57 - 2:03
    solvable, actionable, and they can get a bit
    over their head.
  • 2:04 - 2:11
    So when you triage bugs, you help
    everybody have a better experience
  • 2:11 - 2:12
    with Debian.
  • 2:14 - 2:16
    So, you want to do it.
  • 2:17 - 2:19
    First, it's easy.
  • 2:19 - 2:23
    You don't need to learn any new tool
    supposing you already know
  • 2:23 - 2:25
    how to read and write e-mail.
  • 2:27 - 2:32
    So that's a low threshold to start.
  • 2:33 - 2:38
    It's very rewarding, the maintainers are
    happy when you help them,
  • 2:38 - 2:41
    even if you don't touch their packages,
  • 2:41 - 2:49
    if you sort their bugs, they'll be happy
    and the users who submitted them
  • 2:49 - 2:51
    will be happy that somebody looked
    at them
  • 2:52 - 2:56
    so it can be very joyful.
  • 2:58 - 3:03
    Also, you search random bugs for packages
    you don't necessarily know,
  • 3:04 - 3:08
    so you learn about a lot of software
    in Debian and
  • 3:08 - 3:12
    some of them are really really surprising
    and you…
  • 3:13 - 3:16
    "Wha? What does this do?" and that's kind
    of fun.
  • 3:18 - 3:20
    And of course, it saves kittens.
  • 3:26 - 3:29
    On this page, there's a…
  • 3:31 - 3:36
    The bug triage page is a howto page
    I made some years ago, with tips
  • 3:37 - 3:43
    and this part, especially, has a list
    of teams that added themselves
  • 3:43 - 3:47
    so that they want you to help
    sort their bugs.
  • 3:49 - 3:52
    Those are the teams I worked with,
    they're really really nice,
  • 3:53 - 3:54
    they don't bite.
  • 3:57 - 3:59
    They will let you know if you did an error,
  • 3:59 - 4:03
    they will answer your questions,
    you can work together.
  • 4:05 - 4:08
    I don't recommend closing random bugs.
  • 4:08 - 4:13
    If you go and touch packages from people
    you have not warned
  • 4:13 - 4:17
    or who are not willing to have somebody
    touch their bugs,
  • 4:17 - 4:20
    you might have backfire.
  • 4:23 - 4:28
    To start, I think it's good to go packages
    that you know people are happy
  • 4:28 - 4:29
    if you help with.
  • 4:35 - 4:38
    The first tool to triage bugs is UDD.
  • 4:40 - 4:47
    I don't know if you've ever tried it,
    the interface is really great.
  • 4:56 - 4:58
    Here, I can show you.
  • 5:02 - 5:04
    Here, that's UDD.
  • 5:07 - 5:09
    So it's a bit arid like this, but
  • 5:14 - 5:22
    it allows you to select many many
    types of packages,
  • 5:23 - 5:26
    we can see that later.
  • 5:26 - 5:32
    Then you can choose a team or
    other criteria
  • 5:33 - 5:38
    and when you're happy about
    your criteria, you search.
  • 5:39 - 5:45
    It will give you a list of packages
    corresponding to your criteria
  • 5:47 - 5:51
    and you can select some more info
    you want listed here.
  • 5:54 - 5:56
    So, that's UDD search.
  • 6:02 - 6:09
    I usually ignore the bug reports that
    somebody has searched in the last year.
  • 6:12 - 6:14
    Probably somebody else will look at them,
  • 6:14 - 6:18
    let's look at those that are lost
    in the limbos.
  • 6:19 - 6:24
    I select wontfix, moreinfo, upstream or
  • 6:24 - 6:28
    Those are those that probably you can do
    something on.
  • 6:30 - 6:34
    And then you chose a team, preferably
    one of those that is listed
  • 6:34 - 6:36
    in the page we saw before.
  • 6:45 - 6:50
    Once you'll have selected a bug and
    something to do on it,
  • 6:50 - 6:53
    you'll have to document what you do.
  • 6:57 - 7:00
    Because you can change many many stuff
    on the bug,
  • 7:00 - 7:07
    you send the commands to
  • 7:07 - 7:12
    but it's always nice to put a small
    a small sentence, or 2 or 3
  • 7:12 - 7:18
    to say what made you conclude that is
    the right change.
  • 7:22 - 7:26
    Also make sure the e-mail where you do
    the commands is sent
  • 7:26 - 7:32
    to everybody interested, because
    by default it only sends it
  • 7:32 - 7:36
    to the maintainer and the submitter
    in some cases.
  • 7:37 - 7:40
    So if other people answered the bug
    report saying
  • 7:40 - 7:48
    "Hey, I have the bug too" or if upstream
    came by to explain something,
  • 7:48 - 7:53
    it's good to see all of those who
    interacted on the bug report and
  • 7:53 - 7:55
    put them all in copy.
  • 8:01 - 8:08
    Ideally, people can receive the e-mail,
    read what you're saying and
  • 8:08 - 8:12
    don't have to go back to the bug page
    to read it again.
  • 8:13 - 8:20
    So that you should sum up the thread
    if it was long and have them know everything.
  • 8:29 - 8:35
    If you do massive triage, you should have
    a few generic messages
  • 8:35 - 8:41
    so you keep the messages and just
    replace the words as needed.
  • 8:41 - 8:44
    It saves you a lot of time.
  • 8:45 - 8:51
    Also, it allows you to put a lot of
    nice things in your generic e-mail
  • 8:51 - 8:54
    that people are always happy to read
    without more effort.
  • 8:55 - 8:58
    You know, add a little "Thanks for
    submitting the bug" or
  • 8:58 - 9:04
    "That was a very interesting discussion"
    or something like that.
  • 9:06 - 9:10
    Let's keep the positive energy flowing.
  • 9:13 - 9:18
    There are many ways to triage.
  • 9:18 - 9:21
    One of them is trying to reproduce
    bug reports.
  • 9:22 - 9:26
    In the UDD we saw earlier, if you select
  • 9:26 - 9:30
    Oh no… those that don't have the tag
  • 9:31 - 9:37
    these are bugs that one person submitted
    but nobody knows if they're really
  • 9:37 - 9:42
    still up to date or if it's just, somebody
    submitted it but…
  • 9:44 - 9:48
    If it's confirmed, there's more chance
    that the maintainer will look at them.
  • 9:50 - 9:54
    If they're really old, maybe they have been
    corrected and nobody bothered
  • 9:54 - 9:55
    to close the bug.
  • 9:57 - 10:03
    If they're new, maybe you should have
    them too, so see if it's the case.
  • 10:04 - 10:07
    If it's the case, you write to this adress
  • 10:07 - 10:16
    the 'nnn' is the number of the bug and
    you add the tag 'confirmed'
  • 10:17 - 10:23
    That's how we interact with control@b.d.o
  • 10:24 - 10:30
    All the bug tracking is on a e-mail
  • 10:31 - 10:34
    'found bugnumber versionnumber'
  • 10:36 - 10:40
    that's a command that control will
  • 10:40 - 10:43
    you give the bug number and what version
    you're running.
  • 10:44 - 10:48
    You add the tag 'confirmed'.
  • 10:48 - 10:51
    Since you found it, you're 2, so it's
  • 10:51 - 10:56
    And 'thanks', you always have to end
    your e-mails to control with 'thanks'
  • 10:56 - 11:00
    or 'thank you' or whatever variation
    of it you want.
  • 11:01 - 11:06
    The control is a very very polite beast
    and likes you to be the same.
  • 11:08 - 11:12
    If you don't put politeness, it won't work.
  • 11:13 - 11:17
    Actually it's to tell them that the commands
    are done, but
  • 11:17 - 11:20
    let's be polite also with machines.
  • 11:27 - 11:35
    If the bug was not confirmed, you tried
    to reproduce it and you couldn't.
  • 11:37 - 11:44
    You could add the tag 'unreproducible' or
  • 11:45 - 11:50
    So, depending if you're quite sure that…
    if you're not the first saying
  • 11:50 - 11:55
    "I can't reproduce it" or if you're sure
    you have exactly the same setup as
  • 11:55 - 11:56
    the original submitter,
  • 11:56 - 11:59
    then you should put 'unreproducible'.
  • Not Synced
    If it might be reproducible for other
    people, but just not you,
  • Not Synced
    then you should ask 'moreinfo' so that
    the original submitter gives
  • Not Synced
    more details on how to reproduce their bug
  • Not Synced
    And it also requires you to be polite
    at the end of the command.
  • Not Synced
    An other very useful thing is to forward
    them upstream.
  • Not Synced
    Some upstream follow the Debian bug tracker
  • Not Synced
    but a lot of them don't.
  • Not Synced
    Maybe somebody reported the issue in
    the Debian bug tracker but
  • Not Synced
    upstream is not aware of it
  • Not Synced
    and most Debian maintainers are not
    gonna solve the bug themselves,
  • Not Synced
    they're more probably gonna wait for it
    to be corrected upstream,
  • Not Synced
    so we need the bug to go back to where
    it will be corrected
  • Not Synced
    In a lot of cases, it can be because
    upstream considers it not a bug,
  • Not Synced
    so won't fix it, so let's say it on the
    Debian bug too
  • Not Synced
    or maybe upstream is not aware of
    the bug so…
  • Not Synced
    Ok, that's very tiny…
  • Not Synced
    At least you have all.
  • Not Synced
    Here you have the command to add
    the upstream bug tracker number.
  • Not Synced
    "forwarded bugnumber", you put the URL
    in the upstream's bug tracker
  • Not Synced
    and then you say thanks again.
  • Not Synced
    So that's what I was saying before, you
    can also report it upstream
  • Not Synced
    if it hasn't been already.
  • Not Synced
    Sometimes, the upstream bug tracker
    is more up to date,
  • Not Synced
    so in upstream it's fixed, so it's good
    to let know to the Debian bug tracker
  • Not Synced
    and add the tag 'fixedupstream'
  • Not Synced
    and it's good to say in which version
    so that the maintainer may be
  • Not Synced
    motivated to update to the new version.
  • Not Synced
    In lot of cases, the bug reports are tagged
    'moreinfo', which is
  • Not Synced
    somebody said "It doesn't work", which,
    sorry for you, but there's no chance
  • Not Synced
    it's gonna be fixed with that.
  • Not Synced
    So in lots of cases, the bug is tagged
    'moreinfo' to say
  • Not Synced
    "This bug does not give enough info
    to be solved"
  • Not Synced
    Or sometimes, the maintainer
    packages a new version
  • Not Synced
    and you think probably the bug is
  • Not Synced
    and you also need to ask the original
    submitter if they still have the bug
  • Not Synced
    Or somebody said "Oh I'm gonna to some
    fix next weekend" and it's 2 years later
  • Not Synced
    and you're not sure they actually did
    the test they were saying they would do.
  • Not Synced
    So, info were asked and it feels like
    the bug is hanging.
  • Not Synced
    In those cases, it's helpful, sometimes,
    to send an e-mail to the person who said
  • Not Synced
    "I'm gonna do something" or who needs to
    answer if they still have the bug
  • Not Synced
    and saying "Hey! that's a gentle ping"
  • Not Synced
    "You said you would test" or "Can you still
    reproduce a bug?"
  • Not Synced
    so that you can update the status of the
    bug on the bug tracker.
  • Not Synced
    It's good to wait, like, a good amount of
    time before bothering people
  • Not Synced
    about this kind of thing.
  • Not Synced
    I usually wait one year, like I told you,
    probably shorter might be good,
  • Not Synced
    but it's good also not to harass people,
    they have a life.
  • Not Synced
    Sometimes, the bugs have been tagged
    'moreinfo' or 'wontfix' for a long time
  • Not Synced
    The info is not given, or it's unlikely
    that somebody else wants
  • Not Synced
    this 'non-bug' fixed.
  • Not Synced
    Different teams have different policies
    but most of them will be happy
  • Not Synced
    if you close the bugs that nobody is gonna
    do anything about.
  • Not Synced
    If the bug was tagged 'moreinfo' more than
    a year ago and
  • Not Synced
    nobody answered to give more info, or if
    a major release came out and
  • Not Synced
    probably the bug is fixed but the original
    submitter doesn't answer
  • Not Synced
    then it's good to close them, in most
    cases, depending on the team.
  • Not Synced
    But it's good to ping them before you
  • Not Synced
    give them a reasonable amount of time
    to try to test it again.
  • Not Synced
    Ok, we don't have the bottom of the page.
  • Not Synced
    The command to…
  • Not Synced
    The command to close a bug is to write to
  • Not Synced
    Maybe I shouldn't have done that.
  • Not Synced
    And closing the bugs is kind of one of
    the most satisfying things to do.
  • Not Synced
    Sometimes, I speak with my maintainer
    friends and I say
  • Not Synced
    "Hey, I closed 25 bugs today" and they're
    kind of jealous because
  • Not Synced
    when you have to actually work on the bugs
    to close them,
  • Not Synced
    you can rarely fix 25 in one day.
  • Not Synced
    So it's kind of the perks of doing
    bug triaging.
  • Not Synced
    You know, less bugs on the bug tracker,
    I'm very efficient today.
  • Not Synced
    But don't close random stuff, but when
    you find useless stuff to close,
  • Not Synced
    it feels good.
  • Not Synced
    Where am I?
  • Not Synced
    We missed the last sentence earlier.
  • Not Synced
    When trying to reproduce a bug, you
    should pay particularly attention to
  • Not Synced
    the games team.
  • Not Synced
    You know, like, people open bug reports
    against the game team and then
  • Not Synced
    Oh no, you have to install a bunch of
    games to try to reproduce bugs,
  • Not Synced
    you know, but for work, so you install
    a lot of games and
  • Not Synced
    you try to see if they're buggy, so that's
    also another perk of triaging bugs,
  • Not Synced
    you get to try all the latest games.
  • Not Synced
    An other thing is when people open a bug
    and didn't check if there was
  • Not Synced
    already one open.
  • Not Synced
    It ends up being 2 reports for the same bug.
  • Not Synced
    It's good to merge them so that's clearer.
  • Not Synced
    The 2 bug reports must be on the same
    package, with the same severity
  • Not Synced
    and the same state,
  • Not Synced
    otherwise you can't merge, so you have
    to send first the commands to do that,
  • Not Synced
    like I showed before, and at the end you
    tell the bug tracker to merge.
  • Not Synced
    So, that we've seen.
  • Not Synced
    You can…
  • Not Synced
    Ok, you can't really see the…
  • Not Synced
    So, I was giving an example of my standard
    message I paste when I close a bug
  • Not Synced
    and we don't see the end, but I'm gonna
    do it from memory, it says
  • Not Synced
    "Hi! I'm closing this bug, since it was
    tagged 'moreinfo' for years
  • Not Synced
    without answer. If you still experience
    the issue, please feel free to reopen it
  • Not Synced
    or ask me to do it" because some people
    don't know how to reopen a bug
  • Not Synced
    that has been archived.
  • Not Synced
    So that's a very standard message,
    no nothing, it's not very long.
  • Not Synced
    That is good to have a model so that
    you can just paste, with niceness in it.
  • Not Synced
    If you're not sure about a bug report,
  • Not Synced
    you read through it and you're still
    not sure what to do
  • Not Synced
    because, let's be clear, I don't always
    understand what the issue is.
  • Not Synced
    What you need to understand to triage
    is what the status of the bug report is.
  • Not Synced
    I triaged bugs for the kernel.
  • Not Synced
    I don't understand anything about
    the kernel, like most human beings
  • Not Synced
    but, without understanding the bug report,
    you can understand if somebody asks
  • Not Synced
    for info and nobody provided it
  • Not Synced
    or, for example, for the kernel, all the
    bug reports that were for the nouveau driver
  • Not Synced
    that is not supported anymore,
  • Not Synced
    it was possible to close them because
    nobody cared anymore.
  • Not Synced
    So you don't necessarily need to understand
    what the bug is about
  • Not Synced
    to do something about the bug report
  • Not Synced
    but sometimes it's a bit more complicated,
    you're not sure
  • Not Synced
    just close the bug report, move to the
    next one
  • Not Synced
    There's probably an other one that's,
    you know, low hanging
  • Not Synced
    take the easy stuff.
  • Not Synced
    Because if you do something wrong, or
    if you bother the maintainer to ask
  • Not Synced
    what should be done, then you're not
    really helping,
  • Not Synced
    you might be taking time from them that
    would be best invested somewhere else.
  • Not Synced
    Small warning, there are some people who
    really don't like you touching
  • Not Synced
    their bug reports.
  • Not Synced
    I wish you not to encounter them.
  • Not Synced
    I you do, just either ignore them or ask
    the maintainers of the package you're triaging
  • Not Synced
    to step in and help or you can also
    contact the anti-harassment team.
  • Not Synced
    But it's very rare and most of Debian
    people are very nice people
  • Not Synced
    and they'll be happy to cooperate and
    discuss with you
  • Not Synced
    and bug triaging is fun and rewarding
    and easy.
  • Not Synced
    Those are the links to the things that
    are useful to triage.
  • Not Synced
    The first one is…
  • Not Synced
    Ok, the first one is bad, I'll correct it.
  • Not Synced
    The second one is how to triage with
    all the different commands
  • Not Synced
    that are useful.
  • Not Synced
    The third one is server control,
  • Not Synced
    a reminder of all the different instructions
    you can send to server control
  • Not Synced
    which is the way to interact with
    a bug report.
  • Not Synced
    The last one is about only closing and
    you don't interact with control,
  • Not Synced
    you write to bugnumber-done, so that's
    a different e-mail destination.
  • Not Synced
    So, the idea was to have a workshop,
    so this was the explanation part and now
  • Not Synced
    let's close some bugs, or sort them,
Learn how to triage bugs

Talk given by Solveig at Debconf18

more » « less
Video Language:

English subtitles


Revisions Compare revisions