KWin/Bugzilla: Difference between revisions
Mgraesslin (talk | contribs) Proposal for new KWin Bugzilla components |
Mgraesslin (talk | contribs) + colorcorrection, + appmenu |
||
(13 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
== | == Components == | ||
The | The bugzilla product kwin has several [https://bugs.kde.org/describecomponents.cgi?product=kwin Components]. Here a short overview is peresented. | ||
=== General === | === General === | ||
Line 8: | Line 8: | ||
=== Core === | === Core === | ||
Core components include everything that is part of KWin core. | Core components include everything that is part of KWin core. | ||
==== Core | ==== Core ==== | ||
Bugs directly in the core of KWin. E.g. stacking order related | Bugs directly in the core of KWin. E.g. stacking order related | ||
Line 24: | Line 24: | ||
==== Compatability ==== | ==== Compatability ==== | ||
==== Activities ==== | |||
Everything related to Activities | |||
==== Rules ==== | |||
Everything related to KWin's window specific rules handling | |||
=== Multi Screen === | === Multi Screen === | ||
Line 42: | Line 48: | ||
==== Scene-XRender ==== | ==== Scene-XRender ==== | ||
Xrender related compositor bugs. | Xrender related compositor bugs. | ||
==== Colorcorrection ==== | |||
Bugs related to the color correction integration inside the Scene-OpenGL | |||
=== Decorations === | === Decorations === | ||
Line 50: | Line 58: | ||
==== Aurorae ==== | ==== Aurorae ==== | ||
Bugs in the Aurorae Theme Engine | Bugs in the Aurorae Theme Engine | ||
==== Appmenu ==== | |||
Bugs related to app-menu integration inside window decorations | |||
=== Effects === | === Effects === | ||
Line 58: | Line 68: | ||
Bugs in any tabbox related effects (boxswitch, coverswitch, flipswitch). | Bugs in any tabbox related effects (boxswitch, coverswitch, flipswitch). | ||
==== Effects-PresentWindows ==== | ==== Effects-Window-Management ==== | ||
Bugs in effects for window management (e.g. PresentWindows and desktop Grid). | |||
== Handling priority == | |||
For the purpose of making handling of (not so small number of) KWin bugreports simpler, each bugreport should have a priority assigned, making it possible to sort the list of bugreports and see what bugreports should be handled first. For consistent setting of priorities, these rules should be followed: | |||
=== Priorities === | |||
There are 5 priorities, VHI (highest), HI, NOR, LO, VLO: | |||
* VHI - urgent, should be handled as soon as possible. Examples: Broken trunk, stable branch often crashing for many people, basic often-used feature not working properly, etc. | |||
* HI - important, should be ideally fixed for the next release (meaning minor release, i.e. x.y.0). Examples: A crash that may happen for many people but is not critical, a basic but non-critical feature not working properly, very good idea for a new feature, etc. | |||
* NOR - the default, no priority has been assigned yet (new bugreports get this priority and should get other priority assigned) | |||
* LO - not important enough to be in the next release, low priority for when somebody will feel like fixing it. Examples: Relatively rare crash, not-often-used feature not working, feature request without important benefits, etc. | |||
* VLO - minor issues, too specific or questionable (but still reasonable enough, complete nonsense or "nobody will ever do that" should be closed with WONTFIX). | |||
A short simple way of explaining the priorities is "VHI ASAP, HI reasonably soon, LO somewhen, VLO who knows when". | |||
=== Guidelines === | |||
It is important to note that these rules are just guidelines and do not need to be strictly followed when it makes sense (for example, a minor crash that should be however simple to fix can get HI in order to be checked before next release). Specifically, the examples given are just examples and the description of the priority should be used. The main purpose of these rules is to help with handling many bugreports, not to have rules for the sake of having rules. It is not a big problem if at the time of a KDE release there are tens of HI bugreports. | |||
Wishes should use the same priorities like normal bugreports. | |||
= Flags = | |||
== Driver Specific == | |||
For each of the drivers a flag exists. This should be used to indicate that a given bug is specific for a driver. If the flag is set to "+" it means that the bug is specific to a given driver. All those flags are not requestable. | |||
=== NVIDIA === | |||
Bug is specific to the proprieatary NVIDIA driver. | |||
=== Catalyst/fglrx === | |||
Bug is specific to the proprietary ATI/AMD driver. | |||
=== Intel === | |||
Bug is specific to the Intel driver. | |||
=== r300g === | |||
Bug is specific to the Mesa driver for ATI r300 generation (Gallium driver). | |||
=== r600g === | |||
Bug is specific to the Mesa driver for ATI r600 generation (gallium driver). | |||
=== nouveau === | |||
Bug is specific to the Mesa driver for NVIDIA. | |||
=== Gallium3D === | |||
Bug is specific to any Gallium3D driver. | |||
=== Mesa === | |||
Bug is specific to any Mesa driver. | |||
== Workflow Related Flags == | |||
=== Reproducable-4.8 === | |||
A requestable flag to ask whether a user is still able to reproduce the report with KWin 4.8. If yes it should be set to "+", if not it should be set to "-". | |||
=== Reproducable-4.9 === | |||
Like Reproducable-4.9 for the next version. | |||
=== Triaged === | |||
A requestable flag to indicate whether the bug report has been triaged (put into correct category). "?" means unknown, "+" means is in correct component, "-" it is in the wrong component. | |||
=== Decision Required === | |||
A flag to be set by a developer to ask another developer for a decision. The flag is specifically requestable. | |||
=== | === Answer Required === | ||
A specifically requestable flag to ask the user for an answer (e.g. config options, better backtrace, etc.). User should set it to "+" when it has been set. As the user might be asked several times for answers the flag is multiplicable. | |||
== | === Review Request === | ||
Whether a Review Request has been created for the bug report. |
Latest revision as of 17:29, 12 November 2012
Components
The bugzilla product kwin has several Components. Here a short overview is peresented.
General
Component general for untriaged bugs or not fitting anywhere else.
Core
Core components include everything that is part of KWin core.
Core
Bugs directly in the core of KWin. E.g. stacking order related
Tabbox
Everything related to Alt+Tab except effects
Tiling
Everything related to window tiling.
Scripting
Everything related to KWin's JavaScript itnerfaces
Client Grouping
Everything related to client grouping aka window tabbing. This is the crashers in core, but not the implementation in decorations.
Compatability
Activities
Everything related to Activities
Rules
Everything related to KWin's window specific rules handling
Multi Screen
Multi screen related bugs
Multihead
As before everything to multi head (two+ X servers)
XRandR
Bugs related to XRandR (modern). General multiscreen issues should be put into this component.
Xinerama
Anything to Xinerama/Twinview (legacy).
Compositor
Compositing related bugs in the core (not effects).
Compositing
General bugs either in the effects library or it's implementation in core and scene.
Scene-OpenGL
OpenGL related compositor bugs.
Scene-XRender
Xrender related compositor bugs.
Colorcorrection
Bugs related to the color correction integration inside the Scene-OpenGL
Decorations
KDecoration
Bugs in the decoration libraries (KDecoration and KCommonDecoration) plus bugs in the bridge.
Decorations
Bugs in various decorations shipped with KWin (e.g. Plastik), but not Oxygen (has own component and product) and not Aurorae.
Aurorae
Bugs in the Aurorae Theme Engine
Bugs related to app-menu integration inside window decorations
Effects
Effects-Various
Bugs in any effects not matching into the more specialized components.
Effects-Tabbox
Bugs in any tabbox related effects (boxswitch, coverswitch, flipswitch).
Effects-Window-Management
Bugs in effects for window management (e.g. PresentWindows and desktop Grid).
Handling priority
For the purpose of making handling of (not so small number of) KWin bugreports simpler, each bugreport should have a priority assigned, making it possible to sort the list of bugreports and see what bugreports should be handled first. For consistent setting of priorities, these rules should be followed:
Priorities
There are 5 priorities, VHI (highest), HI, NOR, LO, VLO:
- VHI - urgent, should be handled as soon as possible. Examples: Broken trunk, stable branch often crashing for many people, basic often-used feature not working properly, etc.
- HI - important, should be ideally fixed for the next release (meaning minor release, i.e. x.y.0). Examples: A crash that may happen for many people but is not critical, a basic but non-critical feature not working properly, very good idea for a new feature, etc.
- NOR - the default, no priority has been assigned yet (new bugreports get this priority and should get other priority assigned)
- LO - not important enough to be in the next release, low priority for when somebody will feel like fixing it. Examples: Relatively rare crash, not-often-used feature not working, feature request without important benefits, etc.
- VLO - minor issues, too specific or questionable (but still reasonable enough, complete nonsense or "nobody will ever do that" should be closed with WONTFIX).
A short simple way of explaining the priorities is "VHI ASAP, HI reasonably soon, LO somewhen, VLO who knows when".
Guidelines
It is important to note that these rules are just guidelines and do not need to be strictly followed when it makes sense (for example, a minor crash that should be however simple to fix can get HI in order to be checked before next release). Specifically, the examples given are just examples and the description of the priority should be used. The main purpose of these rules is to help with handling many bugreports, not to have rules for the sake of having rules. It is not a big problem if at the time of a KDE release there are tens of HI bugreports.
Wishes should use the same priorities like normal bugreports.
Flags
Driver Specific
For each of the drivers a flag exists. This should be used to indicate that a given bug is specific for a driver. If the flag is set to "+" it means that the bug is specific to a given driver. All those flags are not requestable.
NVIDIA
Bug is specific to the proprieatary NVIDIA driver.
Catalyst/fglrx
Bug is specific to the proprietary ATI/AMD driver.
Intel
Bug is specific to the Intel driver.
r300g
Bug is specific to the Mesa driver for ATI r300 generation (Gallium driver).
r600g
Bug is specific to the Mesa driver for ATI r600 generation (gallium driver).
nouveau
Bug is specific to the Mesa driver for NVIDIA.
Gallium3D
Bug is specific to any Gallium3D driver.
Mesa
Bug is specific to any Mesa driver.
Workflow Related Flags
Reproducable-4.8
A requestable flag to ask whether a user is still able to reproduce the report with KWin 4.8. If yes it should be set to "+", if not it should be set to "-".
Reproducable-4.9
Like Reproducable-4.9 for the next version.
Triaged
A requestable flag to indicate whether the bug report has been triaged (put into correct category). "?" means unknown, "+" means is in correct component, "-" it is in the wrong component.
Decision Required
A flag to be set by a developer to ask another developer for a decision. The flag is specifically requestable.
Answer Required
A specifically requestable flag to ask the user for an answer (e.g. config options, better backtrace, etc.). User should set it to "+" when it has been set. As the user might be asked several times for answers the flag is multiplicable.
Review Request
Whether a Review Request has been created for the bug report.