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.

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.

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.