Il documento sulla garanzia di qualità descrive la procedura utilizzata per verificare la qualità dei rilasci stabili di OpenCity. Noi seguiamo questa procedura per essere sicuri che gli utenti finali non ricevano qualcosa di difettoso.
OpenCity è disponibile per molte distribuzioni GNU/Linux come Debian, Mandriva, Slackware, Ubuntu ecc... Il documento corrente riguarda solo i pacchetti principali di OpenCity: i sorgenti compressi in un file tar.bz2 e l'autoinstaller InnoSetup per Windows.
Il progetto è stato concepito con il termine "portabilità" in mente. Questo signica che il codice debba essere indipendente dalla piattaforma e possa girare su tutte le architetture possibili. Oggigiorno i processori a 64bit sono più diffusi ma non tutti ne hanno uno e per questo OpenCity deve poter essere eseguito e compilato su architetture a 32 e 64 bit senza alcuna modifica.
Per raggiungere questo livello di portabilità, OpenCity è stato scritto in C++ standard e ogni fantastica carattestica dipendente dal compilatore è assolutamente proibita. Inoltre il codice deve essere ben commentato. Gli algoritmi non ovvi che implementano un calcolo magico devono essere commentati e illustrati in pseudo-codice ogniqualvolta sia possibile.
Il periodo di test che avviene prima del rilascio ufficiale al resto del mondo è di 2 settimane. Ogni rilascio deve essere testato da almeno 1 tester per ogni sistema operativo supportato. I testers sono invitati a controllare i punti seguenti.
L'eseguibile e i dati devono poter essere installati con l'autoinstaller AutoPackage. L'installer deve posizionare un'icona nel menù "Giochi" del desktop e quando l'utente clicca sull'icona, questa deve lanciare il gioco senza nessun'azione ulteriore.
OpenCity è installato dai sorgenti con la formula magica:
./configure && make && make install
Il percorso di installazione può essere modificato con l'argomento "--prefix" passato a "./configure". L'installazione di OpenCity deve essere indipendente dal percorso cioè OpenCity deve funzionare anche se viene installato in un percorso diverso dal prefisso di default "/usr/local/".
Sotto Win32, OpenCity viene distribuito con un installer creato con InnoSetup. Anche qui si applica il requisito dell'installazione indipendente dal percorso. OpenCity deve poter funzionare qualsiasi sia la cartella d'installazione scelta dall'utente finale.
OpenCity dovrebbe funzionare senza problemi per almeno 6h durante le quali deve essere monitorato l'utilizzo di memoria perché OpenCity non deve avere nessun memory leak. Ogni segfault o crash è considerato come un blocco per una release stabile.
OpenCity deve essere fluido con tutta la città piena di costruzioni anche se è previsto un piccolo rallentamento.
Il gioco corrente può essere salvato su disco usando il comando appropriato e il formato dei files di salvataggio è indipendente dalla piattaforma. Ciò significa che l'utente deve poter salvare la partita sotto GNU/Linux e poi caricare da Windows o Macintosh e viceversa.
Se OpenCity è stato installato usando l'autoinstaller AutoPackage, il processo di disinstallazione viene svolto dall'autoinstaller. La disinstallazione consiste nello scrivere "package remove OpenCity" dalla linea di comando con i livelli di accesso richiesti. Leggi la documentazione di AutoPackage per ulteriori dettagli sui comandi.
La procedura di disinstallazione è svolta dal comando "make uninstall". Verrà anche creato uno script bash "uninstall" nella cartella "$PREFIX/opencity/bin" che può essere un metodo alternativo per eseguire la disinstallazione.
Una volta che l'installazione è avvenuta con successo, una scorciatoia per la disinstallazione è creata nel gruppo di OpenCity. Quando l'utente clicca sulla scorciatoia, OpenCity deve essere completamente rimosso.
Ogni utente è benvenuto a segnalare i bugs allo sviluppatore principale. Comunque, ogni bug report deve essere scritto correttamente e la cosa più importante è descrivere come poter riprodurre il bug. Altrimenti ci sarà solo una ridottissima possibiltà che il bug possa essere corretto nelle prossime versioni.
Un bug report corretto dovrebbe menzionare i punti seguenti: