Bug Tracking Process/de: Difference between revisions

From Joomla! Documentation

Created page with "Bug Tracking-Prozess"
 
No edit summary
 
(51 intermediate revisions by 2 users not shown)
Line 1: Line 1:
<noinclude><languages /></noinclude>
<noinclude><languages /></noinclude>
This article documents the current Joomla! bug tracking process from the time a new bug is reported to the time it is closed.
Der Beitrag dokumentiert den aktuellen Bug Tracking-Prozess vom Bug-Bericht bis zum Schließen des Berichts.


Joomla! bugs are tracked in the [https://issues.joomla.org/ Joomla! Issue Tracker], this Tracker is for issues with supported Joomla Versions. As of August 2018, this is version 3.8+
Joomla!-Bugs werden im [https://issues.joomla.org/ Joomla! Issue Tracker] eingetragen, der Fehler unterstützer Versionen sammelt. Empfohlene Version ist '''J{{CurrentSTSVer|minor}}'''.
==Helping out==
==Mithelfen==


You do ''not'' need to be a member of the Joomla! Bug Squad to help fix bugs in Joomla. [[S:MyLanguage/Filing bugs and issues|Anyone can report bugs]], test patches, or submit patches. If you want to help with resolving bugs, go to the [https://issues.joomla.org/ Tracker]. You can help resolve Open issues as outlined below. You can create and submit patches for Confirmed issues. Or you can help test Pending issues. To report about what you have done, login with a Github account and add a comment. You'll be amazed at how much impact you can have and how good it feels to contribute to the Joomla! project.
Man muß ''kein'' Mitglied des Joomla! Bug Squad sein, um beim Fixen von Bugs mitzuhelfen. [[S:MyLanguage/Filing bugs and issues|Bugs und Fehler berichten]], Patches testen oder einreichen. Um Bugs zu lösen, auf [https://issues.joomla.org/ 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.
If you have any questions, or are interested in joining the [[S:MyLanguage/Portal:Bug_Squad|JBS]], please contact [mailto:bugsquad@community.joomla.org The Bug Squad Coordinators].  
Bei Fragen oder wenn man im [[S:MyLanguage/Portal:Bug_Squad|JBS]] Mitglied werden will, bitte die [mailto:bugsquad@community.joomla.org Bug Squad-Koordination] kontaktieren.  
===Testing Pre releases===
===Vor-Veröffentlichungen testen===
Vor einer stabilen Joomla!-Veröffentlichung wird das Update wie folgt getestet:
#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''')
#In den Optionen der "[[S:MyLanguage/Help38:Components Joomla Update|Joomla!-Aktualisierung]]" den Aktualisierungsserver auf "Test" umstellen.
#Ist eine Vor-Veröffentlichung zum Testen freigegeben, auf der Testsite anmelden, das Update installieren und testen. Fehler/Bugs bitte im [https://issues.joomla.org/ Joomla! Issue Tracker] berichten.


Before a stable release of Joomla is released the update needs testing.  This is a simple process:
==Probleme berichten==
# Install the current stable release of Joomla in a subfolder or on localhost (you can use a copy of a production site but '''never test on a live production site''').
[[Image:ReportingIssues.png|ReportingIssues.png]]
# Navigate to the Options of the Joomla! Update component and set the 'Update server' to 'Test'. [[S:MyLanguage/Help38:Components Joomla Update|Components Joomla Update]]
 
# When a Joomla pre release is ready for testing, log into your test site and install the Update.  Then test the site works as expected.  Please report any errors/bugs on the [https://issues.joomla.org/ Joomla! Issue Tracker]
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 [[jforum:728|Bug-Forum]].
==Reporting Issues==


[[Image:ReportingIssues.png|ReportingIssues.png]]
The process is normally started in one of two ways: the bug is added to the respective tracker, or a user reports the bug in the [https://forum.joomla.org/viewforum.php?f=728 Joomla! Bug Forum] for the given maintenance release.


=== Issues reported on the forum ===
===Problem im Forum berichtet===


JBS members scan the forums to determine when issues need to be put into the tracker. If the issue can be reproduced, is clearly a bug, and there are step-by-step instructions for how to reproduce it, it can be entered into the tracker with a status of Confirmed. If it is not as clear-cut, it can be entered with a status of Open, so that other JBS members will know it needs further investigation.
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.
=== Issues directly reported to the tracker ===
===Problem im Tracker berichtet===


When an issue is added to the tracker, the status could be depending on the situation;
Bei Eintrag eines Problems ist der Status im Tracker je nach Situation:
# New
#Neu
# Confirmed
#Bestätigt
# Pending
#Wartend
If the issue needs more investigation, then it should be set to New. If the issue (1) is a bug and (2) can be reproduced and (3) has good test instructions, it should be set to Confirmed. If it meets the three Confirmed criteria and also has a good patch attached, it should be set to Pending. See below for more information about the status codes.
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.


=== Issue Priorities ===
===Problem-Prioritäten===


[[S:MyLanguage/Bug and Issue Tracker Priority|Why most issues are priority 3]], or Normal. The artifacts are prioritized according to the following characteristics:
[[S:MyLanguage/Bug and Issue Tracker Priority|Warum die meisten Probleme Priorität 3]] oder Medium haben. Die Berichte werden nach dieser Charakteristik eingeteilt:


'''Critical (1):'''
'''Kritisch (1):'''
The trunk is not working at all. Significant parts of the source are broken preventing key operations. Examples would be login, installation, extension installers, javascript errors that prevent you from moving a save or similar action, etc. Also includes the generation of Fatal PHP errors and major security issues in a prerelease (Security issues for a stable release should NOT be reported in the tracker but instead reported to the security team security@joomla.org).
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 security@joomla.org berichten).


'''Urgent (2):'''
'''Dringend (2):'''
Parts of the source are obstructing operation in a serious way or causing a major loss in advertised function. Examples would includes PHP notices and warnings and reported javascript errors. Major issues will also typically prevent the release cycle from moving from Beta to Release Candidate (RC), or Release Candidate to General Availability (GA).
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):'''
'''Medium (3):'''
Issues that are hindering advertised behavior but the application is still workable. Examples would include parameters not working as advertised, language files not loading as expected, etc.
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.


'''Low (4):'''
'''Niedrig (4):'''
Minor loss of function and generally annoying behavior. May include less common platform or browser specific problems that while they may be technically major in those environments, they represent a minority. Also include missing translation strings.
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.


'''Very low (5):'''
'''Sehr Niedrig (5):'''
Cosmetic problems, misspelled words, graphically misaligned object, less common issues with parameters, etc.
Kosmetische Probleme, falsch geschriebene Wörter, graphisch unausgerichtete Objekte, wenig bekannte Fehler mit Parametern, etc.


== Resolving Issues ==
==Probleme lösen==


The bug squad takes care of the Joomla releases. For example, that means getting the 3.4, 3.5, 3.6, 3.7  etc releases ready by fixing problems that come up. The idea is to make the release increasingly stable and take care of issues that come up. At the same time, it is vitally important not to break anything that is working. That's called software regression and it's not something you want at this stage.
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.
In the trackers there are several common statuses, mainly: new, confirmed, pending, ready to commit.
Im Tracker gibt es unterschiedliche Status, meist: Neu, Bestätigt, Wartend, Fertig zum Anwenden.


* '''New''' means it's reported, but it hasn't been determined for sure whether it is a real bug or not. Many Open issues are not actually bugs. If the issue fits into one of the categories below, then the status is changed as indicated and the bug is closed:
* '''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.
** Cannot be reproduced. We have tried the same thing the reported did but the software appears to work correctly. (In many cases, more information is needed to be able to reproduce a bug. See "Information Required" below.) Change status to '''Unconfirmed Report'''.
** 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".
** Has already been reported in a different issue number. Change status to '''Duplicate report''' and add the number on the duplicates tab.
** Wurde bereits in einer anderen Fehlernummer berichtet. Statusänderung auf '''Doppelter Bericht''' mit Angabe der Original-Fehlernummer..
** Is a known limitation of the software. Change status to '''Known issue'''.
** Bekannte Einschränkung der Software. Statusänderung auf '''Bekanntes Problem'''.
** Is a feature request, a mistake made by a user, or is the way the software is intended to work. Change status to '''Expected Behaviour'''.
** Bei Featurewunsch, Benutzerfehler oder die Software arbeitet wie erwartet. Statusänderung auf '''Erwartetes Verhalten'''.
** Is a bug with an extension or some other external program or a server issue that will not be addressed. Change status to '''Closed''' and leave a comment explaining the reason.
** 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 Required''' is used if we need more information ''from the person who reported the issue'' to decide about the issue. For example, there are questions about how to reproduce the problem or other questions about the issue. If we get the information we need, then we can continue processing the issue. If we don't get the information within two weeks, then we can change the status to Unable to confirm (or another of the closed status codes if that is more applicable).
* '''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.
* '''Needs Review''' is used if we need a PLT Member or CMS Maintainer for a review / decision. This is different from Information Required, which means that we need more information from the person who reported the issue.
* '''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.
* '''Confirmed''' means that JBS has confirmed that this issue is a bug in Joomla! that should be fixed. That's when the JBS tries to solve it or consults with the development team about a solution. ''At this point there should be clear step-by-step test instructions that indicate how to reproduce the problem. For version 1.6, use the Test Instructions field for this information.''
* '''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.''
* '''Pending''' means that a patch has been submitted. Every Pending issue should have instructions that tell the tester how to reproduce the problem and make sure the patch fixes the problem.
* '''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.
* '''Ready to commit''' means that (in general) two separate people have successfully tested the same patch file, and it works correctly with the patch. Note that, for some issues that are more complex or higher impact, we may need more than two people to test or may need to test on multiple platforms. For simple issues, such as fixing typos in language strings or comments, one tester is enough.
* '''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.
* '''Fixed in Code Base''' means that, after reviewing the code, the JBS commit coordinators have determined that the patch is good and the change has been committed to the Joomla! code-base. At this point, it will be part of the next Joomla! maintenance release.
* '''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.
The '''Easy Test'''-mark is not a dedicated status, it is more a label to show Pending issues with easy test instructions.  
Die '''Leichter Test'''-Liste ist kein Status sondern zeigt wartende Patches mit leicht verständlichen Testinstruktionen.  




The flowchart below provides a visual guide to how the process for resolving bugs works.
Das Flussdiagramm zeigt, wie der Prozess zur Lösung von Bugs abläuft.


[[Image:ResolvingIssues.png|ResolvingIssues.png]]
[[Image:ResolvingIssues.png|ResolvingIssues.png]]

Latest revision as of 05:26, 19 June 2019

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

ReportingIssues.png

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 security@joomla.org 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.

ResolvingIssues.png