Recommandations pour le suivi des problèmes

Ce document décrit la méthode standard de gestion des nouveaux problèmes dans les projets d’UBports. (À ne pas confondre avec le guide de rédaction d’un bon rapport de problème.)

Où sont suivis les problèmes ?

Le principal outil de suivi des problèmes pour Ubuntu Touch est le projet GitLab ubports/development/ubuntu-touch. Ce projet suit tous les problèmes liés au système Ubuntu Touch et sert de point d’entrée aux utilisateurs pour signaler les problèmes qu’ils ont rencontrés.

Par ailleurs, d’autres projets du groupe ont également activé leurs outils de suivi des problèmes :

• Les problèmes spécifiques à chaque appareil sont suivis dans le cadre du projet correspondant, sous le groupe ubports/porting group.

• Les applications principales sous ubports/development/apps suivent leurs propres problèmes.

• Les problèmes système peuvent également être signalés directement pour chaque composant sous ubports/development/core, s’il est clair quel composant est responsable d’un problème.

GitLab permet d’afficher les problèmes à l’échelle du groupe, les références croisées entre projets et les transferts de problèmes entre projets, ce qui rend moins important le projet exact dans lequel un problème est signalé. Si un problème spécifique à un port ou à un site web se retrouve dans le projet ubports/development/ubuntu-touch, il peut être déplacé vers le projet approprié.

Mots-clés

All issues — even closed ones — should be labeled to allow use of GitLab’s filtering. For example, these are issues labeled “Kind: enhancement” inside ubports/development group. Consult the GitLab help pages to learn more about searching and filtering.

Les étiquettes suivantes sont utilisées dans les projets UBports. Étant donné que les demandes de fusion (MRs) dans GitLab partagent le même ensemble d’étiquettes, certaines des étiquettes ci-dessous peuvent également s’appliquer aux demandes de fusion.

À faire

Pensez également à rédiger un document sur le processus de traitement des demandes de fusion.

• Kind: décrivez la nature du problème

  • Kind: bug (bogue): ce problème décrit un dysfonctionnement.

  • Kind: enhancement: (amélioration) : ce problème concerne une demande de fonctionnalité ou décrit un point à améliorer.

  • Kind : maintenance : ce problème décrit une dette technique ; quelque chose que nous devons corriger.

  • Kind: FTBFS (type FTBFS): décrit un problème du type « Fails To Build From Source » (« Échec de la construction à partir du code source ») (un accronyme de Debian).

  • Kind: process : ce type sert à suivre l’avancement d’un projet. Par exemple, un projet lié à la publication d’une version d’Ubuntu Touch.

  • Kind:question : ce problème est une demande de soutien ou une question d’ordre général.

• Needs: décrit une action qui peut/doit être effectuée

  • Needs: help from community : les responsables du projet n’ont actuellement pas les moyens de résoudre ce problème et sollicitent l’aide de la communauté.

  • needs: confirmation/more info : le bogue demande une confirmation et / ou un complément d’information par les utilisateurs concernés.

  • Needs: feedback from author: (Besoin : avis de l’auteur) utilisé pour signaler une demande de fusion qui nécessite l’avis de l’auteur après révision. Cela diffère de Needs: confirmation/more info (Besoin : confirmation/plus d’informations), qui est destiné à être utilisé sur un ticket.

  • Needs: discussion:(À discuter) la manière de résoudre ce problème n’est pas claire et une discussion plus approfondie s’impose.

  • Needs: rebase : cette demande de fusion doit être rebasée, mais les responsables n’ont pas l’autorisation de pousser vers la branche source.

• Severity: (Gravité) quel est le degré de gravité du problème ?

  • Severity: critical : ce problème est très grave et devrait empêcher le déploiement de la version (tel que défini par son jalon).

• Area: Ce ticket concerne un domaine spécifique d’Ubuntu Touch (par exemple, HAL, middleware, interface utilisateur). Des étiquettes comportant ce préfixe peuvent être créées selon les besoins.

• Topic: Ce ticket concerne un sujet particulier (par exemple, la VoLTE ou la migration du backend des contacts). Des étiquettes commençant par ce préfixe peuvent également être créées si nécessaire.

