Fehlerberichterstattung HGF

Wechseln zu: Navigation, Suche

Inhaltsverzeichnis

Allgemeine Fehlerhandhabung

In diesem Dokument wird beschrieben, wie Sie das Bugzilla-System auf bugzilla.opensuse.org benutzen.

In welcher Sprache sollen Fehler berichtet werden?

Fehler müssen generell auf Englisch gemeldet werden. Dieser Umstand ist der internationalen Entwicklergemeinde von openSUSE zu verdanken, in der natürlich nicht jeder Deutsch spricht. Außerdem sind natürlich weltweit Nutzer an Fehlerberichten interessiert, schon allein um zu sehen, ob ein Fehler schon eingetragen wurde.


Welche Felder sollte ich anfangs ausfüllen? Welche soll ich ändern und welche nicht?

  • Component (Komponente)
    Hinweis: Nicht an allen Fehlern während der Installation trägt YaST die Schuld, sie können bspw. auch vom Kernel herrühren.
  • Platform (Plattform)
    Verwenden Sie “all" wenn Sie der Meinung sind, dass es plattformunabhängig ist, andernfalls wählen Sie ihre Plattform.
  • Summary (Zusammenfassung)
    Wenn sich jemand die Zusammenfassung durchliest, sollte er verstehen, worum es sich handelt.
  • Bug description (Fehlerbeschreibung)
    Fügen Sie alle Details über den Fehler ein. Beachten Sie, dass Sie nicht schreiben sollten "See summary" da diese eventuell geändert werden kann.
  • How to Reproduce? (Reproduktionsanleitung)
    Dieser Teil ist so wichtig, dass ihm eine eigene Erklärung in der Antwort auf die Frage 1.1.6 gewidmet wird.
  • Severity (Auswirkungsgrad)
    Wählen Sie den richtigen Grad der Auswirkung. Markieren Sie den Fehler wirklich nur dann als “blocker" wenn Sie denken, wir sollten den Fehler nicht unbehoben mit dem Produkt ausliefern.
  • Der Rest
    Sie müssen die anderen Felder nicht ausfüllen, die Standardfelder reichen aus.

Bekomme ich nach der Meldung Rückmeldungen?

Ja, wenn Sie ihre Einstellungen unter "User Prefs" nicht verändert haben, werden Sie über jede Veränderung per E-Mail informiert.

Falls Sie etwas gefragt werden, oder einfach nur eine Rückmeldung kommentieren wollen, dann antworten Sie nicht auf die Adresse des Kommentars, da diese automatisch von Bugzilla kommt. Sie sollten die Web-Schnittstelle von Bugzilla zur Kommunikation nutzen, da es so allen Interessierten ermöglicht wird, an die relevante Information zu gelangen.

Welche Felder sollte ich ändern und welche nicht?

Als Nicht-Entwickler sollten Sie im Allgemeinen nur Kommentare hinzufügen oder sich selber zu CC hinzufügen. Falls der Fehler den Status “NEEDINFO" hat, vergessen Sie nicht, ihn auf “ASSIGNED" zu setzen, nachdem Sie alle Informationen abgeliefert haben.
Wie? Unterhalb von comment befindet sich ein Ankreuzfeld in der Art von "This comment provides the needed info" - sollte das nicht bevorzugt verwendet werden?


Was soll ich machen, wenn die aktuelle Version von openSUSE einen schon existierenden oder ähnlichen Fehler enthält, dieser aber für eine ältere Version gemeldet wurde?

Ein Vorschlag lautet: Verschieben Sie die Version des Pakets und schreiben Sie einen Kommentar wie "This bug was reported for openSUSE x.y and still fails for openSUSE u.v. I'm adjusting the version". Falls der Fehlerbericht zuvor geschlossen war, sollten Sie ihn wieder öffnen.


Die Leute sind wütend auf mich, weil ich "Install SUSE x.y-Beta-z" in das Feld "how to reproduce" eingegeben habe. Wieso?

Nun, weil dies ganz einfach eine absolut nutzlose Information ist - doppelt vorhanden und in keinster Weise hilfreich, einen Fehler zu reproduzieren. Beide Informationen haben Sie ja schon angegeben, da Sie in der components-Liste "Installation" ausgewählt haben und im Feld nebenan die Ausgabe angegeben haben.

Was wir wirklich wissen müssen, ist was Sie getan haben und wie Sie es getan haben - wie "boot from CD1, select "Installation", select language "Klingon", leave the installation settings as they are, confirm installation, watch as your hard disk goes up in flames."

Und nein, dass ist wirklich absolut keine Pingeligkeit. Es gibt so viele Installationsmodi und so viele verschiedene Wege eine Installation durchzuführen, dass es Jahre dauert, aus den Protokolldateien herauszufinden, wie Sie vorgegangen sind. Sie haben den Ablauf schon in ihrem Kopf parat und sollten wissen, was Sie getan haben. So ist es ein Einfaches für Sie, uns durch gewissenhaftes Ausfüllen die Arbeit zu erleichtern.

