Changes between Version 1 and Version 2 of QtWebKitBugs

Mar 2, 2010 1:08:09 PM (13 years ago)

title size adjustment


  • QtWebKitBugs

    v1 v2  
    3 = Properties of a good bug report =
     3= Reporting and maintaining bugs for QtWebKit =
     5== Properties of a good bug report ==
    46To 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.
    57If you can add more information to a bug that got closed as invalid, please re-open it.
    79Serious 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.
    9 == Attached test case ==
     11=== Attached test case ===
    1012Test cases are favored to external web site links since they are not vulnerable to external updates.
    1113 * For a page rendering bug, a minimal HTML file is usualy efficient.
    1214 * 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
    14 == Crashes ==
     16=== Crashes ===
    1517 * TODO
    17 = Useful filters for QtWebKit bugs =
     19== Useful filters for QtWebKit bugs ==
    1820 * Status filters
    1921   * [ Bugs (unconfirmed or new)]
    2022   * [ Bugs (assigned)]
    22  * Component filter
     24 * Component filters
    2325   * [ API]
    2426   * [ Compilation]
    36 = Bug fields description =
    37 == Component ==
     38== Bug fields description ==
     39=== Component ===
    3840The [ component] is used to signify the rough are that the bug relates to.
    4244'''Note:''' the 'QtWebKit' component should be used for bugs/features in the QtWebKit ''API'' layer, '''not''' to signify that the bug is specific to the Qt port of WebKit (see Keywords]).
    44 == Severity ==
     46=== Severity ===
    4547The [ severity] is a signifier of what ''kind'' of bug we're talking about/how serious it is, and should not be confused with [ priority], ie, when it will/should be be fixed (see below).||
    5355The 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.
    55 == Platform and OS ==
     57=== Platform and OS ===
    5658Choose 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.
    5860'''Note''': These two fields should not be used to signal which ''port'' of WebKit we're dealing with, but the underlying platform and OS.
    60 == Keywords ==
     62=== Keywords ===
    6163We 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).
    6668'''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.
    68 == Version ==
     70=== Version ===
    6971Leave 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.
    71 == Priority ==
     73=== Priority ===
    7274This field is set by developers when scheduling and triaging tasks, please leave this at the default priority.