Sziasztok! Egyrészt nagyon örülök, hogy ilyen vita alakult ki a listán az openSUSE disztribúcióval kapcsolatban, másrészt rengeteg félreértés olvastam. Ezek kommunikációja nyilván nem megfelelően történt meg a részemről, ami az én hibám, ezért úgy látom jónak, hogy külön levélben írjak ezekről, remélem megvilágítva a dolgokat. Hogyan működik a disztribúció fejlesztése? A disztribúciófejlesztés alapvetően két részből áll: vannak a projekt alapú komponensek (ilyen a GNOME, a KDE, a Compiz stb.) és vannak a "belső" fejlesztések, amelyektől a disztribúciót disztribúciónak hívunk. A belső fejlesztések egyébként ugyanúgy nyílt forrásúak, de a Novell adja bele a projekt vezetését és derékhadát. A többi projektnél pedig olyan embereket foglalkoztat főállásban, akik amúgy is a projekten dolgoznak, biztosítva a projekt életben maradását. A projektek kiadnak időről időre egy úgynevezett stabil kiadást, amire a disztribúcióknak nincs közvetlen ráhatása. Természetesen arra van ráhatása, hogy melyik kerül kerül be a disztribúcióba, de ebből a szempontból is igyekeznek körültekintőek lenni. Amelyekből már régen nem jelent meg stabil kiadás, vagy amelyik fejlesztésében a Novell is részt vesz, azokból megjelenik a fejlesztői változat a disztribúcióban. Ez azonban nem egyedülálló dolog. Érdemes összehasonlítani a disztribúciókat ebből a szempontból: * http://distrowatch.com/table.php?distribution=fedora * http://distrowatch.com/table.php?distribution=suse * http://distrowatch.com/table.php?distribution=ubuntu Nincs ordító különbség. Az Ubuntunál kevesebb van, de az Ubuntu rengeteg csomaggal egyáltalán nem foglalkozik a kiadásoknál. Egyetértek azzal, hogy a hibás dolgokat kiadni nem jó, azonban az openSUSE projekt és a Novell is rengeteg javítást tesz a disztribúcióba, illetve backportolnak, hogy a kiadás a lehető legjobb legyen. Az sem igaz, hogy fajlagosan, hogy a 7.x korszakban mennyire stabil is jó volt a disztribúciói. Ez valamilyen szempontból igaz, azonban akkoriban a projektek kevesebben voltak kisebbek voltak és a fejlesztés teljesen zárt volt. A 9.3-as verziót követően a Novell ezt teljesen nyílttá tette, tulajdonképpen az utolsó pillanatban, hiszen annyira komplex lett egy Linux disztribúció, hogy öngyilkosság lett volna belső/zártkörű beta tesztekkel folytatni a fejlesztést. A világ akkor kezdett igazán forrni a disztribúciófejlesztések körül és ez mostanában sem csillapodik - szerencsére. Mi található az Update telepítési forrásban? Az update telepítési forrás feltöltése nem rendszertelenül történik, hanem a hibabejelentések nyomán. Érdemes megnézi a változáslistákat. Szinte minden módosítás után egy bnc# szám található, amely a bejelentett hibára vonatkozik. Ez két dolgot jelent: a) főleg azokkal a problémákkal foglalkoznak, amelyek bejelentésre kerülnek, b) lassabban jelennek itt meg a javított dolgok. Ezen problémák miatt tartják karban a Build Service telepítési forrásokat. Ezekből is van Stable és Unstable és egy hibát ennek használatával érdemes tesztelni és visszajelzést adni azzal kapcsolatban, hogy ez megoldja-e az adott problémát vagy nem. Tömören azt tudom mondani, hogy az Update telepítési forrásban található frissítéseket mindenképpen, a Build Service egyéb telepítési forrásait pedig hibás működés esetén _célszerű_ kipróbálni és megfelelő visszajelzést adni a hibával kapcsolatban. Az openSUSE _NEM_ a SLED/SLES tesztkörnyezete! Ez az egyik legnépszerűbb FUD. Belső levelezési listákon már többször felmerült, hogy ezt rendbe kellene tenni, és én most meg is próbálom a magam módján. Ami igaz: a SLED/SLES az openSUSÉ-ra épülő szűkített disztribúció, fejlesztése és tesztelése zárt és teljesen más termékfejlesztési vezetéssel rendelkezik. Az openSUSE vezetőségében csak 50%-ban vannak Novell alkalmazottak és ők határozzák meg a projket fejlesztési irányait és követelményeit. A Novell adja az infrastruktúrát és a fejlesztők egy részét. Amikor például a lokalizációval foglalkozom teljesen más embereknek kell egyeztetnem ennek kapcsán, annak ellenére hogy azonos svn-ben (csak annak két ágában) dolgozom. A SLE termékvonal teljesen más megfontolások alapján épül fel: a stabilitás minden felett. Mondok egy példát: a 2009 első felében megjelenő SLE verzióban cserélik le a gaim-ot pidgin-re. Sok felhasználó új funkciókat akar gyorsan és stabilan. Ez sajnos nem megy, az SLE célközönségének mások az igényei, ezért nem (csak) az openSUSE tapasztalataiból merítenek a disztribúció összeállításakor, hanem a projekteket is áttekintik és rengeteget backportolnak. A belső fejlesztéseket azonban egy az egyben átveszik. ilyen pl. a YaST. Amint kadnak egy YaST verziót az openSUSE megfelelő verziójához, már be is kerül az SLE verzióba. Mivel a tesztelésekkel egy külső cég van megbízva, ezért azok hibabejelentései után az SLE és az openSUSE ágban is megtörténik a javítás (én legalábbis erre nagyon ügyelek). Számtalanszor érem tetten, hogy mennyit profitál ebből az openSUSE projekt. Hogyan lehet jelezni a problémákat? A levelezési lista az egyik formája ennek. Az viszont nagyon jó lenne, ha egyetlen levélben egyetlen probléma lenne leírva, hogy jobban nyomon lehessen követni annak megoldását, megnyugtató lezárását, vagy az arról való döntést, hogy erről nyissunk bugot a projektnél. Ebben nagyon szívesen segítek. Amit szeretnék kérni, hogy kellő alázattal forduljunk a fejlesztők munkájához, mert valami olyasmit tesznek, amiket mi nem: fejlesztenek, tehát hibáznak, ezért nem jó, ha ingerült hangnemben megmondjuk, hogy ez vagy az nagyon nem jó munka (mégha igazunk is van). Próbáljunk segíteni a probléma lokalizálásában, mert ez a legnagyobb segítség. Ha ez nem megy, akkor csak mondjuk el a problémát és talán más folytatja annak lokalizálását, amiből bejelentés esetleg javítás születik. Hogyan működhetne ez közösségként? Talán ez a legjobb rész. A levelezési lista hatalmas, ugyanakkor passzív. Ha valakik szeretnének közreműködni bármiben, akkor elkezdhetnénk ezen ötletelni arról, hogy hogyan tesztelhetnénk közösen, hogyan legyenek jó minőségű dokumentációk, hogyan legyen fantasztikus wiki, news és a többi. Megértem, ha vannak, akik csak használni szeretnék a disztribúciót. Tőlük a reprodukálható hibabejelentések lehetnek a legjobb közösségi munkák... Bánthatjuk egymást a listán, bánthatjuk a disztribúciót, de ez nem visz előrébb. Részemről mindenkinek segíteni szeretnék a problémája megoldásában és látom, hogy több ilyen listatag is van, aki hasonlóan gondolkodik. Próbáljunk konstruktívak lenni és egy remek disztribúció lesz a jutalmunk... köszönöm mindenkinek, aki végigolvasta k N�����r��y隊Z)z{.��n��칻 �&ޢ���� �����v+b�v�r��jwlzf���^�ˬz���i����� ��