Natürlich benötigen wir nicht so viele Details, wenn Sie einen Fehler in einem Hilfetext der abschließenden Hardware-Konfiguration (wie Drucker, TV-Karte, usw.) gefunden haben, aber die Schritte die Sie gemacht haben, bis der Fehler erschien, brauchen wir wirklich. Es gibt so viele Dialoge, dass es nicht gerade einfach ist, herauszufinden welchen Sie meinen und welchen Weg sie dorthin genommen haben.

Die Leute sind ziemlich unzufrieden, weil ich in der Fehlerbeschreibung lediglich "see subject" angegeben habe. Aber meine Überschrift erklärt wirklich schon alles! Ist es nicht einfach Pingeligkeit, von Fehlerreportern zu verlangen, dass alles noch mal im Feld description zu wiederholen?

Nein, überhaupt nicht.

Die Überschriften können jederzeit geändert werden. Das von ihnen berichtete Problem kann eventuell nur die Spitze eines Eisberges sein und das wirkliche Problem kann an einer ganz anderen Stelle liegen. Dann werden diejenigen, die diese richtige Stelle gefunden haben, natürlich die Überschrift dementsprechend anpassen. Im Gegenzug geht dabei ihre ursprüngliche Überschrift verloren.

Deshalb sollte es klar sein, dass die Überschrift (subject) nicht der richtige Ort ist, um wichtige Informationen zu speichern. Das gemeldete Problem ist zweifellos die wichtigste einzelne Information in einem Fehlerbericht.

Außerdem ist es einfach schlechter Stil, alle Arten von Informationen in die Überschrift zu pressen und im folgenden dann nur noch darauf zu verweisen. Das ist pure Faulheit. Es kostet Sie nur ein mal ein wenig Zeit, einen sauberen Fehlerbericht zu erstellen, aber jeder der den Fehler bearbeitet, muss immer wieder alles absuchen, um die relevanten Informationen zu erhalten.

Aus diesem Grund sollte die Überschrift (Subject) kurz und prägnant sein, die Fehlerbeschreibung jedoch ausführlich und erklärend.

Fehlerstatus NEEDINFO

Was bedeutet der Fehlerstatus NEEDINFO und wie soll man damit umgehen?

NEEDINFO heißt, dass der Fehlereigner, also die Person die zur Zeit an der Lösung des Problems arbeitet, mehr Informationen über den Fehler benötigt - üblicherweise vom ursprünglichen Berichterstatter.

Wenn Sie einen Fehler mit dem Status NEEDINFO sehen, dann schauen Sie unter den letzten Kommentaren nach einer Frage oder nach einer Aufforderung, mehr Informationen (wie Protokolldateien usw.) zur Verfügung zu stellen.

Falls das der Fall ist, dann antworten Sie bitte darauf oder stellen Sie die Informationen bereit. Setzen Sie den Fehlerberichtsstatus in der Detailansicht des Fehlers dann auf ASSIGNED - click on Accept bug (change status to ASSIGNED).


Werde ich nicht zum Fehlereigner, wenn ich den Status von NEEDINFO auf ASSIGNED setze (mit Accept bug (change status to ASSIGNED) auf der Fehlerdetailseite von Bugzilla)?

Nein, der Fehlereigner bleibt der gleiche, lediglich der Status ändert sich. Sie können das machen, ohne befürchten zu müssen, dadurch dann für den Fehler verantwortlich zu sein.


Warum ist es wichtig, dass ich den Fehlerstatus von NEEDINFO auf ASSIGNED setze? Ist das nicht die Aufgabe des Fehlereigners?

Nein, dafür ist derjenige zuständig, der die gestellte Frage beantwortet oder die benötigten Informationen liefert.

Die Fehlereigner nutzen NEEDINFO um einfacher überblicken zu können, an welchen Fehlern sie gerade arbeiten können (die mit ASSIGNED, NEW oder REOPENED gekennzeichneten) und bei welchen die Arbeit hängt, weil wichtige Informationen nicht vorhanden sind. - Fehler mit dem Status NEEDINFO erscheinen nicht länger in ihrer Arbeitsliste offener Fehler.

Deshalb ist es wichtig, dass der Fehlerstatus von NEEDINFO auf einen anderen Status gesetzt wird - der Fehlereigner könnte den Fehler sonst in der E-Mail, welche Bugzilla ihm bei neuen Kommentaren sendet, übersehen, was dazu führt, dass der Fehler für unbestimmte Zeit im Status NEEDINFO vor sich hin gammelt.

Unsere Fehlerbetreuer erhalten so viel elektronische Post, dass sie zu Spitzenzeiten (bspw. während einer Betaphase) nicht vernünftig auf jede einzelne Meldung eingehen können. Ab einem gewissen Punkt müssen sie sich dann allein auf die Fehlerstatuslisten verlassen können, wodurch die Gefahr steigt, dass sie den Kommentar übersehen, der sie auf die Verfügbarkeit notwendiger Information hinweist. Was dann dazu führt, dass das Bearbeiten eines Fehlers ins Stocken geraten kann.

So ist es auch im ureigensten Interesse des Berichterstatters, den Status von NEEDINFO zu ändern, nachdem die Fragen beantwortet wurden.

