Lines Matching refs:un

20 - Deve correggere un vero baco che causi problemi agli utenti oppure aggiunge
21   un nuovo identificatore di dispositivo. Maggiori dettagli per il primo caso:
23   - Corregge un problema come un oops, un blocco, una corruzione di dati, un
24     vero problema di sicurezza, una stranezza hardware, un problema di
30     correzione ha un'alta probabilità d'introdurre una regressione,
32     includendo un link, se esiste, ad un rapporto su bugzilla, e informazioni
34   - Non si accettano cose del tipo "Questo potrebbe essere un problema ..."
50 1. Aggiungi un'etichetta 'stable' alla descrizione della patch al momento della
62 L':ref:`it_option_3` è un'alternativa ai due metodi precedenti quando la patch
142 Esiste un'ulteriore variante per l'etichetta "stable" che permette di comunicare
143 allo strumento di *backporting* di ignorare un cambiamento::
176 principali (per esempio per adattarsi ad un cambiamento di API), allora questo
182 Il mittente riceverà un ACK quando la patch è stata accettata e messa in coda,
183 oppure un NAK se la patch è stata rigettata. La risposta potrebbe richiedere
192 - Quando i manutentori -stable decidono di fare un ciclo di revisione, le
199 - Se una patch viene rigettata da un membro della commissione, o un membro
203 - Le patch che hanno ricevuto un ACK verranno inviate nuovamente come parte di
204   un rilascio candidato (-rc) al fine di essere verificate dagli sviluppatori e
210 - Si può rispondere ad una -rc scrivendo sulla lista di discussione un'email
239     I sorgenti -stable-rc sono un'istantanea dei sorgenti stable-queue e
241     Dovrebbe essere usato solo allo scopo di verifica (per esempio in un