• Resolution: utilisé lorsque le ticket est clôturé pour une raison autre que la résolution du problème.

  • Resolution: unable to confirm : nous ne parvenons pas à reproduire le problème et les informations fournies sont insuffisantes.

  • Resolution: not our bug : le problème ne provient pas d’Ubuntu Touch, mais d’un logiciel tiers installé par l’utilisateur.

  • Resolution: won’t fix (ne sera pas corrigé) : Un bug qu’il n’est pas judicieux de corriger, car il va probablement se résoudre de lui-même, demanderait trop de travail, est impossible à corriger ou parce qu’un composant sous-jacent va bientôt changer.

  • Resolution: work as intended: The behavior described in the issue is the intended behavior of the software.

• Backport to: <branch name>: used by the automation to automatically backport an MR to a stable release branches.

• Miscellaneous labels

  • Good first issue (Un bon premier Ticket) : le rapport contient les instructions ou les conseils nécessaires pour résoudre le problème. C’est un excellent moyen pour un nouveau venu de se familiariser avec le projet en résolvant un vrai problème.

  • Hotfix: This MR/issue classifies for being included/resolved as part of a point release of Ubuntu Touch

Note

Si un dépôt qui gère des tickets en local définit ses propres étiquettes, celles-ci doivent être documentées dans le fichier README.md.

Status

Status field is used to indicate the progress of the issue. We’ve defined the following statuses:

• New: This is the status for a newly-opened issue. This indicates that this issue is untriaged; Developers and triagers are encouraged to triage issues, assigns kind and other labels, decide whether this issue warrants a milestone, etc. Alternatively, if an issue is a work item, a tracking issue, or something similar filed by developers, this status can be skipped.

• Ready to be worked on: Indicates that this issue is triaged and can be worked on.

Note

Ce statut remplace le statut par défaut « To Do » (À Faire).

• Blocked: Indicates that something else has to be solved outside of this issue before this issue can progress.

• In progress: Indicates that a developer is actively working on the issue. The issue should be assigned to that developer.

• Has MR: A non-draft MR exists that will fix this issue.

• Done: The issue has been fixed in the main branch.

• Duplicate: The issue is a duplicate. GitLab sets this status automatically when the issue is marked as a duplicate.

• Won’t do: The issue is closed for other reason than the issue being fixed. It should have « Resolution: * » labels to explain the reason (see above).

Jalons

Milestones are used to define which release an issue targets. At a given time, up to 3 milestones are open:

• A milestone for the upcoming stable release e.g. “Ubuntu Touch 24.04-1.1”.

• A milestone for the in development major release e.g. “Ubuntu Touch 24.04-2.0”.

• Once the in development release enters a stabilization phase, a milestone for the next major release (e.g. “Ubuntu Touch 24.04-3.0”) can be created.

Developers are encouraged to avoid assigning too many issues to a milestone; an overflowing milestone makes the milestone not as useful as it could be in tracking progress of a release.

Cessionnaires

Pour que l’on sache clairement qui travaille sur un ticket, il convient d’y affecter un développeur. Cela permet également d’utiliser le filtrage global de GitLab comme une sorte de liste de tâches.

On demande aux développeurs de veiller à garder une liste courte et de mettre régulièrement à jour le statut de leur différentes tâches.

GitLab issue board

We use GitLab’s issue boards to visualize progress of issues in each milestone. The boards are kanban boards, where each column corresponds to each defined status (new, ready to be worked on, blocked, in progress, has MR, done, duplicate, won’t do).

GitLab epic

We use GitLab’s epics to denote a topic which might span single or multiple milestones/releases. This helps organizing some long-term goals which are too large to implement at once.

How labels, milestone etc. are being used?

Think of labels, milestone, and other fields as tools a person can use to efficiently communicate with the reporter, other developers, and interested parties. They could be use in a few ways:

• Because those fields show up in the issue list, it can give an at-a-glance info about the issue, helping developers to quickly understand the issue. For example, a developer could look at an issue on the list, notice that the issue has « needs discussion » label, and decide to jump in to give their 2 cents.

• A field could be used to filter only interested issues. For example, a community member wanting to contribute into confirming issues can filter only issues with « needs confirmation » label and start jumping in.

• A field could also be used to filter out uninteresting issues. For example, when a developer want to look for an issue to work on, one would want to filter out « Kind: process » label (used for e.g. tracking issue for a release).

Since we don’t always have someone to specifically triage issues and set those labels, developers are encouraged to set all those fields as they work on an issue. This will help comminicating what has been done on the issue, and also help summarizing the issue for quicker understanding.