Jump to content

Krita/Docs/Bug Hunting Day: Difference between revisions

From KDE Community Wiki
Dmitry (talk | contribs)
Dmitry (talk | contribs)
No edit summary
Line 14: Line 14:


# Update your Krita to the latest testing version using Krita Lime or any other method you prefer. See this [http://nonaynever.ru/kwiki/krita/MostRecentBuilds manual] on getting the latest testing build.
# Update your Krita to the latest testing version using Krita Lime or any other method you prefer. See this [http://nonaynever.ru/kwiki/krita/MostRecentBuilds manual] on getting the latest testing build.
# Backup and reset your Krita configuration files and resources (see [http://nonaynever.ru/kwiki/krita/ResetKritaConfiguration manual])
# Read [http://nonaynever.ru/kwiki/krita/BugWritingGuidelines Bug Writing Guidelines] to see what info is usually needed in the bug report
# Write or update your name and system configuration in this [https://docs.google.com/spreadsheets/d/1mJ9SPclalprjVj9Lruu1ihrmjFAGeb6iiUjdjUqqAFI/edit#gid=0 spreadsheet]. The info is needed so the developer would know how system/hardware influence the bug.
# Write or update your name and system configuration in this [https://docs.google.com/spreadsheets/d/1mJ9SPclalprjVj9Lruu1ihrmjFAGeb6iiUjdjUqqAFI/edit#gid=0 spreadsheet]. The info is needed so the developer would know how system/hardware influence the bug.
# Ask developers to assign you bugs in this [https://docs.google.com/spreadsheets/d/1AzHmhqqD6JUm_xs2MoGXbgcM4R6Ldt65y-mfP_sXdvI/edit#gid=0 spreadsheet]. The assigned bugs will be selected with a color and a comment.
# Ask developers to assign you bugs in this [https://docs.google.com/spreadsheets/d/1AzHmhqqD6JUm_xs2MoGXbgcM4R6Ldt65y-mfP_sXdvI/edit#gid=0 spreadsheet]. The assigned bugs will be selected with a color and a comment.
# Walk through the bugs and try to reproduce them on your system. You can add comments, ask the reporter about more info and do whatever you think is needed with this bug. You can consult [http://nonaynever.ru/kwiki/krita/BugWritingGuidelines Bug Writing Guidelines] to see what additional info might be needed to reproduce/fix a bug.
# Walk through the bugs and try to reproduce them on your system. You can add comments, ask the reporter about more info and do whatever you think is needed with this bug. You can consult [http://nonaynever.ru/kwiki/krita/BugWritingGuidelines Guidelines] to see what additional info might be needed to reproduce/fix a bug.
# If you managed to reproduce a bug on your computer, you are lucky! Ensure the bugreport has enough information to reproduce it (consult the [http://nonaynever.ru/kwiki/krita/BugWritingGuidelines Guidelines] again). If you have something to add to the bugreport, do it! Remember: steps to reproduce are the most important part of most of the bugs. In the end add a comment to a corresponding cell in the spreadsheet, telling that you reproduced the bug.
# If you managed to reproduce a bug on your computer, you are lucky! Ensure the bugreport has enough information to reproduce it (consult the [http://nonaynever.ru/kwiki/krita/BugWritingGuidelines Guidelines] again). If you have something to add to the bugreport, do it! Remember: steps to reproduce are the most important part of most of the bugs. In the end add a comment to a corresponding cell in the spreadsheet, telling that you reproduced the bug.
# If you cannot reproduce it, that is not so bad. Just write so in a spreadsheet and move further.
# If you cannot reproduce it, that is not so bad. Just write so in a spreadsheet and move further.
Line 25: Line 27:
The main task for developers is to coordinate the work of hunters and have the final word on changing the status of the bugs. The final status assignment can happen when the day is ended based on the contents of the spreadsheet.
The main task for developers is to coordinate the work of hunters and have the final word on changing the status of the bugs. The final status assignment can happen when the day is ended based on the contents of the spreadsheet.


The
The steps for the developers are quite boresome:
 
# Create two spreadsheets for the hunters and assign tasks to them
# If a hunter (who is not a reporter) told the bug is reproducible, check whether the bugreport contains enough info (see [http://nonaynever.ru/kwiki/krita/BugWritingGuidelines guidelines]) and mark it as CONFIRMED
# If a hunter did not managed to reproduce the bug, ask another hunter with a different system configuration to test it
# If no hunters managed to reproduce a bug, mark it either as NEEDSINFO or WORKSFORME
# Repeat until you have no UNCONFIRMED bugs left.

Revision as of 11:23, 15 June 2015

Goals

The main goal of a Bug Hunting Day is to ensure that all the current bug reports are valid and the developers have enough information for fixing them. By the end of the day we should ensure that:

  1. all the CONFIRMED bugs are reproducible on the current version of Krita by at least one person except the reporter and has enough information to be reproduced by a developer
  2. the amount of UNCONFIRMED bugs drops to zero, that is we should triage all (optimistically) such bugs into CONFIRMED or NEEDSINFO
  3. if noone can reproduce a bug, we keep it UNCONFIRMED or mark as NEEDSINFO.

Roles

There are two groups of people involved: Bug Hunters, Developers.

Bug Hunters

Bug hunters are the main force of a hunting day. They test the bugs on bugzilla and write the their verdict. If you would like to be a hunter, please follow these simple steps:

  1. Update your Krita to the latest testing version using Krita Lime or any other method you prefer. See this manual on getting the latest testing build.
  2. Backup and reset your Krita configuration files and resources (see manual)
  3. Read Bug Writing Guidelines to see what info is usually needed in the bug report
  4. Write or update your name and system configuration in this spreadsheet. The info is needed so the developer would know how system/hardware influence the bug.
  5. Ask developers to assign you bugs in this spreadsheet. The assigned bugs will be selected with a color and a comment.
  6. Walk through the bugs and try to reproduce them on your system. You can add comments, ask the reporter about more info and do whatever you think is needed with this bug. You can consult Guidelines to see what additional info might be needed to reproduce/fix a bug.
  7. If you managed to reproduce a bug on your computer, you are lucky! Ensure the bugreport has enough information to reproduce it (consult the Guidelines again). If you have something to add to the bugreport, do it! Remember: steps to reproduce are the most important part of most of the bugs. In the end add a comment to a corresponding cell in the spreadsheet, telling that you reproduced the bug.
  8. If you cannot reproduce it, that is not so bad. Just write so in a spreadsheet and move further.
  9. When you are done with your bugs, you can walk through the other non-reproducible bugs in the spreadsheet. Probably, you are lucky and on your system you can see the bugs that others cannot see! :)

Developers

The main task for developers is to coordinate the work of hunters and have the final word on changing the status of the bugs. The final status assignment can happen when the day is ended based on the contents of the spreadsheet.

The steps for the developers are quite boresome:

  1. Create two spreadsheets for the hunters and assign tasks to them
  2. If a hunter (who is not a reporter) told the bug is reproducible, check whether the bugreport contains enough info (see guidelines) and mark it as CONFIRMED
  3. If a hunter did not managed to reproduce the bug, ask another hunter with a different system configuration to test it
  4. If no hunters managed to reproduce a bug, mark it either as NEEDSINFO or WORKSFORME
  5. Repeat until you have no UNCONFIRMED bugs left.