Release Criteria/de

LibreOffice-Versionen werden strikt zeitbasiert veröffentlicht. Dabei wird weder auf Funktionen noch auf Fehlerkorrekturen gewartet, sondern so exakt wie möglich die Termine eingehalten. Das erzwingt Disziplin beim Korrigieren von Fehlern, ermöglicht gute Planbarkeit, und erlaubt eine hohe Regelmäßigkeit für die Erscheinungstermine neuer Versionen. Zeitgesteuerte Veröffentlichungsmodelle ergeben die höchste Qualität bei freier Software.

Zeitgesteuerte Erscheinungstermine eignen sich für alle Anwendertypen: Enthusiasten holen sich schon die Version X.Y.0 mit den allerneuesten Funktionen (und benannten Schwächen). Konservative Nutzer warten dagegen einen oder zwei der zeitnah erfolgenden Bugfix-Releases ab. Späte Bugfix-Versionen (etwa X.Y.3 oder .4) sollten selbst den konservativsten Ansprüchen genügen.

Kriterien
Ein Release Candidate (RC) kann als fertig (final) bezeichnet werden, wenn:


 * er mindestens 10 Tage veröffentlicht ist und kein Blocker (siehe unten) gefunden wurde

Blocker nominieren
Setze die Severity auf Blocker und füge dem Meta-Bug einen Kommentar und die Abhängigkeit an:

(*) Bitte auch alle Blocker checken!

(**) Bitte auch die nicht in den most annoying bugs enthaltenen Regressionen sowie alle Regressionen checken!

WICHTIG: Der Meta-Bug heißt most annoying bugs. Er listet Bugs, die für viele Anwender ärgerlich sind und im jeweiligen X.Y-Release gefixt werden sollten. Er hilft den Entwicklern beim Priorisieren, hat in der Regel jedoch keine aufschiebende Wirkung auf den Releasetermin. Nur Bugs mit der Severity "Blocker" können den Release aufhalten.

Beachte, dass Kommentare automatisch an die [mailto:libreoffice@lists.freedesktop.org libreoffice] Entwicklerliste gesendet werden.

Definition Blocker
Jede Software hat Fehler. Es können aber nicht alle Fehler behoben werden, da sonst die Software nie veröffentlicht werden könnte. Fehler, die eine Veröffentlichung blockieren können, müssen eines der folgenden Symptome aufweisen:


 * die Applikation kann nicht installiert werden
 * die Applikation startet nicht
 * Daten gehen verloren
 * die Applikation stürzt ab
 * oder friert ein
 * ein Sicherheitsloch
 * Lizenzprobleme
 * Unbrauchbare Funktion

Auch einige normale Fehler können die oben genannten Symptome aufweisen. Die richtigen Blockaden müssen die folgenden Bedingungen erfüllen:


 * das Problem muss von mehreren Benutzern nachgestellt werden können; wenn es nicht reproduzierbar ist, ist es meist ein Anwenderfehler; zudem brauchen die Entwickler mehr Informationen vom Berichterstatter; es ist nicht in Ordnung, eine Veröffentlichung und die Nutzer zu blockieren, wenn der Berichterstatter die benötigten Infos nicht zeitnah gibt
 * die unbrauchbare Funktionalität muss ein Rückschritt sein zur letzten veröffentlichten Version; was nicht bald gemeldet wird, ist meist eine selten genutzte Funktion und die Fehlerbehebung kann bis zum nächsten Release warten;
 * Datenverlust in Import-/Exportfiltern muss ein Rückschritt sein gegenüber der letzten veröffentlichten Version; LibreOffice hat sehr gute Import-/Exportfilter von/in viele Dateiformate; sie werden in jedem Release getestet, aber natürlich nicht zu 100%; manchmal sind sie abhängig von einer fehlenden Funktionalität; wenn das Problem keine Regression ist, wird es als Feature behandelt, und das ist kein Blocker
 * Problem muss viele Nutzer betreffen oder es gibt keinen gangbaren Umweg;es ist nicht gut, wenn eine Veröffentlichung und damit alle Nutzer wegen einer Kleinigkeit behindert werden, obwohl es einen sinnvollen Workaround gibt

Beachte: Die genannte Defintion sollte nicht zu eng gesehen werden. Jeder nominierte Fehler wird grundsätzlich auf der [mailto:libreoffice@lists.freedesktop.org libreoffice] mailing list beachtet. Es bedeutet also nicht, dass andere Fehler nicht während der Release Candidate-Phase gefixt werden. Wenn die Veröffentlichung geblockt ist, kann jeder immer noch sichere Fixes für andere kritische Fehler hinzufügen.