Fehler:KDE/Klassifizierung

aus openSUSE, der freien Wissensdatenbank

Inhaltsverzeichnis

Klassifizierung von KDE-Fehlerberichten

Allgemein

Diese Seite behandelt die Mithilfe bei Fehlermeldungen über KDE, die in Novells Bugzilla gemeldet wurden. Zum melden von Fehlern gehen Sie auf Fehler:KDE (wobei Sie die Seite auch lesen sollten, wenn Sie bei der Klassifizierung von Fehlern helfen wollen).

openSUSE stellt KDE inklusive Tests und verschiedener Modifikationen bereit. KDE wird dennoch hauptsächlich an der Quelle im KDE-Projekt entwickelt, und obwohl das openSUSE-KDE-Team zu KDE beiträgt, ist es auf Grund fehlender Ressourcen nicht möglich, sich um jedes einzelne KDE-Problem zu kümmern (das Team ist relativ klein). Deshalb ist es wichtig, dass die Menge der KDE-Fehlermeldungen für openSUSE in einem vertretbaren Rahmen bleibt, so dass sie auch noch vom openSUSE-KDE-Team gehandhabt werden können. Sie können beim Überprüfen und Klassifizieren von KDE-Fehlermeldungen helfen. Es sind dafür keine bestimmten Kenntnisse als die auf dieser Seite angebotenen Informationen und die auf der Seite Fehler:KDE erforderlich, vor allem ist es nicht notwendig, dass Sie ein Entwickler sind. Indem Sie bei den Fehlerberichten helfen können Sie die Zeit reduzieren, die die openSUSE-KDE-Entwickler damit verbringen müssen, was es denen erlaubt, sich auf die Verbesserung von KDE unter openSUSE zu konzentrieren.

Diese Seite erklärt einige wichtige Konzepte von KDE-Fehlerberichten für openSUSE und stellt einen Schritt-für-Schritt-Leitfaden für die Hilfe bei der Bugzilla-Klassifizierung bereit.

Konzepte

Organisation von Fehlerberichten in Bugzilla

Alle neuen KDE-Fehlerberichte für openSUSE (bspw. dir für die Komponenten KDE/KDE3/KDE4) werden erst mal dem geteilten Alias kde-maintainer@suse.de zugewiesen, der von allen openSUSE-KDE-Entwicklern beobachtet wird. Hier findet die erste Klassifizierung statt.

Jeder openSUSE-KDE-Entwickler hat sein persönliches Bugzilla-Konto, dem er Fehlerbericht zuweist, die er bald bearbeiten wird oder die seinem Fachgebiet entsprechen. Die meisten Fehlerberichte verbleiben dennoch in der geteilten Liste von kde-maintainer@suse.de.

Sie können jedes Bugzilla-Konto in Novells Bugzilla beobachten, indem Sie es der Liste unter Preferences->Email Preferences in der Nähe des Seitenfuß hinzufügen. Um Änderungen in geteilten Fehlerberichten zu verfolgen, inklusive aller neuen Meldungen, fügen Sie 'kde-maintainers@suse.de' hinzu.

Upstream gegenüber Downstream

Upstream meint in diesem Zusammenhang das KDE-Projekt, mit dem KDE-Bugzilla unter http://bugs.kde.org. Downstream meint hier openSUSE, mit dem Novell-Bugzilla unter https://bugzilla.novell.com.

Die Grundregel für KDE-Fehlerberichte in Novells Bugzilla ist, dass dort nur Probleme gemeldet werden sollen, die entweder openSUSE-spezifisch oder schwerwiegend sind. openSUSE-spezifisch meint Paketierung, Anwendungen, Werkzeuge, Desktop-Komponenten oder deren Modifikationen, die von openSUSE-KDE-Entwicklern erstellt wurden. Da es sich hierbei um die Arbeit von openSUSE-KDE-Entwicklern handelt, gehören solche Berichte nicht in das Upstream-Bugzilla. Schwerwiegende Probleme meint in diesem Kontext Probleme, die wichtig für die KDE-Desktop-Erfahrung unter openSUSE sind und viele Nutzer betreffen können oder eine sehr schlimme Wirkung (Datenverlust zum Beispiel) haben. Andere KDE-Fehlerberichte sollten an das Upstream-Bugzilla weitergeleitet und in Novells Bugzilla als RESOLVED UPSTREAM geschlossen werden.

Diese Seite enthält eine Liste der von openSUSE erstellten KDE-Modifikationen. Wenn Sie sich nicht sicher sind, ob ein Fehlerbericht openSUSE-spezifisch ist oder nicht, dann behandeln Sie ihn im Zweifelsfall als openSUSE-spezifisch (und womöglich wird später jemand anders darüber entscheiden).

Prioritäten von Fehlerberichten

Fehlerberichte in Novells Bugzilla werden nach Prioritäten sortiert, um einen besseren Überblick über den Status zu geben und um Entwicklern die Entscheidung zu erleichtern, in welcher Reihenfolge sie an Fehlerberichten arbeiten sollen. Unter Fehler/Definitionen finden Sie eine Erklärung zu den Prioritäten; lesen Sie die Seite bitte, um zu verstehen, wie den Fehlerberichten Prioritäten zugewiesen werden sollten. Prioritäten sollten in erster Linie von Entwicklern gesetzt werden, wobei aber auch erfahrene Mitglieder aus der Gemeinschaft helfen können. Entwicklern ist dennoch der Vorzug zu gewähren, weshalb Sie eine von einem Entwickler gesetzte Priorität nicht verändern sollten. Wenn Sie außerdem noch nicht viel Erfahrung haben, sollten Sie bei der Setzung von Prioritäten vorsichtig sein. Es ist sicherer, wenn Sie nicht schon gleich zu Anfang Prioritäten setzen, sondern sich erst einmal anschauen, wie dies von Anderen gehandhabt wird.

