= Bug/issue tracking =
O problema, eroare, defect, posibilitate nedocumentate, greaseala intr-un sistem software care impiedica sistemul sa functioneza asa cum este de asteptat este un bug.
Un raport care detaliaza un bug intr-un program, adica cum se manifesta, cand, care parte a codului este responsabila, eventual si o solutie posibila.
Bug tracking-ul este un mod organizat de a tine evidenta bugurilor si a starilor acestora(deschis, rezolvat, testat, inchis). Acesta poate varia de la forma neorganizate (intalniri in echipa) la forme organziate liste de discutii, mailuri pana la solutii specializate.
O aplicatie software care are ca rol usurarea bug tracking-ului (este o metoda eficienta centralizata si usor folosibila.) Exista solutii gratuite, dar si solutii enterprise cu preturi foarte ridicate. Un sistem de bug tracking este un subtip de sistem de issue traking.
O aplicatie software care are ca rol centralizarea si adresarea tuturor cererilor legate de unul sau mai multe produse, de la probleme la schimbari de design si aplicari de patch-uri. Cele mai multe sunt in acelasi timp si bug trackere. In general sunt mai complexe decat bug trackerele.
O mica bucata de software creata spre a rezolva problemele si a imbunatati performantele unui program. Aceasta include, dar nu estre limitata la, repararea de bug-uri, cresterea vitezei, imbunatatirea graficii. Unele patchuri creeaza si probleme noi.
Procesul de a stabili o strategie si plan de ce patch-uri la ce sisteme sa fie aplicate la un timp dat.
Bugzilla este unul din cele mai populare sisteme de urmarire a bugurilor avand o groaza de [http://www.bugzilla.org/features/ functionalitati].
Trac nu este atât de sofisticat ca Bugzilla în ce privește urmărirea bugurilor (adică bug tracking), dar oferă mult mai multe alte facilități precum un navigator de Subversion și un wiki, deci o platformă completă de colaborare între utilizatori și dezvoltatori. Deasemenea Trac poate fi extins ușor prin intermediul modulelor, unul dintre cele mai populare fiind cel pentru code review.
* fiecare bug are o adresă de mail distinctă. Comentariile și controlul bug-urilor se face cu emailuri tipizate.
Launchpad este o aplicație web și un site pentru publicarea proiectelor software (în special cele open source). Printre multe alte facilități interesante dispune și de bug-tracking.
Launchpad poate centraliza rapoartele bugurile din mai multe surse independente și oferă posibilitatea dezvoltatorilor de a discuta despre acel bug într-un singur loc. Launchpad se integrază bine cu trackere externe: Bugzilla, Trac, Sourceforge, Roundup, Mantis, RT și Debian BTS. Launchpad încearcă să elimine patchurile scrise în comentarii prin oferirea posibilității de publicare a unei ramure de cod (branches).
Bugurile pot fi urmărite prin email și atom feeds, fiecare bug având asociată o adresa de email (ex: 249177@bugs.launchpad.net).
Un fișier patch e un fișier text care descrie diferențele dintr două versiuni ale unui fișier sau dintre două fișiere distincte. Există două formate standard pentru astfel de fișiere:
Este tipul standard. Structura: o serie de blocuri de tipul următor:
change-command_from-file-line_from-file-line..._---_to-file-line_to-file-line}
Fiecare bloc descrie doar o serie de modificări fără a da informații contextuale (singurele date despre context sunt codate în change-command care descrie modul în care s-au modificat fișierele.
Ex. de change-command: 264,265c264,275: se înlocuiesc din fișierul original liniile 264 și 265 cu blocul de linii 264 .. 275.
Exemplu de fișier patch în format normal:
{{{ 264,265c264,275 < display(“original message: [%s]\n”, msg, blocks); < — > display(“original message: [%s]\n”, msg, blocks); > if (blocks) > { > char c; > char * fmt = “original message: [%s]\n”; > int len = blocks; > c = msg[len-1]; > if (c == 'X') > msg[len-1] = '\0'; > printf(fmt, msg); > msg[len-1] = c; > } }}} ==== Context copiat ==== Deoarece doar modificările fără context nu spun prea multe la o inspectare directă a fișierului patch, s-a definit un nou tip care păstrează și informații de context. Numărul de linii de context din fișierele originale care sunt păstrat în fișierul patch poate fi specificat la crearea fișierului. Structura unui fișier de tip patch: original_file_name_timestamp_---_modified_file_name_timestamp_start_line_original_file_end_line_original_file_context_line_before_1_context_line_before_2_..._context_line_before_n_original_line_1_original_line_2_..._original_line_m_context_line_after_1_context_line_after_2_..._context_line_after_n_---_start_line_modified_file_end_line_modified_file_----_context_line_before_1_context_line_before_2_..._context_line_before_n_modified_line_1_modified_line_2_..._modified_line_p_context_line_after_1_context_line_after_2_..._context_line_after_n} Un exemplu: {{{ * v1.c 2008-11-18 02:34:38.000000000 +0200 — v2.c 2008-11-18 02:38:14.000000000 +0200 * * 260,269 if (build_key(argv[1])) return 2; ! display(“original message: [%s]\n”, msg, blocks); ! apply(msg, blocks, normalize); encrypt1)
apply(msg, blocks, denormalize);— 260,279 —-
if (build_key(argv[1]))
return 2;
! display(“original message: [%s]\n”, msg, blocks);
! if (blocks)
! {
! char c;
! char * fmt = “original message: [%s]\n”;
! int len = blocks;
! c = msg[len-1];
! if (c == 'X')
! msg[len-1] = '\0';
! printf(fmt, msg);
! msg[len-1] = c;
! }
apply(msg, blocks, normalize);
encrypt((unsigned short*) msg, blocks/2);apply(msg, blocks, denormalize);}}} Dacă zona nu se află la începutul sau sfârșitul fișierului, e posibil ca numerele de linii de context dinaintea și după blocul modificat să difere. ==== Context unificat ==== Cel mai întâlnit și mai ușor de vizualizat format de fișier este cel cu context unificat. În modul anterior, contextul din jurul blocurilor este copiat: apare o dată pentru a pune în context blocul original și o dată pentru cel modificat. Acest mod de reprezentare are două dezavantaje: * produce fișiere patch mai mari decât este necesar, * nu scoate bine în evidență diferențele între fișiere la o inspectare vizuală. Deoarece atât a blocurile originale, cât și a cele modificate sunt marcate cu același simbol ”!”, cititorul unui fișier patch în format cu context copiat trebuie să se uite după marcajele care descriu liniile și fișierul la care se referă un anumit bloc (cele pentru fișiere originale sunt marcate cu laboratoare}, iar cele pentru fișierele modificate cu laboratoare}). Structura unui fișier patch cu context unificat: etc._etc._modified_file_name_comentarii_idem_-start_line_original_file_nr_lines_original_file_start_line_modified_file_nr_lines_modified_file_context_line_before_1_context_line_before_2_..._context_line_before_n_-_original_line_1_-_original_line_2_..._-_original_line_m_modified_line_1_modified_line_2_..._modified_line_p_context_line_after_1_context_line_after_2_..._context_line_after_n} Exemplu de fișier patch cu context unificat: {{{ — v1.c 2008-11-18 02:34:38.000000000 +0200 +++ v2.c 2008-11-18 02:38:14.000000000 +0200 @@ -261,8 +261,18 @@
if (build_key(argv[1]))
return 2;
- display(“original message: [%s]\n”, msg, blocks);
-
+ display(“original message: [%s]\n”, msg, blocks);
+ if (blocks)
+ {
+ char c;
+ char * fmt = “original message: [%s]\n”;
+ int len = blocks;
+ c = msg[len-1];
+ if (c == 'X')
+ msg[len-1] = '\0';
+ printf(fmt, msg);
+ msg[len-1] = c;
+ }
apply(msg, blocks, normalize);
encrypt((unsigned short*) msg, blocks/2);
}}}
=== Creare patch ===
==== diff ====
diff poate crea fișiere patch în oricare din cele trei formate standard:
* normal
diff_origial_filename_modified_filename}
* context copiat
pentru a crea un fișier patch cu un număr implicit de linii de context copiat:
diff_-c_origial_filename_modified_filename}
* pentru a crea un fișier patch cu x linii de context copiat:
diff_-cx_origial_filename_modified_filename}
* context unificat
pentru a crea un fișier patch cu un număr implicit de linii de context unificat:
diff_-u_origial_filename_modified_filename}
* pentru a crea un fișier patch cu x linii de context unificat:
diff_-ux_origial_filename_modified_filename}
==== svn diff ====
svn poate genera fișiere de patch care descriu diferențele între două versiuni ale unor fișiere.
Implicit svn diff crează un fișier diff în format unificat (cel mai răspândit format în lumea open-source) și îl scrie la stdout. Pentru a-l scrie într-un fișier pe disc, trebuie redirectată ieșirea către un fișier:
svn_diff_optional_parameters_file.patch}
Câteva moduri de rulare:
* svn diff va scrie la stdout un fișier patch care descrie diferențele între versiunea curentă a directorului curent și cea din HEAD-ul svn-ului.
* svn diff path_name va scrie la stdout un fișier patch care descrie diferențele între versiunea curentă a căii descrise de parametru path_name și cea din HEAD-ul svn-ului (path_name poate fi un fișier sau un director).
* svn diff –diff-cmd diff –extensions -C8 fname:
–diff-cmd specifică ce program trebuie rulat de svn diff pentru a calcula diferențele între cele două versiuni ale lui fname. În acest exemplu, se specifică diff (programul descris în secțiunea anterioară).
după –extensions între ghilimele sau apostrofuri se specifică argumentele suplimentare care trebuie trimise programului specificat prin argumentul –diff-cmd. În acest exemplu specificăm -C8 - 8 linii de context copiat.
* svn diff –old=OLD-URL[@OLDREV] –new=NEW-URL[@NEWREV] - poate calcula diferențele între două repository-uri de svn și între două versiuni specificate prin număr.
* svn diff –old=@OLDREV –new=@NEWREV - pentru proiectul curent (nu se specifică URL-uri diferite), între versiunile OLDREV și NEWREV.
=== Utilizare patch ===
Un fișier patch nu este folosit doar pentru a vizualiza diferențele între două versiuni ale unor fișiere, ci și pentru a transmite un anumit set de modificări de la un utilizator la altul pentru a fi aplicate.
Utilitarul standard cu care se aplică patch-uri se numește patch.
Modul cel mai întâlnit de utilizare este:
patch_-pnum_filename.patch}
patch își ia fișierul din stdin, de aceea trebuie redirectat fișierul de intrare.
În fișierul filename.patch, diff sau svn diff va scrie și numele fișierelor pe care le-a comparat și din conținutul cărora a extras diferențele. E posibil ca diff sau svn diff să fie rulate într-un alt director față de cel în care se va rula patch. Cu opțiunea -pNUM se specifică numărul de nivele din calea specificată în fișierul filename.patch care vor fi ignorate când se va încerca să se determine.
== Exerciții (Răzvan) ==
Trac deține o secțiune specializată pentru bug-uri și tichete care poate fi folosită pentru notificarea dezvoltatori referitoare la diverse probleme în aplicația proiectată. Există scripturi specializate care permit transferul bug-urilor și tichetelor specifice diverselor aplicații de bug tracking în sistemul folosit de Trac.
În general, un tichet trac conține informații despre autorul tichetul, componenta din cadrul proiectului la care se referă tichetul, o prioritate, o persoană responsabilă, o stare (închis, deschis, asociat unei persoane) și o descriere.
Controlul tipului tichetelor, componentelor și priorităților se realizează cu ajutorul utilitarului trac-admin.
'Atenție': Project Manager-ul echipei a primit pe e-mail parola pentru contul asociat de pe anaconda.cs.pub.ro unde se poate configura inclusiv sistemul de ticheting. Daca nu l-a primit discutați cu asistentul.
# (10 minute) (2 echipe) Stabiliți care sunt componentele (component), tipurile de tichete (ticket_type), severitățile (severity) și prioritățile (priority) sistemului de ticheting pentru proiectul vostru. (link util)
# Folosind parola de mai sus, conectați-vă prin SSH (puteți folosi putty) la contul asociat de pe anaconda.cs.pub.ro (sau mps.cs.pub.ro - e acelasi lucru)
# Care sunt componentele implicite, tichetele implicite, severitățile și prioritățile implicite.
# Alegeți un membru al echipei pentru configurarea:
#* componentelor
#* tichetelor
#* severităților
#* priorităților
#: în funcție de deciziile de mai sus
# Verificați în Trac configurările de mai sus.
# Trimiteți câteva tichete de test.
= Coding review session =