Diferente pentru propuneri/3-infoarena3 intre reviziile #13 si #12

Nu exista diferente intre titluri.

Diferente intre continut:

h2. Un plan de atac
Unele probleme din infoarena2 nu origineaza neaparat in cod, dar in modul nostru de lucru. Aici am pus niste idei pentru a imbunatati procesul de dezvoltari. Teoretic ar putea fi aplicate si in infoarena2.
 
h3. Branching
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.
Nu am folosit eficient branch-uri. 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, iar Astfel de schimbari trebuie facute intai intr-un branch special si abia apoi copiate in trunk.
In asa fel trunk-ul devine mult mai stabil si nu este nimic rau in a abandona o idee. In trunk-ul infoarena2 avem cod mort pentru idei abandonate, care acum este dificil de extras. Branch-uri ar fi trebuit sa facem pentru cache-ing, editoare de probleme, validate_array, tag-uri, blog, dataset-uri etc.
*LINK TO PRODUCING OSS*
 
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 rezolvi tichetele pana la o anumita data. Ar ajuta mult ca un tichet "acceptat" sa aiba un owner care este responsabil sa rezolve acel tichet pana la o anumita data.
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 rezolvi tichetele pana la o anumita data. Ar ajuta mult ca un tichet "acceptat" sa aiba un owner care este trebuie sa rezolve acel tichet 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. Astfel de dead-line-uri ar fi un impuls interior pentru fiecare din noi. Atentie: nu ma refer la dead-line-uri de genul "ar fi frumos sa avem #123 rezolvat pana luna viitoare", ma refer la lucruri de genul "eu rezolv #124 pana maine si #125 poimaine".
Un asemenea sistem ar mentine mai multa ordine in tichetele din trac.
h3. Ordine in tichete
h3. Demo-uri
S-a propus de multe ori sa folosim framework-uri si librarii avansate. Adaugarea unei dependinte necesita un efort mare de invatare care se poate dovedi eventual inutil. Inainte de a inghiti o noua dependinta trebuie sa ne asiguram ca se merita. Are sens sa face 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 de infoarena2 sau o chestie from-scratch. Acel demo trebuie sa demonstreze viabilitatea respective tehnologii.
 
Exemplu de demo-uri care ar merita facute:
 
* *SqlAlchemy*: O schema sql alchemy pentru tabelele de scoruri, inclusiv teste de performanta.
* *Selenium*: Cineva sa faca niste teste folosind Selenium, probabil peste infoarena2. Cum anume pot fi stocate in svn si rulate de oricine?
* *Form-uri*: Nu avem o solutie definitiva pentru facut si validat form-uri. Cineva sa ia o asemenea librarie si sa faca CRUD de task-uri, si sa demonstreze ca e sensibil mai usor decat manual.
* *Tabele*: Demo de tabel de scoruri prin AJAX. Cristi: this means you.
* *BL prin HTTP*: Se poate face un BL accesibil direct prin http, fara a scrie controllere manuale? Poate evaluatorul sa acceseze functii de BL de pe live, fara access local la baza de date?
* *Wiki in subversion*: Ar avea sens sa tinem textblock-uri si atasamente in subversion? Demo cu teste de viteza.
 
Putem sa facem intai un numar de demo-uri pentru a ne decide ce anume folosim in infoarena3.
 
h3. Arest la domiciliu
* Framework-uri
* SqlAlchemy
* Selenium
* Form-uri
* Tabele
* BL prin HTTP
* Wiki si atasamente in subversion.
Putem sa facem un mare coding camp la Leonard si Mircea acasa, care sa dureze o saptamana intreaga sau chiar 2. Putem invita si utilizatori infoarena care vor sa ne ajute. Sigur ne putem face cu totii timp sa lansam infoarena3 (concediu). O lansare de success inseamna un site utilizabil la care va continua dezvoltarea si in timpul liber (*because it's fun!*).
h3. Arest la domiciliu

Nu exista diferente intre securitate.

Topicul de forum nu a fost schimbat.