Difference between revisions of "Contribute/Bugsquad/BugDays/KonquerorDay7"

Revision as of 09:23, 20 June 2009

Introduction

Good morning! If this is the first time you're taking part in a bug triage, don't be scared by the amount of explanatory text on this page. We hope it's easily understandable - if it isn't bug us on IRC :-)

This is the page for KonquerorDay7 which starts on Saturday, June 20, 2009, but feel free to start early and feel free to keep going! The aim of this bug day is to

a) Triage: organize as many of the Konqueror bugs as possible, identifying duplicate bug reports and already fixed bugs b) Testcases: Make testcases for the rendering bugs that have been filed. c) Prioritize bugs to fix: Go through a list of websites and check how well they work. Keep an eye out for MAJOR bugs.

Our bug targets are listed in bugs.kde.org under the product konqueror. (That link gives component breakdown.)

Requirements

You don't need any programming experience to help out with Triaging, but you will need a recent version of KDE, either svn trunk (4.2.92 atm), a snapshot of it (Neon Nightly, etc.), or a recent release (eg. KDE 4.3beta2). Information on setting up KDE from trunk can be found here. If you're having trouble installing KDE, feel free to drop by on #kde-bugs early to get some help. Else, #kde-devel can always help you.

General information

• This page has useful information on how to not mis-mark bugs. In particular, "duplicates are hard". Generally we don't want to claim things are duplicates when they aren't. Make sure you get approval from a developer before you mark something a duplicate. We don't want to create more work for the developers!
• Be sure to join #kde-bugs on irc.freenode.net, as this is where the bug-day will be coordinated. (You can even join now!)

Preparations

First of all, put your name and the version of KDE/Konqueror (ie kdelibs and kdebase should be the same version) you are testing with into the Sign-in section. Then read the descriptions of the various sections to file bugs in carefully.

Junior Jobs

We are in search of bugs which are easy enough to fix for someone just starting out developing for KDE. Those kinds of bugs are called "Junior Jobs". If you think a bug sounds really easy to fix so it might qualify as a junior job, please put it in the "Junior Job Proposals" section. They will later be checked by the developers if they really fit the scheme. In case a developer is around, you might as well ask right away.

Workflow

1. Select one of the batches of bugs you'd like to do and pick it by putting your name into the appropriate column.
2. Execute the query to get the list of bugs and go through the bugs one by one.
   1. Read the bug description and the comments carefully and try to reproduce the bug.
   2. Post a comment on bugzilla explaining what you found out. Be sure to also put the version of Konqueror and Qt you are testing with in the comment.
   3. Put the bug into the appropriate section and describe your findings here as well (eg. "Can't reproduce any longer" or "This bug is still reproducible for me"). If there's something special about a bug, you can prepend a little label like eg. crash. Please mark every bug with your IRC nickname. You can easily do that by appending ~~~.
   4. Check if the bug's Version field is set properly. The version field for Konqueror's khtml bugs should always contain the original version the bug is/was reproducible with (i.e. when it was reported).
   5. Check if the bug's component is set correctly. It will be of great help when checking for duplicates. If you lack permissions to change the component or are unsure about it, please put the bugs in the "needs component change" section along with a comment.
      1. The component khtml/KJS is for the interpreter only, most Javascript bugs will fall under the khtml/ecma one.
   6. Check if the bug might qualify as a "Junior Job". If so, please put it in the "Junior Job Proposal" section.
   7. Mark the bug as triaged by adding the triaged keyword on the bug. Again if you lack the permissions to do so, additionally put it in the "Needs triaged keyword" section.
3. If you're done with your batch, pick another one and start from the top :-)

Testcases

Some bugs might have a short html file that gives an example of the bug. Add the testcase keyword. If you lack permissions to do so, additionally add the bug to the "Needs testcase keyword" section.

If it is a rendering bug, and it doesn't have one, put it in the wiki section "needs testcase" for someone to write one.

For bugs involving webpages, if the site doesn't exist anymore, check the "Wayback Machine" on http://archive.org - if you see it there, use that to come up with a testcase.

Unclear

If something has no clear instructions on how to reproduce it, or has little useful information, add a comment asking the reporter for more detail. Then list it in the bugs awaiting feedback section. Be polite, we want to be nice to our bug reporters!

Is it a big bug?

Prioritizing is good. We're especially interested in problems that result in dataloss and crashes. Let's keep track of them.

Double Check!

Please list bugs here to get a second opinion before making the change in bugzilla. This also gives a record of what we've done for the developers to check.

Keep this page updated!

After adding triaged bugs on this page, you should keep an eye on their bugzilla status. Add yourself on the CC field in bugzilla to be informed about updates. When a bug is closed on bugzilla, it should be updated on this page.

You can use the tag <s>...</s> to mark a bug as done like this.

Hints

• You can edit single sections of this page if you you check Enable section editing via edit links in your TechBase Preferences.
• Sometimes you might encounter edit conflicts if several people are working on the wiki page at once. We can mostly avoid those by keeping notes of the bugs we encounter in a text editor and file several of them later at once (don't forget to save).

 

Tip
Please be sure to sign every bug or comment you add to this page with your irc nickname. You can use the wiki markup ~~~ to insert your wiki username automatically (but only do this if it is the same as your IRC nickname, otherwise write your IRC nickname in by hand).

Common Bugs

There are some bugs which are commonly reported several times. If you found such a bug (or think you did), you can put it here:

Message list related

Sign-in

Tell developers what you are testing with. (If you expect to upgrade between now and BugDay, put what version you are using now next to the bugs/comments that you put on this page.)

Please give distro/version or SVN branch/trunk with revision below (or just beta2 if you're using that):

Division of Labour

Please choose a batch that is not already taken and then query bugs.kde.org for all bugs in that batch. Please mark you irc nickname in the table below to show which month's bugs you are working on to avoid duplication of effort.

If you have to leave before you can finish your batch, please put the last bug you triaged as well as if you're going to finish triaging in the table so others will know where you left off.

 

Warning
With these more recent bugs, if the report has been looked at by a developer (i.e. they cc'd themself or commented on it or posted a patch), and it seems like the issue is fixed, BUT the developer didn't close it, make sure the bug really can be closed. Often it can't.

khtml

The following bugs are related to displaying webpages using Konqueror.

non-khtml

The following bugs are related to anything non-html.

Bugs that need changes that require permissions

If you put a bug into this section, please be sure you additionally put it into the appropriate Completed Bugs section.

Completed Bugs

Below lists the various sections for completed bugs. This aids everyone in double checking each other's work. In addition this allows those of us that don't have bugzilla permissions to list bugs so that the folks with the permissions can follow up.