Wiki » Betreuen der Fehlerberichte

Warnung!

Das Wiki ist umgezogen und befindet sich nun unter https://wiki.mageia.org/en/Hauptseite-de . Bitte nutzen Sie das neue Wiki.

Die hier enthaltenen Informationen werden nicht aktualisiert und sind deshalb veraltet oder sogar falsch!

Weitere Sprachen

Deutsch ; English

Diese Seite ist ein Entwurf
Wenn du diese Seite verändern willst, so melde dich einfach an und klicke auf den Tabulator Bearbeiten. Betrachte auch andere Seiten verbessern und betreuen.

Idealerweise wenn ein Fehlerbericht ausgefüllt wurde:

• ist er korrekt und vollständig
• ein Verfolger teilt ihn sofort der richtigen Person zu
• je schneller ein Problem behoben werden kann, um so schneller kann der Bericht geschlossen werden.
  
  

Ein Fehlerbericht kann sehr lange leben, vielleicht sogar für immer

So z.B. aus einem der folgenden Gründe:

• niemand liest den Bericht
• der Berichterstatter stellt keine weiteren Informationen zur Verfügung, nachdem er dazu aufgefordert wurde
• der Berichterstatter stellt Informationen zu Verfügung, aber nicht jene die erwartet wurden
• es ist ein "upstream" Fehler
• der Fehler wurde der falschen Person zugewiesen
• die Person der dieser Fehler zugewiesen wurde hat diesen Fehler einfach vergessen
• das korrigierte Paket ist im Test für Aktualisierungen, aber die Person der dieser Fehler zugewiesen wurde hat vergessen diesen Fehler wieder an QA zurückzuweisen
  
  

Wir wollen sicher nicht, dass ein Fehler länger lebt, als es unbedingt nötig ist. Aus diesem Grund betreuen wir Fehler.

Gute Verwaltung eines Fehlerberichts...

...bedeutet, dass wir uns vergewissern:

• wir starten mit der Fehlerverfolgung innerhalb einer Woche nachdem dieser ausgefüllt wurde, und stellen sicher dass der Berichterstatter weiss, dass wir daran arbeiten
• Wir pingen diesen an, wenn ein Berichterstatter nicht innerhalb zweier Woche auf eine Informationsanfrage geantwortet hat
• wir fahren mit der Fehlerverfolgung fort, eine Woche nachdem der Berichterstatter die benötigten Informationen zur Verfügung gestellt hat
• wir weisen den Fehlerbericht zu, nachdem wir sicher sein können dass dieser vollständig und gültig ist
• wenn es keinen Betreuer gibt, lassen wir den Bericht nicht liegen, sondern CC der Person die diese Software gepackt hat
• nachdem der Fehler dem Betreuer zugewiesen wurde, und der Betreuer den Zustand nicht auf "ASSIGNED" gesetzt hat. pingen wir diesen nach zwei Wochen an, um sicher zu stellen, dass er die Zuweisung nicht vergessen hat
• wenn ein Paket ohne Betreuer einen solchen bekommt, weisen wir alle verfolgten Fehler diesen Betreuer zu
• wir überprüfen alle zwei Monate die Fehlermeldungen die sich nicht verändert haben, außer jene die von der zugewiesenen Person akzeptiert wurden

Wir haben nicht genügend Mitglieder in der Fehlertruppe, wie können wir all dies bewältigen?

Wir können es nicht. Also vergiss die idealistische Liste weiter oben

TODO: Erstelle eine pragmatische List von dem was wir tun können

so z.B.:

• wir sehen dazu, dass Fehlermeldungen mit dem Status "NEW" oder "REOPENED" nicht zu einer "abgestandener" Fehlermeldung wird

Dokumentation von Fehlermeldungen

Fehlerdokumentation benötigt eine Dokumentation entweder wie man den Fehler löst, oder bis dieser Fehler gelöst ist. Für eine Übersicht siehe hier

Werkzeuge und wie diese verwendet werden

TODO: Erweiterte Liste an benötigter Bugzilla suchen

NEEDINFO

NEEDINFO Fehlertruppe

Um Enträge zu finden die mit NEEDINFO gekennzeichnet und Fehlern der Fehlertruppe zugewiesen sind, aber seit 14 Tagen keine Aktion mehr gezeigt haben, siehe in der NEEDINFObugsquad Suche

Die Idee der "NEEDINFObugsquad Suche" ist, zu überprüfen ob die geforderten Informationen gegeben wurden

• ist das so:
  • ist die Information vollständig: entferne das Schlüsselwort NEEDINFO
  • frage nach weiteren Informationen wenn die zusätzlichen Informationen die als Antwort zurückgegeben wurden nicht vollständig sind
  • dem Paket zuzuteilen das beteiligt ist, wenn möglich, wenn das nicht schon getan wurde
  • dass bedeutet dem korrekten Paket zuweisen, wenn zuvor das falsche Paket gewählt wurde
  • die Fehlermeldung den Betreuer des fehlerhaften Pakets zuweisen, wenn die Antwort vollständig ist
