Bugzilla/Guida ai rapporti dei Bug

From Gentoo Wiki
Jump to:navigation Jump to:search
This page is a translated version of the page Bugzilla/Bug report guide and the translation is 100% complete.
Other languages:
English • ‎italiano • ‎русский • ‎中文(中国大陆)‎ • ‎日本語 • ‎한국어

Consigli e Best practices

  • Rileggere il testo prima dell'invio, il testo non può essere modificato in seguito. Inoltre, qualsiasi testo inserito in una segnalazione di bug verrà solitamente inviato immediatamente via e-mail a molte persone. Scrivi in un linguaggio preciso e pulito ed evita discorsi colloquiali. Suggerimento: Immagina di avere una sola possibilità nella tua vita di scrivere questo importantissimo bug report. Sai che il destinatario può leggere l'inglese, ma non è la sua lingua madre.

Cercare i duplicati, prima di creare un nuovo bug.

  • Resta in tema - Un bug ticket viene utilizzato per i rapporti tecnici e le chiacchiere dovrebbero essere evitate. Conservali nei channel (forum, IRC o mailing list).
  • Conferma l'esistenza deol bugsolo una volta - Non aiuta a risolvere il problema se tu e un'altra persona lo segnalate due volte. Ma se il tuo sistema e quello del bug confermato differiscono in modo ovvio e sarebbe utile saperlo, aggiungi queste informazioni.
  • Apri un bug ticket per argomento - Solitamente questo significa non più di un pacchetto e un bug per ticket. Se il tuo problema non viene discusso su un bug, cercane uno correlato al tuo problema o crea un nuovo rapporto. Non dirottare i bug.
  • Non si parla di bug TRACKER. - Questi bug sono meta bug. Se vuoi aggiungere informazioni utili, aggiungile a un bug secondario correlato o crea un nuovo bug.
  • Opzionale: Consulenti Gentoo forniscono anche supporto commerciale per bug ed ebuild.
  • Allega i log al bug ticket se il ticket riguarda problemi durante il runtime o l'installazione.

Packages/ebuild

Si dovrebbero sempre aggiungere le informazioni sulla configurazione del sistema per la segnalazione di un bug. Per fare questo, creare un nuovo attachment e incollare il contenuto di:

user $emerge --info > /tmp/emerge--info.txt

Problemi al momento del build (emerge fallito)

Usa il pulsante Aggiungi un allegato sotto la casella di testo della descrizione per allegare file in bugzilla.
  • Prima scrivi la versione esatta del pacchetto nel titolo della segnalazione di bug, ad es. sys-apps/package-2.3-r4
  • Aggiungi una breve descrizione al titolo.
  • Allega i log al bug ticket

Problemi durante il funzionamento

I file e le informazioni di interesse in ordine di priorità:

  • La versione esatta del pacchetto nel titolo della segnalazione di bug, ad es. sys-apps/package-2.3-r4 si arresta in modo anomalo con errore: Impossibile procedere...
  • Descrizione del problema, in modo che altri possano riprodurlo:
    • Come viene eseguito il programma (sulla console, in un terminale, come demone, in quale runlevel ecc.)
    • Qualsiasi output di errore
    • Ciò che fa crashare il programma, comportarsi male, non avviarsi
    • C'è una soluzione?
    • Qual era l'ultima versione funzionante del pacchetto, se presente?
    • Cosa è cambiato per non farlo funzionare?
  • Allega i log al bug ticket

