h3. Folosim branch-uri

In infoarena2 Nu am 'folosit eficient branch-uri':http://producingoss.com/en/vc.html#branches. Absolut toate modificarile le-am facut direct in trunk iar asta nu este o idee buna. Exista mereu schimbari mari care au nevoie de mai multe commit-uri pentru a fi complet functionale. Astfel de schimbari trebuie facute intai intr-un branch special si abia apoi copiate(svn merge) in trunk. Asta face trunk-ul sa fie mai stabil si sa nu mai contina "cod mort".

In infoarena2 nu am 'folosit eficient branch-uri':http://producingoss.com/en/vc.html#branches. Absolut toate modificarile le-am facut direct in trunk iar asta nu este o idee buna. Exista mereu schimbari mari care au nevoie de mai multe commit-uri pentru a fi complet functionale. Astfel de schimbari trebuie facute intai intr-un branch special si abia apoi copiate (cu svn merge) in trunk. Asta face trunk-ul sa fie mai stabil si sa nu mai contina "cod mort".

Un branch poate sa faca oricine are access la subversion fara sa intrebe pe nimeni. Intr-un branch este OK sa experimentezi cu absolut orice fara sa-ti faci griji ca strici site-ul pentru altii. Cand consideri ca este gata de copiat in trunk poti sa chemi pe cineva sa se uite peste modificari. Modificarile pot fi acceptate in trunk, sau pot aparea observatii si branchul poate fi respins. Daca un branch este respins poti sa ii rezolvi problemele si sa il propui din nou pentru includere in trunk.

Un branch poti sa faci oricand daca ai access subversion, fara sa intrebi pe nimeni. Intr-un branch este OK sa experimentezi cu absolut orice fara sa-ti faci griji ca strici site-ul pentru altii. Cand consideri ca este gata de copiat in trunk poti sa chemi pe cineva sa se uite peste modificari. Modificarile pot fi acceptate in trunk, sau pot aparea observatii si branch-ul poate fi respins. Daca un branch este respins poti sa ii rezolvi problemele si sa il propui din nou pentru includere in trunk.

Ne dorim sa punem doar modificari aproximativ atomica in trunk, care sa nu introduca bug-uri. Este in continuare OK sa aplici bugfix-uri si tweak-uri minore de CSS direct in trunk. Branch-urile sunt necesare pentru feature-uri de genul blog, latex, array_validate, dataset-uri, caching, tag-uri, etc.

Ne dorim sa punem doar modificari aproximativ atomice in trunk, care sa nu introduca bug-uri. Este in continuare OK sa punem bugfix-uri si tweak-uri minore de CSS direct in trunk. Branch-urile sunt necesare pentru feature-uri de genul blog, latex, array_validate, dataset-uri, caching, tag-uri, etc.

h3. Responsabilitati

Codul infoarena este open-source, iar oamenii lucreaza doar in timpul lor liber. Dar daca vrei sa ajuti infoarena atunci trebuie sa te tii de treaba si sa rezolvi tichetele pana la o anumita data. Bineinteles ca nu avem cum sa fortam pe nimeni sa lucreze la infoarena, dar se presupune ca un individ care vrea sa ne ajute cu adevarat nu vrea sa frece menta.

Codul infoarena este open-source, iar oamenii lucreaza doar in timpul lor liber. Dar daca vrei sa ajuti infoarena atunci trebuie sa te tii de treaba si sa rezolvi tichetele pana la o anumita data. Bineinteles ca nu avem cum sa fortam pe nimeni sa lucreze la infoarena, dar se presupune cine vrea sa ne ajute nu vrea sa frece menta.

Un tichet "acceptat" trebuie sa aiba un owner care este responsabil sa rezolve acel tichet pana la o anumita data. Un dead-line nu inseamna "ar fi frumos sa avem #123 rezolvat pana luna viitoare". Un deadline inseamna ceva de genul "eu rezolv #124 pana maine si #125 poimaine". Astfel de dead-line-uri ar fi un impuls interior pentru fiecare din noi.

