From Fedora Project Wiki
No edit summary
No edit summary
Line 32: Line 32:
| image composing || mgracik
| image composing || mgracik
|-
|-
| iscsi || hansg (msivak for stage1)
| iscsi || akozumpl (msivak for stage1)
|-
|-
| kickstart || clumens
| kickstart || clumens
|-
|-
| livecd || akozumpl
| livecd || bcl
|-
|-
| l10n, i18n || akozumpl
| l10n, i18n || akozumpl
Line 44: Line 44:
| lvm not enough extends || rvykydal
| lvm not enough extends || rvykydal
|-
|-
| multi path || pjones
| multi path || pjones, akozumpl
|-
|-
| networking || dcantrell
| networking || dcantrell

Revision as of 13:39, 29 November 2010

Quick guide to Anaconda bug triage

The basic task is simple, go to this url, and make the list shorter :)

There are a number of ways to get bugs of this list:

  1. Close the bug if the user is just using anaconda the wrong way, or asking for a new feature we have no plans whatsoever the ever implement.

    There are tons of reasons to close bugs here as WONTFIX/NOTABUG/etc. You'll get a feel for this after examining a bunch of syslogs. If you're going to close something as WONTFIX, please be very polite and thoroughly explain why not. I feel it's better to give people a well reasoned No and close their bug than to leave their bug open forever giving them false hope.

    If you have any questions about whether we should be fixing something, or if the issue is particularly touchy (text mode, everything installs, spanning tree, etc.) feel free to ask for help.

  2. Ask for more info if the exact cause of the problem is not clear

    Be very precise in what info you ask for. Sometimes you will have to go back and forth several times. Be sure to set needinfo? at the bottom, so the bug drops off our searches and we panic about it less.

  3. Reassign to other components.

    The components you will most likely be assigning bugs to are kernel, x11-xorg-drv-<insert driver here>, yum, or rpm. There are plenty of clues in bugs that'll help you figure out which component to reassign a bug to. If you have any questions, just ask.

  4. If the bug is already fixed and a new package built

    Close it as RAWHIDE (MODIFIED if it's a RHEL bug) and put the right version into Fixed In Version: at the top of the page. If the bug is fixed but no package built, put in MODIFIED and put the next version into Fixed In Version:. This is the version of anaconda, not the version of the product.

  5. Many bugs can be closed as dupes

    If you don't know the number off the top of your head, you'll need to search. I find it's best to search anaconda bugs NEW/ASSIGNED/MODIFIED/CLOSED, assigned to anyone, with attachment data containing the string <insert something important from the bug here>. You can leave a comment in the bug when you close it if you want.

  6. If the bug seems a valid bug, assign it to an anaconda team member

    See the table below for which but to assign to whom.

Area Assignee
booty rvykdal or pjones
dmcrypt dlehman
driver disk msivak
efi pjones
exception handling clumens
fcoe hansg
image composing mgracik
iscsi akozumpl (msivak for stage1)
kickstart clumens
livecd bcl
l10n, i18n akozumpl
logging akozumpl
lvm not enough extends rvykydal
multi path pjones, akozumpl
networking dcantrell
nfs akozumpl
package install clumens
partitioning dlehman
ppc clumens
raid hansg
repo selection rvykydal
resize dcantrell
s390 dcantrell
shutdown akozumpl
stage1 msivak or pjones (network dcantrell)
time, date, timezones akozumpl
windowmanager akozumpl
install method selection rvykydal
UI clumens
isomd5sum rvykydal
network configuration rvykydal

Note experience helps with a lot of these things. You need to know the code and you need to know the bug history to really be thorough. After you wade through a couple hundred, it's all second nature.