• wenn keine Information angegeben wurde:
  • solange pingen, dass dieser an seine Anforderung erinnert wird
  • wenn nach 2 Aufforderungen, nach 4 und nach weiteren 2 Wochen keine Antwort kommt: schließe den Fehler als RESOLVED-OLD und erkläre dies (leuhmanu's Greasemonkey Skript erleichtert dies und kann auch hilfreich sein wenn nach 2 Wochen abermals gepingt wird)
• und vergiss das oben genannte, wenn der Berichterstatter des Fehlers antwortet, dass eine Aktualisierung das Problem behoben hat, und schließe den Fehler mit RESOLVED-FIXED

NEEDINFO zugewiesen

Um NEEDINFO zu finden, die irgendjemand von den Fehlern der Fehlertruppe zugewiesen hat, aber von der zugewiesenen Person nicht akzeptiert wurde (irgendjemandem, aber Fehlertruppe) und nach mehr als 14 Tagen noch immer keine Aktion zeigte: NEEDINFOassigned search

Die Idee von NEEDINFOassigned search ist, zu überprüfen ob die geforderten Informationen gegeben wurden

• ist das so:
  • ist die Information vollständig: dann entferne das Schlüsselwort NEEDINFO und schreibe einen Kommentar dass du das Schlüsselwort entfernt hast da die benötigten Informationen eingetroffen sind
  • frage nach weiteren Informationen, wenn auch diese Antwort nicht vollständig war
  • Neuzuweisung des Pakets wenn neue Informationen klar stellen dass ein anderer Übeltäter für diesen Fehler zuständig ist
  • Neuzuweisen an den Betreuer des realen Übeltäters, wenn nötig und möglich
  • Neuzuweisen an die Fehlertruppe wenn der reale Übeltäter keinen Betreuer besitzt, und setze die Ersteller des Pakets in die CC des Fehlerberichtes
• ist die Information nicht vorhanden:
  • pinge so lange dass dieser an die Anforderung erinnert wird
  • wenn keine Antwort nach 2 Anfragen über 4 und über 2 Wochen kommt:
    • Zeigt die Person an die der Fehler zugewiesen wurde Interesse am Fehler: frage sie/ihn ob dieser Bericht als OLD geschlossen werden soll oder nicht
    • Zeigt die Person an die der Fehler zugewiesen wurde keine Interesse am Fehler zeigt: schließe den Fehler als OLD und erkläre warum (leuhmanu's greasemonkey Skript macht es leichter)
• und vergiss das oben genannte, wenn der Berichterstatter des Fehlers antwortet, dass eine Aktualisierung das Problem behoben hat, und schließe den Fehler mit RESOLVED-FIXED

STALE

Um Fehlerberichte zu finden in denen seit mehr als einen Monat keine Aktion mehr stattgefunden hat (mehr als 92 Tage), aber enthalten sind:

• erweiterte Anforderungen
• Fehler die den Status ASSIGNED besitzen
• Fehler die von der Person der sie zugewiesen wurden, akzeptiert wurden (OK am Whiteboard)

Stale bugs, das sind nicht zugeteilt oder von der Person an dem die Zuteilung erfolge nicht akzeptierte Fehler, ausser Erweiterungen

Die Idee dieser Suche ist, Leute darauf aufmerksam zu machen, dass diese Fehler dazu tendieren, vergessen zu werden. Zur Zeit (hoffentlich bleibt es dabei) ist keiner dieser Fehler der Fehlertruppe zugewiesen. Für Fehler der Art "assigned to anybody but bugsquad", muss ein Kommentar erstellt werden:

Pingen, da seit mehr als 3 Monaten hier keine Aktion mehr stattgefunden hat, er hat einfach den Status NEW oder REOPENED.

@ <name der Person die der Fehler zugewiesen wurde>
Please set status to ASSIGNED if you think this bug was assigned correctly.
If for work flow reasons you can't do that, then please put OK on the whiteboard instead.

Paketanforderungen

Alphabetische Reihenfolge

alphabetisch sortierte Suche

Paketanforderungen sollten "<package name>, <kurze Beschreibung>" in der Zusammenfassung enthalten, und der Paketname sollte nur Kleinbuchstaben enthalten, so dass beim Sortieren, mit dem obigen Link, leichter zu sehen ist ob es duplikate gibt

Vergleiche mit Mandriva 2010.2

Paketanforderungen die nicht überprüft wurden ob diese in Mandriva 2010.2 vorhanden sind

Um einen Aufstieg von Mandriva 2010.2 auf Mageia 1 zu erleichtern, ist es allen Paketen von Mandriva 2010.2 erlaubt nach Mdv 1 zu gehen. Aus diesem Grunde setzen wir Mdv auf das Whiteboard das Paket in Mandriva 2010.2 zu finden ist, and X wenn dies nicht der Fall ist.

Gehe zum Portal der Fehlertruppe