Guide des mainteneurs#

Ce document définit un maintainer comme un contributeur disposant de privilèges de fusion. Les informations détaillées ici sont principalement liées aux versions de Qiskit et aux autres processus internes.

Politique de la branche stable#

La branche dite stable est la source saine des différentes corrections des anomalies majeures identifies et corrigées dans le master depuis la dernière version. Toute modification de cette branche stable doit se faire en évaluant en premier le risque lié à la modification et en le comparant au bénéfices obtenus. Seuls quelques changements bien identifiés doivent être inclus dans cette branche stable. Une correction majeure mais adressant une anomalie critique ou bien une correction triviale pour une fonctionnalité très mineure peuvent être considérées. Dans tous les cas, il est bon de considérer les points suivants :

  • Le risque de régression : même la plus petite des modifications peut avoir un impact sur la stabilité du code. Et l’objectif est bien entendu de garder la branche stable la plus sûre possible.

  • Le bénéfice utilisateur : sommes-nous en train de corriger quelque chose constaté par les utilisateurs ? Cela apporte-t-il un réel gain pour eux ?

  • La portée de la correction : si cette correction règle un problème important, mais qu’elle engendre des modifications fortes du code, il doit être envisagé d’imaginer une correction plus légère.

  • 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.

Structure de la Documentation#

La façon dont la documentation est structurée dans Qiskit est de pousser autant que possible la documentation réelle dans les ficelles. Il est ainsi plus facile de faire des ajouts et des corrections au cours du développement, car la majorité de la documentation vit près du code modifié.

Consultez le site https://qiskit.github.io/qiskit_sphinx_theme/apidocs/index.html pour savoir comment créer et écrire des documents d’API efficaces, tels que la configuration des fichiers RST et des chaînes de caractères.