Segnalare un aumento della versione; una nuova versione upstream è disponibile da un po'

  • Cerca su Bugzilla prima di inviare una richiesta di bump - c'è già un bug aperto? L'albero di Portage locale è stato sincronizzato ultimamente; è già su Portage?
  • Evita le richieste bump zero-day (attendere almeno 48 ore dopo l'annuncio del rilascio)
  • E' stato effettivamente rilasciato da fonti upstream, o è solo contrassegnato nell'albero dei sorgenti? Alcuni progetti segnano un rilascio nell'albero molto tempo prima che venga rilasciato ufficialmente.
  • Assicurati di menzionare se compila e funziona bene sulla tua architettura. Qualsiasi altra informazione utile fornita è benvenuta.
  • Aggiungi un collegamento al sito Web a monte
  • Fornisci un link o un elenco di bug corretti o nuove funzionalità (a volte chiamato changelog)
  • Scrivi un riepilogo nella forma app-editors/vim-12.3.5 version bump

Opzioni

  • Funziona una semplice copia o l'ebuild necessita di modifiche? (dipendenze modificate, file di patch obsoleti)
  • Testa l'ebuild in un overlay locale prima di inviare gli allegati
  • Fornire patch per le modifiche proposte all'ebuild, con una spiegazione facoltativa delle modifiche (il nome del file deve corrispondere al nuovo numero di versione, non al vecchio)
  • Fornire file aggiuntivi (initd, file unit) come allegati separati (se necessario)
  • Non incollare i file direttamente nei commenti; usa gli allegati.

Richiesta di un nuovo pacchetto; richiesta ebuild

Se si richiede una nuova ebuild per un software da aggiungere a Portage, è necessario trovare o diventare un manutentore per il pacchetto.

Se esiste già una segnalazione di bug per il pacchetto, puoi aiutare mantenendo aggiornate le informazioni sul pacchetto. Se aggiungi un componente -VERSION al pacchetto atom, allora questo può essere aggiornato con nuove versioni nel tempo mentre il bug report non viene mantenuto per mostrare che c'è un interesse continuo nel vederlo integrato nell'albero di portage.

Se non esiste alcuna segnalazione di bug per il pacchetto, è possibile inviare una segnalazione di bug nel progetto Gentoo Linux e nel componente Nuovo pacchetto.

Il Riepilogo della tua segnalazione di bug dovrebbe elencare un atom di pacchetto (preliminare) categoria/pacchetto, magari con un suffisso -VERSION, seguito da una breve descrizione canonica del pacchetto (la voce DESCRIZIONE variabile in un ebuild). È importante disambiguare il nome del nuovo pacchetto: se l'upstream usa nomi diversi per lo stesso software, magari un'abbreviazione oltre al nome completo, dovresti menzionarli entrambi (tutti) nel Sommario in modo che altre persone possano trovare segnalazioni di bug sullo stesso software. Se più (gruppi di) persone tengono traccia di diverse segnalazioni di bug riguardanti virtualmente la stessa richiesta di ebuild, questo raddoppierà lo sforzo di ricerca e sviluppo di ebuild e dividerà le persone che hanno un interesse comune.

Dovresti collegarti al sito web upstream (la variabile HOMEPAGE in un ebuild) usando il campo URL. Dovresti fornire un elenco di funzionalità nella Descrizione della segnalazione di bug. Questo potrebbe essere preso direttamente dal sito Web originale o da un manuale o altra documentazione e potrebbe essere utilizzato in seguito per il tag longdescription in metadata.xml.

Puoi allegare un ebuild e i relativi file che dovrebbero andare nell'albero di portage direttamente al bug report, oppure puoi usare il campo See also per fare riferimento a un git pull request .

Puoi aiutare a sviluppare il pacchetto impostando un local overlay con i tuoi ebuild, metadati, patch e altri file ausiliari. Se hai bisogno di supporto tecnico per lo sviluppo del tuo ebuild, molte persone sarebbero felici di [1].

Pacchetto XY deve essere contrassegnato stabile

Se un pacchetto viene compilato e funziona senza problemi sul sistema per più di 30 giorni e non è ancora contrassegnato come stabile puoi creare una richiesta stabile.

Kernel

File e informazioni di interesse per i rapporti di bug relativi al kernel in ordine di priorità:

  • Quale kernel e versione vengono utilizzati, su quale architettura, ad es. gentoo-sources-3.4.2-r2 su x86_64
  • Il file di configurazione del kernel dovrebbe essere allegato al bug report (/usr/src/linux/.config)
  • Un elenco di tutti i dispositivi nel sistema può essere acquisito con lspci -k
  • Devono essere allegati i file di registro durante l'inizializzazione del kernel (/var/log/dmesg o /var/log/messages)
Note
Su richiesta, un kernel git-bisect potrebbe essere fatto per identificare le patch difettose

Vedi anche