==Include(page="template/iap")==

|_. Data      | 2007-11-08                                      |
|_. Autor(i)  | ==User(type="tiny" user="fluffy")==             |
|_. Stare     | S-a dezbatut, acum e din nou *_IN-CONSTRUCTIE_* |

|_. Data      | 2007-11-08                              |
|_. Autor(i)  | ==User(type="tiny" user="fluffy")==     |
|_. Stare     | *_IN-DEZBATERE_* Propus pentru aprobare |

h2. Abstract
Pe scurt, codul din spatele site-ului infoarena2 este intr-o stare foarte proasta si trebuie rescris. Pagina aceasta incearca sa explice in detalii problemele din cod, si incearca sa demonstreze ca rescrierea soft-ului este cel mai bun mod de a avansa site-ul.

In sedinta din '24 octombrie':planificare/sedinta-20071024 eu ( ==user(user="fluffy")== ) am fost insarcinat sa scriu aceasta pagina. In urma sedintei din '7 noiembrie':planificare/sedinta-20071107 s-a decis sa reformulam aceasta pagina sub 'format IAP':propuneri. Propunerea a fost discutata si au venit cateva observatii din partea lui ==User(user="wickedman")== la care trebuie sa raspund.

In sedinta din '24 octombrie':planificare/sedinta-20071024 eu ( ==user(user="fluffy")== ) am fost insarcinat sa scriu aceasta pagina. In urma sedintei din '7 noiembrie':planificare/sedinta-20071107 s-a decis sa reformulam aceasta pagina sub 'format IAP':propuneri. Propunerea a fost discutata si au venit cateva observatii din partea lui ==User(user="wickedman")==

Am pus si un 'topic pe forum':http://infoarena.ro/forum/index.php?topic=2243.0, dar pana acum feedback-ul a fost sub asteptari.

Am pus si un 'topic pe forum':forum/index.php?topic=2243.0, dar pana acum feedback-ul a fost sub asteptari.
 
*Update:* Propun sa votam pe idea de a rescrie site-ul in python si sa aprobam acest IAP. Propunerea a devenit mult prea lunga si nu cred ca e practic sa intram in prea multe detalii de arhitectura. Daca o aprobam putem sa copiem bucati in planificare/development si sa facem IAP-uri pentru alte idei majore. Nimic din ce am scris nu ramane batut in cuie.

h2. Motivatie

Atasamentele sunt un sistem complet distict, sunt fisiere pe disc sub-ordonate unui textblock din baza de date. Manipularea atasamentelor este FOARTE neplacuta, si pot aparea desincronizari in diverese locuri. Securitatea atasamentelor depinde de cea a textblock-urilor (si indirect a problemelor) in moduri complicate si imprevizibile. Ar fi mai bine sa avem un singur suport de "BLOB-uri" versionate.

Nu avem suport de redenumire si stergere care sa pastreze istoria, si nici o idee resonabil de design care ar permite asa ceva in baza de date. Trebuie investigat daca se poate folosi subversion in loc de MySQL pentru fisiere versionate.

Nu avem suport de redenumire si stergere care sa pastreze istoria, si nici o idee simpla de design care ar permite asa ceva in baza de date. Trebuie investigat daca se poate folosi subversion in loc de MySQL pentru fisiere versionate.

h3. Securitatea si magia din wiki

* Time-based, care incrementeaza versiunea cu _0.0.1_. Acolo punem tichete pentru care stim ca avem oameni sa le faca intr-un interval de timp relativ scurt. Le vom sincroniza aproximativ cu sedintele asociatiei sau cu rundele de concurs.
* Feature-based, care incrementeaza versiunea cu _0.1_. Acolo punem tichete majore, care merita o incrementare a versiunii. Cand gasim oameni mutam tichetele in _+0.0.1_. Cand ramanem fara tichete intr-un astfel de milestone ii facem release.

Pentru noi nu are sens sa mentinem branch-uri stabile si instabile, pentru ca avem o singura instanta care este in productie la orice moment. Site-ul live o sa-l rulam direct din svn de pe branch-ul ultimului release; spre exemplu din _branches/infoarena3-3.2.7_. Daca apare un bug urgent il putem rezolva direct pe live cu commit in acel branch. *NU* vom rula din _tags/infoarena3-3.2.7_, care trebuie sa ramana read-only.

h3. Quality Asurrance
 
Noi am rulat in mare parte site-ul direct din trunk si am avut de multe ori bug-uri mari pe site-ul live. Motivul principal a fost ca sa nu stagnam development-ul prin birocratie excesiva. Este totusi destul de riscant si neprofesional sa rulam direct din trunk.
 
Putem sa avem un site special de development pe trunk, dar care este marcat explicit pentru testing. Site-ul poate sa sa se updateze singur la ultimul trunk si sa ruleze teste automate folosind un dataset redus (pentru a minimiza efectele unei gauri de securitate). Scripturile necesare nu sunt deloc greu de scris. Ramanem totusi la idea de a rula din svn, nu are sens sa facem o procedura separata de upgrade/deployment.

Asta presupunem ca folosim layout-ul oarecum standard din subversion. Este discutabil daca acesta este bun pentru cazul nostru. O idee alternativa ar fi sa tinem branches doar pentru modificari mari si urate, trunk pentru ultima versiune si niste directoare release/infoarena3-A.B.C de unde rulam trunk-ul.

