Guia de seguiment de problemes

Aquest document descriu el procés estàndard per tractar amb problemes nous als projectes de l’UBports. (No s’ha de confondre amb la guia guia per a l’escriptura d’un bon informe d’error.)

On se segueixen els errors?

El rastrejador principal de problemes d’Ubuntu Touch és el projecte ubports/development/ubuntu-touch GitLab project. Aquest projecte fa un seguiment de tots els problemes d’Ubuntu Touch a nivell de sistema, i serveix com a punt d’entrada perquè els usuaris informin dels problemes que han trobat.

Mentrestant, altres projectes del grup també tenen els seus rastrejadors d’incidències activats:

• Els problemes específics del dispositiu es rastregen sota el projecte de cada dispositiu sota el grup ubports/porting .

• Les aplicacions principals a ubports/development/apps fan un seguiment dels seus propis problemes.

• Els problemes del sistema també es poden presentar contra cada component a ubports/development/core directament, si està clar quin component és responsable d’un problema.

GitLab permet mostrar issues across the group, referència d’emissió creuada i transferència d’emissió entre projectes, fent que el projecte exacte sigui menys important. Si un problema específic del port o del lloc web va acabar en un projecte d’ubports/desenvolupament/ubuntu-touch, es poden traslladar al projecte apropiat.

Etiquetes

Tots els problemes - fins i tot els tancats - s’haurien d’etiquetar per permetre l’ús del filtratge global del GitHub. Per exemple aquests són tots els problemes etiquetats amb «kind=enhancement» dins del grup ubports/developement . Consulteu les Pàgines d’ajuda del Gitlab per a més informació sobre la cerca i el filtratge.

Les etiquetes següents s’utilitzen dins dels projectes UBports. Atès que les sol·licituds de fusió (MR) a GitLab comparteixen el mateix conjunt d’etiquetes, algunes de les etiquetes següents també es poden aplicar a les sol·licituds de fusió.

Tasca pendent

Considereu també escriure un document sobre el procés de tractar amb les sol·licituds de fusió.

• Kind: descriu la naturalesa del problema

  • Kind: error: aquest problema descriu alguna cosa que no funciona correctament.

  • enhancement: Millora - Aquest problema és una demanda de funcionalitat.

  • Kind: manteniment: aquest problema descriu un deute tècnic; una cosa que hem de netejar.

  • Kind: FTBFS: aquest problema descriu un problema de «Fails to Build From Source» (un accrònim de Debian).

  • Kind: processa: aquest problema és un problema de seguiment per a algun procés. Per exemple, un procés en llançar un llançament d’Ubuntu Touch.

  • question: Pregunta - Aquest problema és una demanda de suport o una pregunta general.

• Needs: descriu alguna acció que es pot/ha de fer

  • Neds: ajuda de la comunitat: els mantenidors actualment no tenen capacitat per resoldre aquest problema i els agradaria l’ajuda de la comunitat.

  • needs confirmation: Cal confirmació - A l’error li cal confirmació i / o més informació dels usuaris afectats.

  • Needs: feedback from author: s’utilitza per marcar una sol·licitud de fusió que requereix una retroalimentació de l’autor després d’una revisió. Això és diferent de Needs: confirmació/més informació que està destinat a ser utilitzat en un problema.

  • Needs: discussió: no està clar com resoldre aquest problema i es requereix més discussió.

  • Needs: rebase: aquesta sol·licitud de fusió s’ha de tornar a basar, però els mantenidors no tenen permís per empènyer a la branca d’origen.

• Severitat: com de greu és el problema.

  • Severitat: crítica: aquest problema és molt greu i hauria de bloquejar el desplegament de la versió (definida per la seva fita).

• Àrea: aquest problema està relacionat amb una àrea determinada d’Ubuntu Touch (p. ex. HAL, middleware, UI). Les etiquetes d’aquest prefix es poden crear segons correspongui.

• Topic: aquest problema està relacionat amb un tema d’interès determinat (p. ex. VoLTE, migració del dorsal de contacte). Les etiquetes d’aquest prefix també es poden crear segons correspongui.

• Resolució: utilitzada quan es tanca el problema per una altra raó que el problema que s’està solucionant.

  • Resolució: no es pot confirmar: no es pot reproduir el problema i no es proporciona prou informació.

  • Resolució: no és el nostre error: el problema no és un problema a Ubuntu Touch, sinó que és un problema en un programari de tercers instal·lat per l’usuari.

  • wontfix: No s’arreglarà - No té sentit arreglar aquest error, atès que probablement s’arreglarà per sí mateix, implicaria molta feina arreglar-lo, no es pot arreglar, o algun component subjacent canviarà aviat.

  • Resolució: treball segons el que es pretén: El comportament descrit en el problema és el comportament previst del programari.

• Aporta a: <branch name>: utilitzat per l’automatització per tornar enrere automàticament un MR a una branca d’alliberament estable.