Un tichet "acceptat" trebuie sa aiba un owner care este responsabil sa rezolve acel tichet pana la o anumita data. Un deadline nu inseamna "ar fi frumos sa avem #123 rezolvat pana luna viitoare". Un deadline inseamna ceva de genul "eu rezolv #124 pana maine si #125 poimaine". Astfel de deadline-uri functioneaza ca o motivatie suplimentara.

Asta este foarte similar cu sistem-ul mare de roluri din 'echipa infoarena':echipa-infoarena, care momentan pare sa functioneze destul de bine. Pe langa dead-line-uri per-tichet vom avem si un om care se ocupa de development in mod global, care acum este ==user(user="fluffy")==. *TODO:* de detaliat ce face dev lead?

Asta este foarte similar cu sistem-ul mare de roluri din 'echipa infoarena':echipa-infoarena, care pare sa functioneze destul de bine. Pe langa dead-line-uri per-tichet vom avem si un om care se ocupa de development in mod global, care acum este ==user(user="fluffy")==. *TODO:* de detaliat ce face dev lead?

h3. Milestone-uri semnificative

Propun sa avem 2 tipuri de milestone-uri:

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

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

Asta presupunem ca folosim layout-ul oarecum standard din subversion; care este discutabil 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.

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.

Pentru infoarena3 primul release public va fi 3.0. Putem denumi versiunile intermediare ca infoarean3-0.1

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.

h3. Cum alegem tehnologie

De multe ori s-a discutat ca infoarena sa folosesca o anume librarie avansata sau framework. Folosirea unei librarii externe este o decizie majora care trebuie analizata cu grija. Orice dependinta externa trebuie sa satisfaca urmatoarele conditii:
* Sa fie simplu de inclus. Sa existe macar pachete debian si fedora; sau sa poata fi copiata direct in svn. *Nu* se accepta installere din afara distributiei de linux.

De multe ori s-a discutat ca infoarena sa folosesca o anume librarie avansata sau framework. Folosirea unei librarii externe este o decizie majora care trebuie analizata cu grija. O dependinta externa trebuie sa satisfaca urmatoarele conditii:
* Sa fie simplu de inclus. Sa existe macar pachete debian si fedora; sau sa poata fi copiata direct in svn. *Nu* se accepta installere din afara distributiilor de linux.

* Sa ne ajute cu ceva major care ar fi foarte greu sa facem de la 0.

* Sa fie cunoscuta si dezvoltata activ. Altfel probabil ca respectiva librarie nu e buna de nimic.

* Sa fie cunoscuta si dezvoltata activ. Altfel probabil ca respectiva librarie nu e foarte buna.

* Sa nu impuna restrictii asupra arhitecturii site-ului. Asta elimina cam toate framework-urile.
* Scalabil, testabil, etc.

Mai mult, cine propune o dependinta trebuie sa dovedeasca ca indeplineste toate conditiile de mai sus. Putem sa facem asta prin tichete speciale de "investigare". Individul responsabil de un asemenea tichet trebuie sa invete tehnologia respectiva si sa ne ajute sa decidem daca merita folosita. Rezultatul unui asemenea tichet este un demo, care poate fi un branch sau o chestie from-scratch. Acel demo trebuie sa demonstreze viabilitateai respective tehnologii, dar nu trebuie sa fie neparat imediat utilizabil in trunk.

Mai mult, cine propune o dependinta trebuie sa dovedeasca ca indeplineste toate conditiile de mai sus. Putem sa facem asta prin tichete speciale de "investigare". Individul responsabil de un asemenea tichet trebuie sa invete tehnologia respectiva si sa ne ajute sa decidem daca merita folosita. Rezultatul unui asemenea tichet este un demo, care poate fi un branch sau o chestie from-scratch. Acel demo trebuie sa demonstreze viabilitatea respectivei tehnologii, dar nu trebuie sa fie neparat imediat utilizabil in trunk.

Idei de demo-uri:

* BL prin HTTP: Se poate face un BL accesibil direct prin http, fara a scrie controllere pentru fiecare functie? Poate evaluatorul sa acceseze functii de BL de pe live, fara access TCP la baza de date?
* Wiki in subversion: Ar avea sens sa tinem textblock-uri si atasamente in subversion? Demo de manipulare cu teste de viteza.

