12 | | Serious bug reporters might also want to have a look at the [http://webkit.org/quality/reporting.html steps to report a bug] and the [http://webkit.org/quality/bugwriting.html reporting guidelines] applying to the whole WebKit project. |
13 | | |
14 | | === Attached test case === |
15 | | Test cases are favored to external web site links since they are not vulnerable to external updates. |
16 | | * For a page rendering bug, a minimal HTML file is usualy efficient. |
17 | | * For bugs of more platform-related features, a zip file containing a C++ source file and a .pro file compilable by typing {{{qmake && make}}} might be required |
18 | | |
19 | | === Steps to reproduce a crash === |
20 | | Because crashes are often caused by complex conditions, it is usually difficult to provide a test case reproducing them. In that case: |
21 | | * Try to reproduce the crash more than once. Describe as best as you can the steps required to reproduce it. |
22 | | * If your can run a debug build of !QtWebKit and attach a stack trace of the crash to the bug report, this would further help the investigation.[[BR]]'''Note: ''' The debug builds of Qt do not include debugging information for !QtWebKit by default to prevent linking problems. A debug build from trunk or a nightly package of !QtWebKit is currently required to extract reliable stack traces. |
23 | | |
24 | | == Useful filters for QtWebKit bugs == |
| 28 | == Properties of a good bug report == |
| 29 | To pass through triaging and get the chance to be fixed, a bug report should contain information allowing a developer to reproduce the problem quickly and easily on different versions without having to understand the problem first. |
| 30 | If you can provide more information about a bug that got closed as invalid, please re-open it. |
| 31 | |
| 32 | Serious bug reporters might also want to have a look at the [http://webkit.org/quality/reporting.html steps to report a bug] and the [http://webkit.org/quality/bugwriting.html reporting guidelines] applying to the whole WebKit project. |
| 33 | |
| 34 | === Attached test case === |
| 35 | Test cases are favored to external web site links since they are not vulnerable to external updates. |
| 36 | * For a page rendering bug, a minimal HTML file is usualy efficient. |
| 37 | * For bugs of more platform-related features, a zip file containing a C++ source file and a .pro file compilable by typing {{{qmake && make}}} might be required |
| 38 | |
| 39 | === Steps to reproduce a crash === |
| 40 | Because crashes are often caused by complex conditions, it is usually difficult to provide a test case reproducing them. In that case: |
| 41 | * Try to reproduce the crash more than once. Describe as best as you can the steps required to reproduce it. |
| 42 | * If your can run a debug build of !QtWebKit and attach a stack trace of the crash to the bug report, this would further help the investigation.[[BR]]'''Note: ''' The debug builds of Qt do not include debugging information for !QtWebKit by default to prevent linking problems. A debug build from trunk or a nightly package of !QtWebKit is currently required to extract reliable stack traces. |
| 43 | |
| 44 | == Triaging bugs == |
| 45 | |
| 46 | [http://en.wikipedia.org/wiki/Triage Triaging] bugs basically means sorting out the good bug reports from the bad ones. It's an important step for keeping the bug database clean and maintainable. |
| 47 | |
| 48 | The following steps are used by the developers when triaging QtWebKit bugs: |
| 49 | |
| 50 | 1. Verify that the bug report has a test-case |
| 51 | * If there's no test-case, close the bug as resolved INVALID with a comment asking for more info. |
| 52 | 1. Try to reproduce the bug on your local system. Ideally you should only triage bugs that are reported against your local platform. |
| 53 | * If the bug was reported against the same platform as your own, and you could not reproduce the bug in trunk, close the bug as resolved WORKSFORME with a comment. |
| 54 | * If you cannot reproduce the bug, but your system is different than the reported one, add a comment to the bug but don't close it. It might be valid for the reported platform. |
| 55 | * If the bug was reported against a platform but you could reproduce it on another platform, change the Platform and OS fields to reflect this. |
| 56 | 1. Verify all the fields and update them if they are not accurate (in particular the Severity and Component fields) |
| 57 | 1. Set a priority for the bug |
| 58 | * P1 means the bug should ideally be fixed for the next release (typically crashes or other serious bugs) |
| 59 | * P2 means the bug is important, but not critical for a release like P1s are |
| 60 | * P3 means the bug is valid, but due to limited resources in the QtWebKit team it is considered after P1s and P2s. If a P3 bug is important to you, see the QtWebKit [https://trac.webkit.org/wiki/QtWebKitContrib contribution guidelines] on how to help getting it fixed. |
| 61 | 1. Change the assignee from webkit-unassigned@webkit.org to webkit-qt-unassigned@trolltech.com. This marks the bug as triaged, and will notify people who are watching the list of triaged bugs. |
| 62 | |
| 63 | |