Mailinglist Archive: opensuse-hu (140 mails)
| < Previous | Next > |
[opensuse-hu] próbalevél: openSUSE félreértések
- From: "Kálmán Kéménczy" <kkemenczy@xxxxxxxxxxx>
- Date: Sat, 3 Jan 2009 08:56:45 +0100
- Message-id: <7ed179420901022356k670731c9k8577d4d4def81504@xxxxxxxxxxxxxx>
Ezt a levelet a levelezőrendszer tesztje miatt küldöm újra.
Aki egyszer már megkapta az hagyja figyelmen kívül. köszönöm
k
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˘§˛ë ˘¸
Aki egyszer már megkapta az hagyja figyelmen kívül. köszönöm
k
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˘§˛ë ˘¸
| < Previous | Next > |