Kommunikation

Sie können das openSUSE-KDE-Team über die auf der KDE-Hauptseite erklärten Wege erreichen. Wenn Sie Fragen zu oder Probleme mit der Bugzilla-Klassifizierung haben, finden Sie dort Antworten und Hilfe.

Fehlerberichte überprüfen

Wenn Sie bei Fehlerberichten helfen wollen, dann folgen Sie diesem Leitfaden:

  • Wenn ein neuer Fehler gemeldet wird, dann prüfen Sie als Erstes, ob es sich wirklich um einen KDE-Fehler handelt. Manchmal schieben Nutzer ein Problem auf KDE, das eigentlich für GNOME, X.Org, den Kernel oder andere Distributionskomponenten gemeldet werden sollte. Falls der Fehlerbericht einer anderen Komponente zugewiesen werden soll, ändern Sie in Bugzilla das Feld 'Component' und klicken Sie auf 'Commit' (die Neuzuweisung wird durch das Ändern der Komponente automatisch ausgelöst).
  • Prüfen Sie die Gültigkeit und die Vollständigkeit des Fehlerberichts:
    • Unvollständige Fehlerberichte - Fehlerberichte wie "it is broken" ohne weitere Details sind komplett nutzlos. Ein guter Fehlerbericht ist einer, aus dem klar hervorgeht, was passierte (man kann sehen, wie man ihn reproduziert) und was daran falsch ist (der Fehlerbericht benennt klar das Problem). Ein bestimmtes Beispiel nutzloser Fehlerberichte sind Meldungen über Abstürze, die nur eine Rückverfolgung (Backtrace) enthalten, ohne auf die Details einzugehen, besonders dann, wenn die Rückverfolgung selber nutzlos ist (siehe Fehler:KDE#Nützliche Absturzberichte). Solche Fehlerberichte sollten für den Melder auf NEEDINFO gestellt werden und der Melder sollte nach den fehlenden Informationen gefragt werden. Wenn die benötigten Informationen nach einem Monat noch nicht bereitgestellt wurden, schließen Sie alte NEEDINFO-Fehlerbericht mit "No reply in more than 4 weeks. Please reopen if you are able to provide the requested information" als RESOLVED NORESPONSE. Wenn der Melder die Informationen bereitstellt, stellen Sie sicher, den NEEDINFO-Status zu entfernen und den Fehlerbericht nochmals zu überprüfen.
    • Ungültige Fehlerberichte - In einigen Fehlerberichten wird vielleicht nach Dingen gefragt, die aus verschiedenen Gründen nicht wirklich Sinn ergeben (Fragen nach sehr komplizierten und spezifischen Funktionen, wahllose Klagen über den allgemeinen Stand der Dinge ohne konkret zu werden, und so weiter). Solche Fehlerberichte sollten als RESOLVED INVALID oder WONTFIX geschlossen werden.
  • Zuweisen einer Priorität, wie oben erklärt.
  • Prüfen, ob das Problem reproduziert werden kann (kann übersprungen werden, wenn es bspw. zu kompliziert ist, oder die Zeit dafür fehlt; allerdings können diese Informationen sehr hilfreich sein):
    • Wenn das Problem nicht reproduziert werden kann, betrachten Sie den Fehlerbericht als unvollständig und nutzen Sie NEEDINFO, um nach weiteren Informationen zu fragen.
    • Wenn das Problem unter einer aktuelleren Version nicht reproduziert werden kann, schließen Sie P3-P4 Fehlerberichte mit einem Kommentar als RESOLVED FIXED.
    • Andernfalls fügen Sie einen Kommentar hinzu, in dem Sie die Reproduzierbarkeit bestätigen und der jede möglicherweise wichtige Information enthält.
  • Entscheiden Sie, ob der Fehlerbericht in Novells Bugzilla verbleiben oder nach Upstream verwiesen werden soll, in das KDE-Bugzilla. Nutzen Sie dazu den folgenden Leitfaden (siehe auch weiter oben):
    • Wenn es ein openSUSE-spezifisches Problem ist, belassen Sie es in Novells Bugzilla.
    • Fehlermeldungen mit der Priorität P3-P4, die nicht openSUSE-spezifisch sind, sollten an das KDE-Bugzilla weitergeleitet und als RESOLVED UPSTREAM geschlossen werden. Wenn Sie das gleiche Problem im Bugzilla finden können, erwähnen Sie diese URL im Abschlusskommentar und im Feld 'URL'. Melden Sie den Fehlern andernfalls selber im KDE-Bugzilla oder fragen Sie den Melder, ob er das macht.
    • Andere Fehlerberichte sollten behalten werden (das gilt für Fehler die zwar nicht openSUSE-spezifisch, aber schwerwiegend genug für Priorität P1-P2 sind). So wie andere nicht openSUSE-spezifische Fehler sollten auch diese upstream in KDEs Bugzilla gemeldet werden, da dort meist eine höhere Chance auf deren schnelle Lösung besteht.
  • Weisen Sie den Fehlerbericht wenn möglich, dem Entwickler zu, in dessen Fachgebiet er fällt, andernfalls belassen Sie den Fehlerbericht im Alias kde-maintainers@suse.de, wenn Sie sich nicht sicher sind. Die aktuellen Fachgebiete sind:
    • llunak: X-spezifisches Zeug - KWin (Fensterverwaltung, Arbeitsflächeneffekte), mehrere Monitore, Bildschirmschonerhandhabung
    • stbinner: Kerry
    • wstephenson: KDEPIM (KMail, Kopete), KNetworkManager