Dizzy <[EMAIL PROTECTED]> scria la data de 15 Decembrie 2005:
> On Thursday 15 December 2005 08:30, Liviu Daia wrote:
> > Ce incercam eu sa spun era ca poti avea un proiect care
> > se dezvolta rapid si substantial fara sa-ti obligi user-ii sa
> > faca upgrade-uri din doua in doua saptamani doar pentru ca pe
> > tine te chinuie creativitatea. Iar asta nu tine de resurse, ci
> > de management-ul proiectului si de mentalitatea (si poate de
> > experienta) developer-ilor.
>
> Incomplet! Tocmai din cauza ca avem asa multe exemple de cum fac altii
> nici nu trebuie sa ai nu stiu ce super mentalitate sau sa te fi nascut
> destept ca sa poti sa faci asemenea politici de project management.
>
> However, depinde foarte mult de putere de dezvoltare, adica de numarul
> de developeri. De exemplu la un proiect la care lucrez eu de ceva
> anisori am incercat sa fac o politica serioasa dezvoltand 2 branch-uri
> (unul development, altul stable in care doar bug fixuri si facilitati
> minore testate fara sa brake compatibility) dar in acesti ani a fost
> evident la fiecare din ciclurile de dezvoltare (au fost 3 pana acum
> in acest sistem stable/development) ca NU avem oamenii si forta
> de dezvoltare sa putem sustine asa ceva (adica sa lungeste timpul
> intre release-uri enorm datorita efortului de a mentine 2 branch-uri
> separate, de a backporta bugfix-uri tot timpul).
Postfix este in esenta un "one-man show". Alti 2-3 contribuie din
cand in cand cate un feature, si multi altii vin ocazional cu cate
un bug report sau un patch de 2 linii. Restul comunitatii tine de
mana user-ii (sub forma de suport pentru configurare si solutii pentru
diferite task-uri practice) si face galerie. Cheia acolo nu sunt, cum
spuneam, resursele, ci faptul ca seful proiectului se ocupa 80% din timp
cu design-ul si documentatia (brainstorming-ul comunitatii poate avea
un rol important aici) si doar 20% cu codul efectiv. De nenumarate ori
a amanat sau chiar a eliminat features care pareau foarte atractive din
punctul de vedere al user-ilor, pentru motivul ca design-ul nu era in
regula. Si aproape de fiecare data implementarea acestor features a
devenit banala cateva luni mai tarziu, cand exista contextul potrivit.
E adevarat ca nu toate proiectele au sansa sa aiba un Wietse Venema
in echipa. De cele mai multe ori insa perceptia ca radacina raului in
problemele proiectelor open source e lipsa de resurse, e doar o iluzie.
Salutari,
Liviu Daia
--
Dr. Liviu Daia http://www.imar.ro/~daia
_______________________________________________
RLUG mailing list
[email protected]
http://lists.lug.ro/mailman/listinfo/rlug
