[openeda:2004] - Re: sastanak 19.03.2004. by Toplica Tanaskovic <toptan@kde.org.yu>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dana petak 19 mart 2004 20:27, Gvozden Marinkovic napisa:

> Prijatno sam iznenadjen interesovanjem za ovaj projekat.
> Drago mi je da ima toliko ljudi spremnih da nesto rade.
> Nadam se da ce entuzijazam dovoljno dugo trajati.

	Takođe.
> Tim2 - core:
> 1. Nikola Stojiljkovic *
> 2. Vladimir Milivojevic
> 3. Nikola Randjelovic
> 4. Toplica Tanaskovic

	:)
	Ja ću biti član sva tri tima, manje trećeg, više prva dva. Razlozi:
1. Ne omalovažavam nikoga, ali mislim da članovi tima 1 nemaju baš puno 
iskustva sa Qt/KDE gui sistemom...
2. Ista priča samo ovaj put za non-gui Qt sistem.
3. Kad se timovi ustale i budu preležali dečje bolesti, verovatno ću se 
skrasiti u nekom od prva dva tima...

> Na sastanku je takodje dogovoreno sledece:
>
> - kor sistema bi trebao da bude sto je moguce manje
> zavistan od KDE-a, da bi bilo moguce portovanje na
> Windows. Ukoliko je potrebna cvrsca veza za KDE-om
> bice izdvojeno u poseban set klasa (da kazemo da ce
> mo imati razlicite implementacije osnovnog apstraktnog
> interfejsa).

	!? Zašto!?
Nema potrebe, za različitom implementacijom. Evo zašto:
1. Od celog KDE-a, nama trebaju samo kdelibs, dakle biblioteke. One za sada ne 
mogu da se iskompajliraju koristeći samo Qt biblioteke, ali je 
"pročišćavanje" u toku. Verzija 3.3 bi trebalo da bude u potpunosti zasnovana 
samo na Qt-u...
2. Mnogi programi koji koriste kdelibs su u potpunosti nezavisni od X-eva i 
linux-a uopšte. Guglajte samo za KDE apps on OSX, kako Qt nudi kompatibilnost 
na nivou sorsa između platformi ne vidim razlog zašto naš paket ne bi mogao 
da se kompajlira bez problema na linux, windows i MacOSX mašinama.
3. Jel čuo neko za mingw? gcc iz njega daje native windows executable 
programe, a ko je malo gledao sors Qt-a zna i da tamo ima target win32-g++,
tako dobijamo i besplatne identične alate za razvoj paketa (gcc, make, 
automake i kompanija...)
4. Ukoliko nemamo iza sebe kdelibs kao potporu, ode mas u propas što se tiče 
lokalizacije našeg paketa, pošto nećemo imati ugrađenu gettext podršku. 
Guglajte za gettext sistemom. On radi na svim platformama identično, tako da 
opet ništa nećemo morati da menjamo po sorsu za razne portove...

> - tim 1 koji radi GUI, takodje o tome treba da vodi
> racuna, tako sto ce omoguciti kasniju realizaciju i
> za druge platforme.

	Nema potrebe. Tim 1 treba da vodi računa samo da ne koristi OS-specific 
stvari, tj. da ne piše "prljav" kod. Tačnije da ne izađe iz okvira Qt/KDE 
biblioteka...

> - vodje timova treba da pogledaju i prouce postojece
> alate (Protel, OrCAD) i da popisu osobine elemenata
> i mogucnosti programa. Na osnovu toka definisace se
> skup funkcionalnosti koje ce i openEDA podrzavati.

	Ovo je u redu, ali je za početak previše. Ukoliko u startu budemo imali 
veliki broj osobina, GUI tim ima toliko da se zakopa da neće imati prvu radnu 
stabilnu verziju ni za godinu dana! Ponavljam još jednom, treba naći 
minimalni skup osobina, a opet dovoljno funkcionalan, tako da tim 1 može 
izaći sa nekim GUI-jem u nekom razumnom vremenskom roku. Zbog toga timovi i 
jesu međusobno nezavisni, timovi 2 i 3 naprave lako proširivu osnovu osobina 
lupi se tag u CVS, tim 1 koristi biblioteke date verzije, a 2 i 3 teraju 
dalje. Kad 1 završi sve sa bibliotekama date verzije, lupi se tag i na njihov 
deo koda, to se proglasi verzijom tom i tom, koja zahteva biblioteke verzije 
te i te i tera dalje sa radom koristeći novije biblioteke timova 2 i 3 i tako 
non stop...
	Svi smo mi ovde puni entuzijazma i voljni da radimo, al dajte da ne grizemo 
više nego što možemo da sažvaćemo...

> - vodje timova trebaju da se dogovore oko interfejsa
> izmedju timova (ko sta od koga trazi i kako:)

	Nema preteranog dogovaranja. Prosto rečeno tim 2 ima glavnu reč. On definiše 
minimalni skup osobina i jednostavno kaže timu 3 daj mi API za dobijanje tih 
osobina iz XML-a, takođe uz malu konsultaciju kaže timu jedan ovo su ti 
pozivi za dobijanje osobina nekog elementa i kraj. Naravno tim 2 mora da vodi 
računa o kompletnosti osobina koje svojim API-jem daje timu 1, kao i o 
kompletnosti osobina koje traži da mu tim 3 da preko svog API-ja. Timovi 1 i 
3 praktično ne bi trebali nikada oči jedno drugima da vide.
	Šta će tim 2 da radi sa podacima koje dobije API-jem tima 3, i kako će sa 
njima da postupa pri obradi i prosleđivanju timu 1 ne sme nikoga sa strane da 
interesuje, niti neko sa strane tu ima uticaja. Osim u dobro obrazloženim i 
dokumentovanim i DOBRO istestiranim slučajevima.
	Tako rade KDE i GNOME, tj kde-core tim koji razvija kdelibs i gnome-core tim 
koji razvija gnomelibs. Mislim da su oni što se tiče organizacije i metode 
rada pri razvijanju kompleksnih sistema neko na koga bi trebalo da se 
ugledamo i čija bi iskustva trebalo da koristimo.

- -- 
Pozdrav,
Tanasković Toplica
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAYGc+tKJqksC6c0sRAm6aAJ9Kr9QjeARDF9JP01pW/xv4w7KXXQCff4wY
5/5zyyyvE0sDKdCA/G7Z2c0=
=UEQ+
-----END PGP SIGNATURE-----