| Version 27 (modified by , 15 years ago) ( diff ) |
|---|
Reporting and maintaining bugs for QtWebKit
Where to report bugs
Bugs are reported together with other ports on WebKit Bugzilla.
Please create your bug report using the following link to make sure that it appears in the appropriate filters:
- Template shortcut: http://webkit.org/new-qtwebkit-bug
Properties of a good bug report
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. If you can provide more information about a bug that got closed as invalid, please re-open it.
Serious bug reporters might also want to have a look at the steps to report a bug and the reporting guidelines applying to the whole WebKit project.
Contains an attached test case
Test cases are favored to external web site links since they are not vulnerable to external updates.
- For a page rendering bug, a minimal HTML file is usualy efficient.
- For bugs of more platform-related features, a zip file containing a C++ source file and a .pro file compilable by typing
qmake && makemight be required.
Lists the steps to reproduce a crash
Because crashes are often caused by complex conditions, it might be difficult to provide a test case to attach reproducing them 100% of the time. In that case:
- Try to reproduce the crash more than once. Describe as best as you can the steps required to reproduce it.
- 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.
Note: The debug builds of Qt do not include debugging information for QtWebKit by default to prevent linking problems. A debug build of WebKit trunk or a nightly package of QtWebKit is currently required to extract reliable stack traces.
Useful filters for QtWebKit bugs
- Triaged bugs
- All
- By platform
- By topic
Triaging bugs
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.
The following steps are used by the developers when triaging QtWebKit bugs:
- Verify that the bug report has a test-case
- If there's no test-case, close the bug as resolved INVALID with a comment asking for more info.
- Try to reproduce the bug on your local system. Ideally you should only triage bugs that are reported against your local platform.
- 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.
- 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.
- 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.
- Verify all the fields and update them if they are not accurate (in particular the Severity and Component fields)
- Set a priority for the bug
- P1 means the bug should ideally be fixed for the next release (typically crashes or other serious bugs)
- P2 means the bug is important, but not critical for a release like P1s are
- 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 contribution guidelines on how to help getting it fixed.
- If the status is UNCONFIRMED, set it to NEW.
- Add the keyword "Triaged".
The table for the weekly bug triage task force (WTTF) is maintained in a separate wiki page: QtWebKitTriageRoster
Bug fields description
Component
The component is used to signify the rough area that the bug relates to.
If you don't know which one to choose leave the component at 'New Bug'. It's better to leave it at 'New Bug' than to choose one at random.
Note: the 'QtWebKit' component should only be used for bugs/features in the public QtWebKit API layer, not to signify that the bug is specific to the Qt port of WebKit (see Keywords]).
Severity
Use the following rules of thumb when deciding on a severity:
- Use 'Blocker' for compilation errors/build breaks
- Use 'Critical' for crashes, loss of data, severe memory leak
- Use 'Enhancement' for feature-requests/enhancements
The severities 'Minor, Normal, Major' should then be used for "normal" bugs which don't fall into either of these categories, ranging from minor loss of function, or other problem where easy workaround is present, to major loss of function.
Platform and OS
Choose the settings most relevant to where you found the bug, or 'All' if you've confirmed that the bug exists on more than one platform.
Note: These two fields should not be used to signal which port of WebKit we're dealing with, but the underlying platform and OS.
Summary
Choose a descriptive summary/title for the bug and prefix the summary with "[Qt]" if the bug only applies to the Qt-port.
Keywords
We need a way to track bugs that are specific for the Qt port of WebKit. The right way to do this is using the 'Qt' keyword (you may not see the keywords entry field until after creating the bug. If so, please add the keyword after creating the bug).
- Add the keyword 'Qt' to signal that it's a Qt-related bug
- Add the keyword 'Performance' if the bug is performance-related
Note: Do not use the 'QtWebKit' component to signal that it's a Qt bug. The QtWebKit component is used for bugs/features in the QtWebKit API layer, not to signify that the bug is a Qt-bug in general.
Version
Leave at 'nightly build'. You should always test a bug against a nightly build of QtWebKit to make sure that it's still valid before reporting.
Priority
This field is set by developers when scheduling and triaging tasks, please leave this at the default priority.
