[Gruppo FCM] R: R: R: R: Fwd: suddivisione Q&A speciale FCM #68

Mer 23 Gen 2013 14:00:13 GMT

Perfetto.
Grazie Jacopo.

Il giorno 23 gennaio 2013 14:57, Jacopo Zilio <jacopozilio a gmail.com> ha
scritto:

> Eccola!****
>
> ** **
>
> TESTING
>
>
> D Quante persone / team di test di Ubuntu, e con quale frequenza? Inoltre,
> come viene testato? Viene testato per pacchetto, o come distro tutto
>  insieme?
> R C'è il team della comunità guidato da Nicholas Skaggs che fa uno sforzo
> impressionante per avere sempre più la partecipazione della comunità nei
> test. In aggiunta a ciò, abbiamo la squadra QA, che installa e verifica
> l'installazione periodicamente. La verifica gli aggiornamenti da versione a
> versione è un compito molto difficile, soprattutto con le transizioni e le
> altre cose che cambiano fra le release. Per far fronte a questo, abbiamo
> test automatici di aggiornamento che installano una versione precedente di
> Ubuntu su una macchina, cambiano alcune configurazioni, e aggiornano alla
> prossima versione. Ogni giorno c’è anche un installatore automatico
> dell’ISO più recente, il quale assicura che le ultime ISO prodotte possano
> essere installate ogni giorno.
> Quindi, noi abbiamo più tipi di test:
> test di unità che sono abilitati durante la compilazione. La compilazione
> fallirà se non passa.
> test automatici dei pacchetti, che vengono testati e confrontati con la
> versione installata del componente. Questi se non passano tale test non
> verranno copiati nella lista dei pacchetti per il  rilascio.
> test  delle ISO e test di aggiornamento, fatti ogni giorno e
> automaticamente.
> test manuali su base regolare delle ISO e di alcuni componenti (Nicholas
> sta cercando di ottenere aiuto perquesta operazione, seguire planet Ubuntu
> per maggiori informazioni).
> alcuni componenti, come l'intero ecosistema Unity (60 componenti) hanno
> prove supplementari che vengono eseguite su base quotidiana, anche prima di
> essere caricato sulla distro.
>
>
> D Come si fa a garantire che i pacchetti vitali o necessari non manchino?
> R Ci sono sempre più prove automatizzate che consentono l'esecuzione di
> una sessione completa e di testare applicazioni come l’esperienza core. In
> questo modo possiamo vedere che manca un componente fondamentale dopo
> l'installazione dell’ISO giornaliera. Si noti anche che un pacchetto
> mancante per caso sarà probabilmente su un elenco di componenti per mancata
> corrispondenza (manca dal main o è lì senza alcun motivo) - questo è un
> altro modo di avvistare questo :)
> Se le ultime ISO non vengono compilate a causa di un componente mancante o
> di una mancata corrispondenza, noi lo notiamo subito. La mancata
> corrispondenza non dovrebbe esserci più con le ulteriori misure che abbiamo
> introdotto in Raring. Ora tutti i pacchetti stanno in una “tasca” proposta
> (simile a quando facciamo Aggiornamenti stabili di versione), e vengono
> convalidati prima di essere copiati nella “tasca” di rilascio nell'archivio
> principale. La convalida assicura che l’archivio non si giunga allo stato
> di non-funzionante.
>
>
> D Provate le vecchie macchine? Es: porta parallela, floppy, ecc..
> R Questo viene fatto con test manuale la maggior parte delle volte. Martin
> Pitt sta introducendo di alcuni oggetti fittizi (oggetti falsi utilizzati
> per scopi di test) per essere in grado di individuare regressioni per
> vecchie configurazioni del genere, ma, siamo onesti, l'obiettivo di Ubuntu
> non è quello di essere in grado di girare su hardware così vecchio, ci sono
> altre distribuzioni mirate per macchine con più di 10 anni :)
>
>
> D Il benchmark di Ubuntu viene fatto durante la produzione o prima del
> rilascio?
> R Ci sono alcuni limitati benchmark automatizzati, ma questo è un settore
> che stiamo sviluppando e siamo sempre migliori con ogni uscita. Questo e
> test automatici sono due storici punti deboli focali del software libero.
> Al giorno d'oggi, Ubuntu sta cambiando questa mentalità, mettendoli al
> centro dell’esperienza utente. Quindi stiamo lavorando sempre più su questa
> direzione al fine di aiutare l'intero ecosistema ad evolvere su di esso.
>
>
> D C'è un modo semplice (per gli utenti/tester) a seguire un bug dalla
> segnalazione alla risoluzione?
> R Abbastanza facile! Basta trovarlo su launchpad (normalmente, il metodo
> più efficiente è cercare direttamente il bug sul pacchetto che si pensa
> difettoso), e fare clic sul pulsante di iscrizione sul
> https://bugs.launchpad.net/ubuntu/+bug/ 1. Vi arriveranno tutte le
> notifiche (e numerosi commenti) sui cambiamenti di stato. Quando la
> componente di Ubuntu del bug è contrassegnato come "Fix Released", questo
> significa che la correzione è ora nella versione di sviluppo.
> È possibile, dalll'interfaccia launchpad, chiedere il backport della
> correzione per una versione precedente e monitorare il suo stato lì
>
>
> D Esiste un processo per determinare l'origine di un difetto in un test?
> R Questo si basa più sull'esperienza della distro, sulla conoscenza dei
> componenti che fanno ciò e sul fare dogfooding [
> http://en.wikipedia.org/wiki/Eating_your_own_dog_food]. Avere il bug
> confermato è un buon inizio per avere una panoramica generale sui
> componenti di una distribuzione Ubuntu e capire che cosa può essere la
> causa principale di quel problema. ****
>
> _______________________________________________
> I traduttori della rivista Full Circle Magazine
> Per modificare o revocare l'iscrizione:
> http://liste.ubuntu-it.org/cgi-bin/mailman/listinfo/ubuntu-it-fcm
>
>

-- 
Fabrizio NICASTRO
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://liste.ubuntu-it.org/pipermail/ubuntu-it-fcm/attachments/20130123/7c9236d2/attachment.htm>