Probabil ca aceste demo-uri vor fi de fapt formulate sub forma de IAP-uri. Momentan inca nu am decis exact ce tehnologie folosim in infoarena3. Vom face IAP-uri doar and structura de baza a site-ului este gata.

Probabil ca aceste demo-uri vor fi de fapt formulate sub forma de IAP-uri. Momentan inca nu am decis exact ce tehnologie folosim in infoarena3. Vom incepe sa facem IAP-uri doar cand structura de baza a site-ului este functionala

h2. Arhitectura infoarena3

Ca sa evitem probleme tehnice din infoarena3 ne trebuie un o arhitectura clara si solida pe care putem construi. Trebuie sa evitam a ne "infunda" din nou. Acum nu avem inca nici un fel de cod scris si totul poate fi schimbat foarte usor.

Ca sa evitem probleme tehnice din infoarena2 ne trebuie un o arhitectura clara si solida pe care sa putem construi. Trebuie sa evitam a ne "infunda" din nou. Acum nu avem inca nici un fel de cod scris si totul poate fi schimbat foarte usor.

h3. Python ca limbaj de programare
Propun sa scriem infoarena3 in python. Este un limbaj foarte OK pentru programarea web, cu multe librarii disponibile. Este recunoscut pentru a fi foarte foarte curat si a incuraja un stil frumos de cod. Avem oameni disponibili sa programeze in python.

Este foarte dificil sa faci o alegere desteapta intre limbaje de programare. Am dat cu banul si am ales python. Nu exista motive foarte bune pentru python dar nici nu vad motive foarte bune pentru a alege altceva. Este foarte dificil sa compari inteligent limbaje de programare, atat de dificil incat majoritatea discutiilor pe acest subiect sunt neproductive.

Este foarte dificil sa faci o alegere desteapta intre limbaje de programare, atat de dificil incat majoritatea discutiilor pe acest subiect sunt neproductive. Noi am dat cu banul si am ales python. Nu exista motive foarte bune pentru python dar nici motive foarte bune pentru a alege altceva.

h3. Baza de date

Propun sa folosim 'SQLAlchemy':http://www.sqlalchemy.org/ pentru a manipula baza de date, sau macar partea de expresii SQL. Ne scapa de a formata de mana conditii de where pentru chestiile simple, si suporta mai multe baze de date. Trebuie investigat cu multa grija si testat performanta.

Propun sa folosim 'SQLAlchemy':http://www.sqlalchemy.org/ pentru a manipula baza de date, sau macar partea de expresii SQL. Ne scapa de a formata de mana conditii de where pentru chestiile simple, si suporta mai multe baze de date. Trebuie investigat cu multa grija si testata performanta.

Vrem sa suportam minim MySQL pentru productie si SqlLite pentru development. Ar fi foarte util sa putem rula site-ul in modul de development fara o procedura complexa de setup.

 * 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 vrei noi.

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

Avem ca si in infoarena2 un singur entry-point in tot site-ul. Acolo analizam requestul (ne uitam la url si query string) dupa care pasam munca la un controller. Un controller este o functie python care se ocupa de un intreg request. Controllerele nu se cheama niciodata unul pe altul.

Avem ca si in infoarena2 un singur entry-point in tot site-ul. Acolo analizam requestul (ne uitam la url si query string) dupa care pasam munca la un controller. Un controller este o functie python care se ocupa de un request de la cap la coada. Controllerele nu se cheama niciodata unul pe altul.
 
Multe controllere vor folosi probabil suportul de versionare. Trebuie sa putem refolosi usor codul de editare si istorie si sa il integram in alte componente. Ne dorim un editor integrat de task-uri si de profil de utilizator.

Multe controllere vor folosi probabil suportul de versionare. Trebuie sa putem refolosi usor codul de editare si istorie.

Doar componentele mari ale site-ului vor avea propriile controllere. Pentru un tabel rapid sau un raport solutia preferata este sa facem un macro.

h3. Securitate

h2. Plan de bataie

Pentru infoarena3 primul release public va fi 3.0. Putem denumi versiunile intermediare ca infoarean3-0.1
 

h3. Barebones read-only site
Facem intai site-ul in modul read-only: all content, some macros, no forms, no security. Bagam teste de performanta pe el. What does done mean?