| 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 | |