Sie könnten natürlich ab und zu auch mal das Glück haben, dass der Fehlereigner selber merkt, dass die gewünschte Information eingetroffen ist und den Fehlerstatus selber auf ASSIGNED setzt; nur ist es in der Regel keine besonders gute Taktik, allein auf Glück zu vertrauen.

Beachten Sie bitte, dass die Fehler, welche dem BNC-Screening-Team (vor allem Probleme mit YaST und X11) zugewiesen werden, am Anfang oder während der Bearbeitung nicht von Berichterstattern oder Informationslieferanten von NEEDINFO auf ASSIGNED gesetzt werden sollten. Der Grund dafür ist, dass eine Änderung des Status fast immer eine Neuzuweisung durch dieses Team nach sich zieht. Das Ändern dieses Status kann dann dazu führen, dass der betroffene Fehler auf der falschen Liste erscheint und deshalb eventuell nicht effizient bearbeitet (reassigned) werden kann. Danke, dass Sie das in Betracht ziehen.

Fehlerstatus VERIFIED / CLOSED

Sollte ich einen Fehler als VERIFIED oder CLOSED markieren, wenn ich sehe, dass das Problem in einer neuen Version oder in einer Aktualisierung behoben ist?

[Muss noch geschrieben werden]


Fehlerstatus WONTFIX

Dieser Abschnitt wurde nach Fehlerstatus WONTFIX verschoben.


Wie melde ich einen Fehler in ...

Weitere Informationen zum Melden von Fehlern in verschiedenen Komponenten, wie bspw. dem Kernel, KDE oder YaST, finden Sie im Artikel Fehler berichten.


openSUSE Dokumentation

Melden Sie Fehler in der Dokumentation von openSUSE in Bugzilla (Komponente: "Documentation") und für bereits veröffentlichte Produkte im englischen Wiki in der Errata der openSUSE 11.0 Dokumentation oder der Errata der openSUSE 10.3 Dokumentation.


Beta-Versionen testen

Ich würde gerne an den Tests von openSUSE teilnehmen. Wen sollte ich kontaktieren?

openSUSE ist offen. Schreiben Sie sich einfach auf den Mailinglisten des openSUSE-Projekts ein und melden Sie Fehler wie es unter Fehler berichten und hier beschrieben wird.

Ich würde gerne daran teilnehmen, Beta-Versionen anderer Produkte wie SLES oder SLED zu testen. An wen sollte ich mich wenden?

Nicht alle diese Produkte haben Betaprogramme, aber falls sie eines haben, dann erreichen Sie es überThe Novell Beta Program.


Welche Art von Rückmeldung soll ich geben?

Wir würden gerne sowohl positive als auch negative Rückmeldungen haben - und natürlich Verbesserungsvorschläge.

Mit positiven Rückmeldungen meinen wir Berichte über erfolgreiche Installationen und erfolgreiches Arbeiten mit openSUSE und dass bestimmte Bereiche getestet wurden und einwandfrei funktionieren. Berichten Sie uns davon doch bitte auf der Mailing-Liste [1]. Diese positiven Rückmeldungen werden in unsere testdb aufgenommen.

Für negative Rückmeldungen, womit wir alle auftretenden Probleme meinen, benutzen wir Bugzilla. Füllen Sie dort bitte einen separaten Fehlerbericht für jedes Problem aus, dass bei ihnen auftritt. Andere Abschnitte auf dieser Seite erklären, wie Sie dabei vorgehen.

Zusätzliche Ideen für Verbesserungen, im allgemeinen Fähigkeitenanforderung (feature request) genannt, sind immer willkommen. Dazu existieren im englischsprachigen Wiki spezielle Seiten: Paketwunschliste und Fähigkeitenwunschliste


Was ist betatestdb.suse.de?

Hinweis: betatestdb.suse.de wurde zuletzt für SUSE Linux 10.0 aktualisiert und der Zugang ist Passwortgeschützt. (Die Anmeldedaten für dieses Wiki und Bugzilla werden dort nicht funktionieren.)

Betatestdb ist ein Werkzeug, mit welchem man sich ansehen kann, welche Pakete schon von Betatestern überprüft wurden und ob das erfolgreich war oder nicht. Das erlaubt es uns, nicht nur negative Rückmeldungen (etwas funktioniert nicht) über Bugzilla zu erhalten, sondern auch positive Rückmeldungen entgegen zunehmen, etwa dass Pakete arbeiten und das Produkt stabil ist.

Für eine große Anzahl von Paketen finden Sie dort genaue Prüffälle; diese enthalten eine Beschreibung, was zu tun ist - entweder bestimmte Funktionen zu testen oder das ganze Softwarepaket zu prüfen. Folgen Sie bitten den dortigen Anweisungen und geben Sie ihre Resultate dann in die betatestdb ein.

Hinweis: Zur besseren Übersicht wurden die Pakete in bestimmte Bereiche eingeteilt.

Abgerufen von „https://de.opensuse.org/index.php?title=Fehlerberichterstattung_HGF&oldid=36822“