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.

h3. Quality Asurrance

Noi am rulat in mare parte site-ul direct din trunk si am avut de multe ori bug-uri destul de naspa pe site-ul live. Motivul principal a fost ca sa nu stagnam developmentul prin birocratie excesiva. Este totusi destul de riscant si neprofesional sa rulam direct din trunk.

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 care ruleaza automat 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.

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.

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:

* 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 saptaman) pana e stabil. Abia dupa asta migram live pe ultimul release, si apoi facem doar fix-uri pentru gauri majore. Ideal nu ar trebui sa scriem in release dupa ce migram site-ul live.

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.

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 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.

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.

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