openSUSE:Bug Screening KDE

Jump to: navigation, search

KDE Bugreport Screening

General

This page is about helping with bugreports about KDE reported at openSUSE bugzilla. For reporting bugreports go to openSUSE:Bugreport_KDE (but you should read that page also if you want to help with screening).

OpenSUSE provides KDE, including testing and making various modifications. KDE is however primarily developed upstream by the KDE project and while the openSUSE KDE team contributes to KDE, it is not possible for them to take care of every single KDE problem due to limited resources (the team is relatively small). Therefore it is important to keep KDE bugreports reported for openSUSE at a reasonable amount that can be handled by the openSUSE KDE team. You can help by screening KDE bugreports. No specific knowledge is required other than information provided by this page and the openSUSE:Bugreport_KDE page, specifically it is not necessary to be a developer. By helping with bugreports you can reduce the time openSUSE KDE developers have to spend with them, allowing them to focus on improving the KDE provided by openSUSE.

This page first explains some important concepts about KDE bugreports for openSUSE and then provides a step-by-step guideline for helping with bugzilla screening.

Concepts

Bugreport organization in bugzilla

All new KDE bugreports for openSUSE (i.e. the ones with the KDE/KDE3/KDE4 component) are initially assigned to a shared kde-maintainers@suse.de alias that is watched by all openSUSE KDE developers. This is where the initial screening should take place.

Each openSUSE KDE developer has their own personal bugzilla account, where they reassign bugreports they plan to work on soon or that are their expert area. Most bugreports are however kept in the shared kde-maintainers@suse.de list.

You can watch any bugzilla account in Novell bugzilla by adding it to the list in Preferences->Email Preferences, near the bottom of the page. For watching changes in shared bugreports, including all new KDE bugreports, add 'kde-maintainers@suse.de'.

Bugreport priorities

Bugreports in Novell bugzilla are sorted using priorities to give a better overview of the status and make it easier for developers to see in what order they should work on the bugreports. There is a specific page explaining the priorities at openSUSE:Bug_definitions, please read it to understand how priorities should be assigned to bugreports. Priorities should be primarily set by developers, but experienced community members can help by setting them too. Developers still have a higher priority, so please do not change priority set by a developer. Also, if you do not have much experience yet, please be careful with setting priorities. It is safer if you do not set priorities at the beginning and start doing so only after seeing how priorities are set by others.

Upstream vs downstream

Upstream in this context means the KDE project, with the KDE bugzilla at http://bugs.kde.org. Downstream here means openSUSE, with the Novell bugzilla at http://bugzilla.opensuse.org.

The basic rule for KDE bugreports in Novell bugzilla is that only either openSUSE-specific or important problems should be reported and kept there. OpenSUSE-specific means packaging, applications, tools, desktop components or their modifications done by openSUSE KDE developers, since they are work of openSUSE KDE developers, they do not belong to upstream bugzilla. Important problems, in this context, means problems that are important for the KDE desktop openSUSE experience and can affect many users or have a very negative impact (technically, bugreports with priorities P2 and above). Other KDE bugreports should be forwarded to upstream bugzilla and closed in Novell bugzilla with RESOLVED UPSTREAM.

See this page for a list of KDE modifications done by openSUSE. If unsure whether a bugreport is or is not openSUSE-specific, consider the bugreport openSUSE-specific (and possibly later somebody else will decide otherwise).

Repositories

These rules are primarily for KDE as shipped with openSUSE releases (including online updates). For KDE provided in additional repositories there are these differences:

  • KDE:Release:XY - this is used to prepare minor version updates to the latest stable openSUSE release and other pending online updates. Therefore these rules apply the same way.
  • KDE:Distro:Factory - this repository provides KDE that will be part of the next stable openSUSE release. Therefore it becomes more important only when nearing that release and otherwise bugreports for packages from it should be upstreamed more aggressively, as there is a fair chance that upstream will fix them in time for the release.
  • KDE:UNSTABLE:SC - this is the latest unstable KDE. Only openSUSE-specific packaging bugreports should be accepted.

Communication

You can reach members of the openSUSE KDE team at places explained in the [main KDE page]. If you have any questions or problems with bugzilla screening, you can ask others there.

Bugreport status

