Joomla! Documentation™

Der Beitrag dokumentiert den aktuellen Bug Tracking-Prozess vom Bug-Bericht bis zum Schließen des Berichts.

Joomla!-Bugs werden im Joomla! Issue Tracker eingetragen, der Fehler unterstützer Versionen sammelt. Empfohlene Version ist J3.10.

Mithelfen

Man muß kein Mitglied des Joomla! Bug Squad sein, um beim Fixen von Bugs mitzuhelfen. Bugs und Fehler berichten, Patches testen oder einreichen. Um Bugs zu lösen, auf Tracker gehen. Wie offene Probleme gelöst werden, wird unten beschrieben. Man kann für bestätigte Fehler einen Patch erstellen und einreichen. Oder anstehende Patches testen. Zum Berichten mit einem GitHub-Zugang anmelden und kommentieren. Es ist überraschend angenehm, wieviel Einfluß man hat und wieviel man zum Projekt beitragen kann. Bei Fragen oder wenn man im JBS Mitglied werden will, bitte die Bug Squad-Koordination kontaktieren.

Vor-Veröffentlichungen testen

Vor einer stabilen Joomla!-Veröffentlichung wird das Update wie folgt getestet:

1. Die Staging-Version von Joomla https://github.com/joomla/joomla-cms in einem Unterverzeichnis oder auf lokal installieren (eine Kopie der Produktsite kann ebenfalls getestet werden, aber nie auf der Produktsite testen)
2. In den Optionen der "Joomla!-Aktualisierung" den Aktualisierungsserver auf "Test" umstellen.
3. Ist eine Vor-Veröffentlichung zum Testen freigegeben, auf der Testsite anmelden, das Update installieren und testen. Fehler/Bugs bitte im Joomla! Issue Tracker berichten.

Probleme berichten

Der Prozess beginnt meist mit einer der beiden Möglichkeiten: Der Bug der aktuellen Version wird im Tracker eingetragen oder ein Benutzer berichtet ihn im Bug-Forum.

Problem im Forum berichtet

JBS-Mitglieder beobachten das Forum, ob Fehler in den Tracker geschrieben werden müssen. Ist das Problem reproduzierbar, ein offensichtlicher Bug, gibt es eine Schritt-für-Schritt-Anleitung zum Reproduzieren wird es Im Tracker mit dem Status "Bestätigt" eingetragen. Ist das nicht der Fall, erhält es den Status "Neu" damit alle Mitglieder wissen, dass weitere Untersuchungen nötig sind.

Problem im Tracker berichtet

Bei Eintrag eines Problems ist der Status im Tracker je nach Situation:

1. Neu
2. Bestätigt
3. Wartend

Braucht es weitere Untersuchungen, wird "Neu" als Status gesetzt. Ist des Problem 1. ein Bug und kann 2. reproduziert werden und hat 3. gute Testanweisungen, wird es auf "Bestätigt" gesetzt. Treffen die drei Kriterien zu und es gibt einen guten Patch, wird es auf "Wartend" gesetzt. Unten mehr zu den Status-Codes.

Problem-Prioritäten

Warum die meisten Probleme Priorität 3 oder Medium haben. Die Berichte werden nach dieser Charakteristik eingeteilt:

Kritisch (1): Der Trunk arbeitet nicht. Wichtige Teile sind unterbrochen, Schlüsseloperationen nicht möglich. Beispiele sind Anmeldung, Installation, Erweiterungs-Installation, Javascript-Fehler, die "Sichern" und Ähnliches verhindern, etc. Ebenso Fatal-PHP-Fehler und schwerwiegende Sicherheitsfehler in einer Vor-Veröffentlichung (Sicherheisfehler NICHT im Tracker, nur an das Securityteam [email protected] berichten).

Dringend (2): Teile des Codes verhindern Operationen in ernsthafter Weise oder verursachen Schäden an angekündigten Funktionen. Beispiele sind PHP-Notizen und Warnungen, Javescriptfehler. Das verhindert im Veröffentlichungszyklus den Übergang von "Beta" zu "Release Candidate" oder "Release Candidate" zur Verfügbarkeit.

Medium (3): Fehler verhindern angekündigte Funktionen, die Applikation aber arbeitet. Beispiele sind nicht wie angekündigt arbeitende Parameter, Sprachdateien, die nicht wie erwartet geladen werden, etc.

