Changes between Version 36 and Version 37 of QtWebKitBugs

Feb 12, 2013 8:48:38 AM (11 years ago)

General cleanup related to bugs now being tracked in the Qt bug tracker


  • QtWebKitBugs

    v36 v37  
    55== Where to report bugs ==
    6 Bugs are reported together with other ports on WebKit Bugzilla.[[BR]]Please create your bug report using the following link to make sure that it appears in the appropriate filters:
    7  * Template shortcut: []
     6 * [ The Qt bug tracker] if you are a !QtWebKit user
     7 * [] For in-release and auto-tests regressions, bugs that you intend to fix yourself or bugs that affect all ports of WebKit
    9 == Properties of a good bug report ==
    10 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.
    11 If you can provide more information about a bug that got closed as invalid, please re-open it.
    13 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.
    15 === Contains an attached test case ===
    16 Test cases are favored to external web site links since they are not vulnerable to external updates.
    17  * For a page rendering bug, a minimal HTML file is usualy efficient.
    18  * 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.
    20 === Lists the steps to reproduce a crash ===
    21 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:
    22  * Try to reproduce the crash more than once. Describe as best as you can the steps required to reproduce it.
    23  * 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 of WebKit trunk or a nightly package of !QtWebKit is currently required to extract reliable stack traces.
     9[ The Qt bug tracker] can also be used to report suggestions or to trac long term tasks since project management is easier to do there.
    2511== Useful filters for QtWebKit bugs ==
    3319       * [ Mac]
    3420       * [ Linux]
    35        * [ S60]
    3621   * By topic
    3722      * [ API]
    4833   * [ Meta bug to fix crashes/assertions/timeouts ]
    4934   * [ Meta bug to fix newly added but failing tests ]
    51  * Other
    52    * [ QtWebKit 2.0 Release Master Bug]
    53    * [ QtWebKit 2.1 Release Master Bug]
    54    * [ QtWebKit 2.1 Pending API]
    5636== Triaging bugs ==
    7151     * P2 means the bug is important, but not critical for a release like P1s are
    7252     * 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.
    73   1. If the status is UNCONFIRMED, set it to NEW.
    74   1. Add the keyword "'''QtTriaged'''".
    7654The table for the weekly bug triage task force (WTTF) is maintained in a separate wiki page: [wiki:QtWebKitTriageRoster QtWebKitTriageRoster].
    77 You can use the first filter in the "Useful filters" section above to start the triaging.
    7956The [wiki:QtWebKitWeeklyBuilds Weekly Builds] may be of help when trying to reproduce bugs on other platforms.
    12097=== Priority ===
    12198This field is set by developers when scheduling and triaging tasks, please leave this at the default priority.