New bugreports are created with the state NEW. Bugreports should stay in this state until they have been properly triaged and are ready to be handled by a developer (or closed, of course). When all is needed for a bugreport is a developer to fix it and it is clear from the bugreport what the problem is (how to reproduce it, etc.), the bugreport should be set to ASSIGNED.

Reviewing bugreports

When helping with bugreports, follow these guidelines:

  • When a new bugreport is reported, first check whether it is really a bugreport about KDE. Sometimes users attribute to KDE a problem that should in fact be reported to for example GNOME, X.Org, kernel or other distribution components. If the bugreport should be reassigned to another component, change the 'Component' field in bugzilla and click 'Commit' (reassigning will be selected automatically by changing the component).
  • Check the validity and completeness of the bugreport:
    • Incomplete bugreports - Bugreports such as "it is broken" without any futher details are completely useless. A good bugreport is a one from which it is clear what happened (it can be seen how to reproduce) and what was wrong about it (the bugreports clearly states the problem). A specific example of a bugreport that is not very useful are reports about crashes at include only the backtrace from the crash and no other details, especially if the backtrace itself is useless (see openSUSE:Bugreport_KDE#Useful_Crash_Reports). Such bugreports should be set to NEEDINFO to the reporter and the reporter should be asked for missing information. If no information will be provided after a month, close old NEEDINFO bugreports as RESOLVED NORESPONSE with "No reply in more than 4 weeks. Please reopen if you are able to provide the requested information.". If the reporter provides the information, make sure the NEEDINFO status is removed and review the bugreport again.
    • Invalid bugreports - Some bugreports may ask for things that it does not make sense to do for various reasons (asking for very complicated and specific features, random complaints about the general state of things without being specific, and so on). Such bugreports should be closed as RESOLVED INVALID or WONTFIX.
  • Assign a priority to the bugreport, as explained above.
  • Check whether the problem can be reproduced (can be skipped if e.g. too difficult and not having the time, but this information can be helpful):
    • If the problem cannot be reproduced, consider the bugreport incomplete and use NEEDINFO to ask for more information.
    • If the problem cannot be reproduced on a more recent version than the one reported, close P3-P4 bugreports with a comment saying so as RESOLVED FIXED.
    • Otherwise add a comment confirming that the problem can be reproduced including any possibly important information.
  • Decide whether the bugreport should be kept in Novell bugzilla or upstreamed to the KDE bugzilla, using the following guidelines (see also above):
    • If it is an openSUSE-specific problem, keep it.
    • Bugreports with priority P3-P4 that are not openSUSE-specific should be forwarded to KDE bugzilla and closed as RESOLVED UPSTREAM. If you can find the same problem in the KDE bugzilla, mention the URL to that bugreport in the closing comment and in the 'URL' field, otherwise either report the problem yourself or ask the reporter to do so.
    • Reports for KDE:KDE4:Desktop:UNSTABLE should be kept only when it is a packaging problem, otherwise they should be RESOLVED UPSTREAM.
    • Reports for KDE:Distro:Factory should be upstreamed more aggressively if the next stable openSUSE release is not coming close.
    • Other bugreports should be kept (that is, not openSUSE-specific but important enough to have priority P1-P2). Just like with other bugreports that are not openSUSE-specific it should be also reported to upstream KDE bugzilla, as there is often a higher chance the problem will be fixed by upstream first.
  • Set the bugreport status to ASSIGNED if it is ready for a developer to fix it. If there is still something unclear about the bugreport (no way to reproduce, not confirmed the problem exists, etc.) use further NEEDINFO or leave it at NEW for somebody else to triage.
  • Reassign the bugreport to the developer who expert area it is, if possible, otherwise leave the bugreport in the kde-maintainers@suse.de alias if not known or not sure. Most bugreports should be shared unless one developer is clearly reponsible or someone wants to work on a specific bug.

Stock Responses

  • "Thanks for the detailed bug report. I have forwarded it to the upstream maintainer at bugs.kde.org, and we will monitor that bug for a fix. If possible, please add yourself to the upstream CC list for the bug so you can provide more data or test fixes."
Retrieved from "https://en.opensuse.org/index.php?title=openSUSE:Bug_Screening_KDE&oldid=120934"