Niedrig (4): Geringer Verlust an Funktion und generell lästiges Verhalten. Beinhaltet weniger bekannte Plattform- oder Browserspezifische Probleme, die in der jeweiligen Umgebung eine Mehrheit betreffen, insgesamt aber eine Minderheit sind. Betrifft auch fehlende Übersetzungsstrings.

Sehr Niedrig (5): Kosmetische Probleme, falsch geschriebene Wörter, graphisch unausgerichtete Objekte, wenig bekannte Fehler mit Parametern, etc.

Probleme lösen

Bug Squad achtet auf Joomla!-Veröffentlichungen. Heißt, das die Veröffentlichungen von 3.4, 3.5, ... entdeckte Probleme lösen. Die Idee ist, die Veröffentlichungen zunehmend stabiler zu machen. Genauso wichtig ist, nicht zu beschädigen, das funktioniert. Das wird "Software Regression" genannt und will niemand. Im Tracker gibt es unterschiedliche Status, meist: Neu, Bestätigt, Wartend, Fertig zum Anwenden.

• Neu bedeutet, das etwas berichtet wurde aber unklar ist, ob es ein Bug ist. Viele neue Probleme sind kein Bug. Passt der Bericht in einer der unteren Kategorien, wird der Status geändert oder der Bericht geschlossen.
  • Kann nicht reproduziert werden. Dasselbe wurde nachgestellt, die Software arbeitet aber wie erwartet (in viele Fällen wird mehr Information benötigt, um den Bug reproduzieren zu können. Siehe unten "Informationen erforderlich"). Statusänderung auf "Unbestätigte Meldung".
  • Wurde bereits in einer anderen Fehlernummer berichtet. Statusänderung auf Doppelter Bericht mit Angabe der Original-Fehlernummer..
  • Bekannte Einschränkung der Software. Statusänderung auf Bekanntes Problem.
  • Bei Featurewunsch, Benutzerfehler oder die Software arbeitet wie erwartet. Statusänderung auf Erwartetes Verhalten.
  • Ein Bug einer Erweiterung, eines anderen, externen Programmes oder ein Serverfehler, der nicht bearbeitet werden kann. Statusänderung auf Geschlossen samt Kommentar mit Erklärung der Entscheidung.
• Information erforderlich wenn von der berichtenden Person mehr Informationen als Entscheidungsgrundlage benötigt werden. Beispiel: Es gibt Fragen, wie ein Problem nachgestellt werden kann oder andere Fragen zum Problem. Nach Einlangen der Informationen kann am Problem weitergearbeitet werden. Werden die Informationen innerhalb zweier Wochen nicht geliefert, wird mit "Unbestätigte Meldung" oder einem anderen zutreffenden Status geschlossen.
• Benötigt Überprüfung wird verwendet, wenn ein Mitglied des Production-Departement oder ein CMS-Betreuer für eine Überprüfung oder Entscheidung benötigt wird. Bei "Information erforderlich" wird die Information vom Berichtenden benötigt.
• Bestätigt bedeutet, dass JBS den zu fixenden Joomla!-Bug bestätigt. Entweder arbeitet das JBS selbst oder in Zusammenarbeit mit dem Entwicklungsteam an einer Lösung. Hier müssen klare Schritt-für-Schritt-Testinstruktionen zum Reproduzieren des Problems vorhanden sein.
• Wartend bedeutet, ein Patch wurde eingereicht. Jeder wartende Bericht benötigt Anweisungen, wie Tester ein Problem reproduzieren und sicherstellen können, dass der Patch das Problem behebt.
• Fertig zum Anwenden bedeutet, dass (grundsätzlich) zwei unterschiedliche Personen den Patch erfolgreich getestet haben. Für komplexere Patches oder solche mit größerer Auswirkung können mehrere Personen oder mehrere Plattformen nötig sein. Für einfache Probleme wir der Korrektur von Rechtschreibfehlern in Sprachstrings oder Kommentaren genügt ein Test.
• Im Code repariert bedeutet, dass JBS-Beitragskoordinatoren den Patch für gut befunden und in die Codebasis übernommen haben und damit Teil der nächsten Joomla!-Veröffentlichung sein wird.

Die Leichter Test-Liste ist kein Status sondern zeigt wartende Patches mit leicht verständlichen Testinstruktionen.

Das Flussdiagramm zeigt, wie der Prozess zur Lösung von Bugs abläuft.