Changes between Version 9 and Version 10 of QtWebKitBugs


Ignore:
Timestamp:
Mar 8, 2010 3:17:08 AM (14 years ago)
Author:
vestbo@webkit.org
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • QtWebKitBugs

    v9 v10  
    66Bugs are reported together with other ports on WebKit Bugzilla. Please use the template shortcut [http://webkit.org/new-qtwebkit-bug] to make sure that your bug report appear in the appropriate filters. For more detailed information see the [#Bugfieldsdescription bug fields description].
    77
    8 == Properties of a good bug report ==
    9 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.
    10 If you can provide more information about a bug that got closed as invalid, please re-open it.
     8=== Useful filters for QtWebKit bugs ===
    119
    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 ==
    2510 * Status filters
    2611   * [https://bugs.webkit.org/buglist.cgi?short_desc_type=allwordssubstr&short_desc=&product=WebKit&long_desc_type=allwordssubstr&long_desc=&bug_status=UNCONFIRMED&bug_status=NEW&keywords_type=allwords&keywords=Qt&order=Importance Bugs (unconfirmed or new)]
     
    4126
    4227
     28== Properties of a good bug report ==
     29To 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.
     30If you can provide more information about a bug that got closed as invalid, please re-open it.
     31
     32Serious 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 ===
     35Test 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  ===
     40Because 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
     48The 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
    4364== Bug fields description ==
    4465=== Component ===
    45 The [https://bugs.webkit.org/describecomponents.cgi?product=WebKit component] is used to signify the rough are that the bug relates to.
     66The [https://bugs.webkit.org/describecomponents.cgi?product=WebKit component] is used to signify the rough area that the bug relates to.
    4667
    4768If 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.
     
    83104This field is set by developers when scheduling and triaging tasks, please leave this at the default priority.
    84105
     106     
    85107
    86108