Leitfaden für Maintainer#

Dieses Dokument definiert einen Maintainer als einen Beitragenden mit Zusammenführungsrechten. Die hier beschriebenen Informationen beziehen sich hauptsächlich auf Qiskit-Releases und andere interne Prozesse.

Stable-Branch-Policy#

Der Stable-Branch ist als sichere Quelle für die Behebung von schwerwiegenden Fehlern und Sicherheitsproblemen gedacht, die seit einem Release auf Master-Branch behoben wurden. Bei der Überprüfung eines PRs für den stabilen Branch müssen wir das Risiko eines jeden Patches gegen den Wert abwägen, den er für die Benutzer des stabilen Branchs hat. Nur eine begrenzte Anzahl von Änderungen ist für die Aufnahme in den stabilen Branch geeignet. Ein großer, riskanter Patch für ein großes Problem könnte Sinn machen, ebenso wie ein trivialer Fix eines Code-Branchs zur Behandlung von relativ selten auftretenden Fehlern. Bei einer Änderung muss eine Reihe von Faktoren abgewogen werden:

  • Das Risiko des Rückschritts: Selbst die kleinste Änderung bringt das Risiko mit sich, Fehler zu verursachen. Solche Rückschritte wollen wir auf dem Stable-Branch definitiv vermeiden.

  • Der Vorteil verbesserter Sichtbarkeit für Benutzer: Beheben wir etwas, was die Benutzer tatsächlich bemerken werden, und wenn ja, wie wichtig ist es?

  • Wie autark ist die Änderung: Wenn eine Änderung ein wichtiges Problem löst aber auch jede Menge Code überarbeitet, sollte man wahrscheinlich darüber nachdenken, wie ein weniger riskanter Fix aussehen könnte.

  • Whether the fix is already on main: a change must be a backport of a change already merged onto master, unless the change simply does not make sense on master.

Backporting#

When a PR tagged with stable backport potential is merged, or when a merged PR is given that tag, the Mergify bot will open a PR to the current stable branch. You can review and merge this PR like normal.

Aufbau der Dokumentation#

The way documentation is structured in Qiskit is to push as much of the actual documentation into the docstrings as possible. This makes it easier for additions and corrections to be made during development, because the majority of the documentation lives near the code being changed.

Refer to https://qiskit.github.io/qiskit_sphinx_theme/apidocs/index.html for how to create and write effective API documentation, such as setting up the RST files and docstrings.