Diferente pentru propuneri/3-infoarena3 intre reviziile #55 si #56

Nu exista diferente intre titluri.

Diferente intre continut:

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
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 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.
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.
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.
 
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.
h3. Cum alegem tehnologie
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 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.
h3. Barebones read-only site

Nu exista diferente intre securitate.

Topicul de forum nu a fost schimbat.