Noi avem o singura instanta care este in productie la orice moment. Asta inseamna ca nu are sens sa mentinem branch-uri separate stabile sau instabile. Noi nu facem "release-uri" publice in sensul standard si e posibil ca layout-ul standard subversion sa nu fie foarte util. Propun sa ne facem un layout custom:

Nu avem resurse sa facem QA mai avansat de atat. Daca facem review cu grija la ce intra in trunk si mentinem o suita de teste automate putem sa ne descurcam destul de bine.

* branches/more-ajax: Sandbox-uri pentru schimbari majore
* trunk/: Bleeding edge. De aici rulam site-ul de test. Bugs welcome!
* release/infoarena-3.1.7: De aici rulam site-ul live. Facem commit cu multa grija.
* external/smf-2.1.9: Pentru pachete externe care au nevoie de merge; echivalent vendor.
 
Cand stabilizam copiem ultimul trunk in release/ si testam un pic (o saptamana) pana e stabil. Abia dupa asta migram live pe ultimul release, si facem doar fix-uri pentru bug-uri majore. Ideal ar fi sa nu scriem in release dupa ce migram site-ul live.

h3. Cum alegem tehnologie

La baza site-ului vom avea o componenta de versionare de fisiere. Aceasta componenta nu stie absolut nimic de useri, probleme, securitate sau tag-uri. Orice semnificatie a fisierelor este data doar de mai sus. De la aceasta componenta ne dorim urmatoarele:

 * Fetch rapid, cu cache transparent pe disc. Nu servim fisiere direct baza de date.
 * Istorie completa a modificarilor
 * Delete reversibil, care sa apara in istorie
 * Mutare/copiere pastrata in istorie.
 * Posibilitatea de a distruge complet o revizie

* Fetch rapid, cu cache transparent pe disc. Nu servim fisiere direct baza de date.
* Istorie completa a modificarilor
* Delete reversibil, care sa apara in istorie
* Mutare/copiere pastrata in istorie.
* Posibilitatea de a distruge complet o revizie

Nu avem nevoie de:

 * Directoare. Ne trebuie doar fisiere.
 * Meta-date. Versionam doar blob-uri; eventual cu cateva coloane strongly-typed (mime type?)
 * Notiuni de securitate.
 * Schimbari atomice pe mai multe fisiere.

* Directoare. Ne trebuie doar fisiere.
* Meta-date. Versionam doar blob-uri; eventual cu cateva coloane strongly-typed (mime type?)
* Notiuni de securitate.
* Schimbari atomice pe mai multe fisiere.

Este dificil sa satisfacem toate cerintele folosind tabele de SQL, dar se poate face. Multe cerinte pot fi relaxate pana aproape de nivelul infoarena2. O varianta interesanta ar fi sa folosim subversion pentru versionare, dar din pacate nu se mapeaza perfect pe ce vrem noi. De investigat si discutat.

Vrem sa suportam mai multe tipuri de probleme sau runde, fara sa oprim evaluatorul. Asta este foarte realizabil daca nu ne incurcam cu sisteme multe prea generice. Nu o sa mai avem descriptori de securitate si ia_parameter_values, toate datele noastre vor fi accesibile in SQL curat. Asta inseamna ca putem sa facem query-uri complexe pentru determinat ce job-uri trebuie evaluate.

h3. Integrare SMF, textile.
 
Integrarea SMF o se faca in cea mai mare parte cu query-uri direct in tabele de SMF. Tabele SMF sunt relativ inteligibile. Pentru cazurile in care nu ne ajunge putem investiga un mod de a chema cod php din python in acelasi request. Aproape sigur se poate, dar s-ar putea sa ne restranga la mod_python. Daca se poate atunci putem sa evitam sa duplicam codul de header/footer spre exemplu, dar nu este critic.
 
Exista un parser textile pentru python dar nu esti dezvoltat activ. Asta nu e o problema; il introducem in repository si il modificam pentru ce avem nevoie. Putem face teste automate ca sa verifice ca output-ul este foarte similar. In infoarena2 am incercat sa modificam cat mai putin parser-ul de textile pentru a putea lua update-uri upstream. Asta nu s-a intamplat si cred ca e mai bine sa modificam fara mila.
 

h2. Plan de bataie

Ajunge cat am batut campii, trebuie sa ne apucat si de munca. Primul release public se va numi infoarena 3.0 si are ca criteriu implementarea intregii functionalitati infoarena2. Pana atunci vom face dezvoltarea intr-un branch separat din acelasi repository. Infoarena2 intra in maintenance-only mode; unde nu reparam decat chestii critice.

Ajunge cat am batut campii, trebuie sa ne apucat si de munca. Primul release public se va numi infoarena 3.0 si are ca criteriu implementarea intregii functionalitati infoarena2. Pana atunci vom face dezvoltarea intr-un branch separat din acelasi repository.
 
h3. Ce se intampla cu infoarena2 si trac.
 
Infoarena2 intra in maintenance-only mode; unde nu reparam decat chestii foarte necesare. Facem release 2.1.5 si trecem la layout-ul de repository propus pentru infoarena3. Bagam toate tichetele intr-un milestone de "Infoarena 2.99 blue-sky" si mutam in 2.1.6 doar tichetele pentru care putem asigna un om.
 
Pentru infoarena3 facem tichete de investigare si 2 milestone-uri: "3.0" si "3.99 blue-sky" cu aceasi semnificatie. Momentam lucram in branches/infoarena3, facem switch la trunk cand dam release de 3.0. O sa avem si alte branch-uri de research pentru 3.0.

h3. Barebones read-only site