• Etiquetes diverses

  • Bon primer problema: l’informe conté instruccions o consells necessaris per a solucionar-lo. És un lloc excel·lent perquè algú nou aprengui sobre el projecte solucionant un problema real.

  • Hotfix: Aquest MR/issue classifica per ser inclòs/resolt com a part d’un llançament puntual d’Ubuntu Touch

Nota

Si un repositori que segueix els problemes localment defineix les seves pròpies etiquetes, s’haurien de documentar al README.md.

Estat

El camp Estat s’utilitza per indicar el progrés de la incidència. Hem definit els següents estats:

• Nou: Aquest és l’estat d’un problema recentment obert. Això indica que aquest problema no està provat; s’anima als desenvolupadors i trígers a triar els problemes, assignar tipus i altres etiquetes, decidir si aquesta qüestió justifica una fita, etc. Alternativament, si un problema és un element de treball, un problema de seguiment, o alguna cosa similar presentat pels desenvolupadors, aquest estat es pot ometre.

• Ready to be worked on: Indica que aquest problema es tria i es pot treballar.

Nota

Aquest estat substitueix l’estat predeterminat de «Fer».

• Bloquejat: Indica que una altra cosa s’ha de resoldre fora d’aquest problema abans que aquest problema pugui progressar.

• En progrés: Indica que un desenvolupador està treballant activament en el problema. La qüestió s’ha d’assignar a aquest desenvolupador.

• Ha MR: Hi ha un MR que no és un projecte que solucionarà aquest problema.

• Fet: El problema s’ha solucionat a la branca main.

• Duplica: El problema és un duplicat. GitLab estableix aquest estat automàticament quan el problema està marcat com a duplicat.

• No ho faré: El problema es tanca per una altra raó que el problema que s’està solucionant. Hauria de tenir etiquetes «Resolució: *» per explicar el motiu (vegeu més amunt).

Fites

Les fites s’utilitzen per definir quin alliberar un objectiu d’emissió. En un moment donat, s’obren fins a 3 fites:

• Una fita per al proper llançament estable, p. ex. “Ubuntu Touch 24.04-1.1”.

• Una fita per al llançament principal en desenvolupament, p. ex. “Ubuntu Touch 24.04-2.0”.

• Una vegada que el llançament en desenvolupament entra en una fase d’estabilització, es pot crear una fita per al següent llançament principal (p. ex. “Ubuntu Touch 24.04-3.0”).

S’anima als desenvolupadors a evitar assignar massa problemes a una fita; una fita desbordant fa que la fita no sigui tan útil com podria ser en el seguiment del progrés d’un llançament.

Assignats

Per fer transparent qui està treballant en un problema, s’hauria d’assignar el desenvolupador. Això permet també usar el filtratge global de GItHub com una mena de llista de tasques pendents.

Es demana als desenvolupadors de mantenir la seva llista curta i mantenir actualitzat l’estat del seus problemes.

Tauler d’errors del GitLab

Utilitzem els taulers d’emissió de GitLab per visualitzar el progrés dels problemes en cada fita. Els taulers són taulers kanban, on cada columna correspon a cada estat definit (nou, preparat per ser treballat, bloquejat, en curs, té MR, fet, duplicat, no ho farà).

Èpica del GitLab

Utilitzem les èpiques de GitLab per denotar un tema que podria abastar fites/llançaments individuals o múltiples. Això ajuda a organitzar alguns objectius a llarg termini que són massa grans per implementar alhora.

Com s’estan utilitzant les etiquetes, les fites, etc.?

Penseu en les etiquetes, les fites i altres camps com a eines que una persona pot utilitzar per comunicar-se eficientment amb el reporter, altres desenvolupadors i parts interessades. Es podrien utilitzar de diverses maneres:

• Com que aquests camps es mostren a la llista d’incidències, pot donar una informació a-a-glance sobre el problema, ajudant els desenvolupadors a comprendre ràpidament el problema. Per exemple, un desenvolupador podria mirar un problema a la llista, notar que el problema té etiqueta «necessita discussió», i decidir saltar per donar els seus 2 cèntims.

• Un camp es podria utilitzar per filtrar només els problemes interessats. Per exemple, un membre de la comunitat que vulgui contribuir a confirmar problemes pot filtrar només problemes amb l’etiqueta «necessita confirmació» i començar a saltar.

• També es podria utilitzar un camp per filtrar problemes no interessants. Per exemple, quan un desenvolupador vol buscar un problema en el qual treballar, es vol filtrar l’etiqueta «Kind: process» (utilitzada per exemple per al seguiment d’un problema per a una versió).

Com que no sempre tenim algú que triï específicament els problemes i estableixi aquestes etiquetes, s’anima als desenvolupadors a establir tots aquests camps a mesura que treballen en un problema. Això ajudarà a minimitzar el que s’ha fet sobre el tema, i també ajudarà a resumir el problema per a una comprensió més ràpida.