[opensuse-hu] bugzilla bejegyzés
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sziasztok! Az "Ez is egy vélemény" szál olvasásakor jutott eszembe egy ötlet. Felmerült a tud angolul, írjon bug reportot dolog, illetve a magyar hibabejelentő rendszer. Az jutott ezzel kapcsolatban eszembe, hogy itt a lev. listán, akik éreznek magukban erőt, azok bejelenthetnék mások hibáit. Persze ehhez szükséges az, hogy a másik emberből tényleg csak a nyelvtudás hiányozzon, és ne az utánajárási hajlandóság. Azt hiszem akik használják a bugzillát, nem szívesen áldozzák be a "ez a gyerek korrekt bejelentőket ad, és utána nem tűnik el" státuszukat, ha angol lev. listán kérdezel utána dolgoknak, akkor ott szembetűnőbb, hogy nem mindenkinek ugyanolyan elánnal segít a "community". Általánosságban ha téged megismertek valamilyennek (akár neten keresztül), nyilván az ezzel "kivívott" odafigyelést nem áldoznád fel más nem törődömsége miatt. Tehát olyanok "adjanak be" bejelentőt, akik tényleg komolyan gondolják, hogy utána akarnak járni a problémának, és válaszolnak a kérdésekre, nem jönnek 2 hét után, hogy "ja, már Ubuntut/Mandrivát/Debiant/xy-t használok, nem érdekel". Gondolom a magyar bejelentő rendszer úgyis egy forward-szerver lenne a bugzilla felé. Először próbáljuk ki kicsiben, van-e rá egyáltalán igény? Ez csak egy ötlet, bármilyen hosszú is. Vélemény? Üdv.: Tamás -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkpmD/wACgkQsuVyj8v2Zy4QZQCfUBP5xFP665EA6QGrW6Cn1cIE sMQAnAw7EXcT/l7s1X+Qycs4IxOBV/oP =/mEV -----END PGP SIGNATURE-----
Szia!
Gondolom a magyar bejelentő rendszer úgyis egy forward-szerver lenne a bugzilla felé. Először próbáljuk ki kicsiben, van-e rá egyáltalán igény?
Ez csak egy ötlet, bármilyen hosszú is. Vélemény?
Nekem kicsit más az elképzelésem ezzel kapcsolatban és még a részletek ki kell dolgozni, de akkor felvázolnám: - lesz egy leírás arról, hogy egy hiba bejelentéshez mit kell tenni pontosan: tipikusan lesz egy script, ami összeszedi a lényeges paramétereket, enélkül nehéz bármit is mondani, ebben viszont szinte minden fontos info benne les (a Novell supportnál ez egy jól bejáratott mechanizmus). Szerintem ezzel a maroknyi segítő nagyon hatékony lehet. Nem tudom még, hogy hova hogyan legyen ez feltöltve. - a segítségkérés során szükség van a bejelentő közreműködésére is és az info alapján elindulhat egy megoldási folyamat - minden, és ez nagyon fontos _minden_ segítségkérésnek kell lennie végének, vagy megoldás legyen, amiből SDB készül a wikire (ezt célszerűnek annak kéne elkészítenie, akinek a problémája volt és segíthetnek a megoldók, illetve azok, akik a levelezés kapcsán képesek felgönygyölíteni az ügyet.), vagy bug, amire bugzilla bejegyzés készül (ezt a Novellnél lévő fantasztikus kollégákkal tudjuk vállalni, de csak akkor, ha már minden info rendelkezésre áll, esetleg reprodukálható). tehát a fórum és levlista bejegyzések utolsó szála a hibáknál valamilyen link lenne. Tudom, hogy ez túl utópisztikus és nagyon professzionális megközelítés, de ha ebben benne vagytok, akkor szerintem hatékony lehet. Vélemény? k
Kálmán Kéménczy írta:
Szia!
Tudom, hogy ez túl utópisztikus és nagyon professzionális megközelítés, de ha ebben benne vagytok, akkor szerintem hatékony lehet.
Vélemény?
k Felhasználóként (talán kicsit aktívabb felhasználóként) nagyon jó iránynak tartom. Aki akar segíteni, jelentést, tapasztalatot írni annak ez a "kapcsolat" hasznos lehet. Csak legyen tényleges végeredménye is.
-- Üdv: Karesz _____________________ www.kareszka.hu
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Kálmán Kéménczy wrote:
Szia!
Gondolom a magyar bejelentő rendszer úgyis egy forward-szerver lenne a bugzilla felé. Először próbáljuk ki kicsiben, van-e rá egyáltalán igény?
Ez csak egy ötlet, bármilyen hosszú is. Vélemény?
Nekem kicsit más az elképzelésem ezzel kapcsolatban és még a részletek ki kell dolgozni, de akkor felvázolnám:
<snip> Sziasztok! Ez tényleg jó ötlet. Nem is gondoltam volna, hogy ilyen grandiózus dologra gondoltál :) Ez tényleg professzionális megközelítés. Egy játszós partíciót/virtuális gépet látok a szemeim előtt, amin van egy image-ből felmásolt alaprendszer, amire az információgyűjtő szkript párja felmásolja a kapott konfig- és egyéb fájlokat, aztán bejegyzi az ugyancsak összegyűjtöt repókat, majd a zypper-nek átadja a csomaglistát, és máris kész a tesztkörnyezet. Ez a Novellnél hogy működik? Ha valami nehezen reprodukálható probléma van, akkor hogy csináltok tesztkörnyezetet? Nekem nagyon tetszik az ötlet, bár a *minden* segítségkérést végig kell vinni, lehet, hogy pont a segíteni akarókat ijeszti meg. Mindenesetre ez a kitétel tényleg nagyon magasra teszi a lécet. Igaz, a dolgok így haladnak előre :) Üdv.: Tamás -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkpmGmwACgkQsuVyj8v2Zy4/NACgl/cswW1fSG7IlilV5IbHj7iA dLQAnjulKGayuryuEGF3iH9y4wkYKthU =80LX -----END PGP SIGNATURE-----
Egy játszós partíciót/virtuális gépet látok a szemeim előtt, amin van egy image-ből felmásolt alaprendszer, amire az információgyűjtő szkript párja felmásolja a kapott konfig- és egyéb fájlokat, aztán bejegyzi az ugyancsak összegyűjtöt repókat, majd a zypper-nek átadja a csomaglistát, és máris kész a tesztkörnyezet. Ez a Novellnél hogy működik? Ha valami nehezen reprodukálható probléma van, akkor hogy csináltok tesztkörnyezetet?
Ennél prózaibb a helyzet. A begyűjtött log kerül kiértékelésre. Abból már sok minden kiderül. A reprodukálás ez alapján manuálisan zajlik, ha rá tudunk fókuszálni a hibára. Sajnálom, ha nem annyira űrrakéta, ahogy gondoltad :)
Nekem nagyon tetszik az ötlet, bár a *minden* segítségkérést végig kell vinni, lehet, hogy pont a segíteni akarókat ijeszti meg. Mindenesetre ez a kitétel tényleg nagyon magasra teszi a lécet. Igaz, a dolgok így haladnak előre :)
A segíteni akarók lehetnek bárhonnan, a lényeg, hogy legyenek "sweeperek", akik ügyelnek a lezárásra, begyűjtik az infot, ha valami félbemaradt, hogy ne legyen elvarratlan szál. Ha egy ilyen kis közösség összejönne, akkor vonzó lehet a disztró is. k
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Kálmán Kéménczy wrote:
Ennél prózaibb a helyzet. A begyűjtött log kerül kiértékelésre. Abból már sok minden kiderül. A reprodukálás ez alapján manuálisan zajlik, ha rá tudunk fókuszálni a hibára. Sajnálom, ha nem annyira űrrakéta, ahogy gondoltad :)
Hát azt hittem ennél misztikusabb a dolog :) Persze, aki SLES-t/SLED-et használ, az megérdemli a manuális kezelését a problémának. A Hollóházira is kézzel festik a mintát :) Az egész problémát rossz oldalról fogtam meg. Én a konfig fájlokat gondoltam fontosabbnak, de persze, a log fájlok sok mindent elárulnak. Tamás -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkpmKeMACgkQsuVyj8v2Zy4JAQCdGL9VjSHbyto35GMNJ5PpuaRY jIYAni7A/gQoBjQd5dm5vgArcGRXkQ6B =SDdH -----END PGP SIGNATURE-----
Ennél prózaibb a helyzet. A begyűjtött log kerül kiértékelésre. Abból már sok minden kiderül. A reprodukálás ez alapján manuálisan zajlik, ha rá tudunk fókuszálni a hibára. Sajnálom, ha nem annyira űrrakéta, ahogy gondoltad :)
Hát azt hittem ennél misztikusabb a dolog :) Persze, aki SLES-t/SLED-et használ, az megérdemli a manuális kezelését a problémának. A Hollóházira is kézzel festik a mintát :)
Az egész problémát rossz oldalról fogtam meg. Én a konfig fájlokat gondoltam fontosabbnak, de persze, a log fájlok sok mindent elárulnak.
nem pontosan írtam: nem csak log, hanem config is. aztán minderre van analizátor, tehát nem annyira kézihajtány. k
Ha már a hibabejelentésnél tartunk és általában bejelentem a hibákat, de van valami amivel nem tudok mit kezdeni, mert a jelenség nem reprodukálható. OpenSuse 11.1-et használok. Mind a firefox, mind a thunderbird a legváratlanabb pillanatban lefagy. Aztán újraindítva megint megy, mintha mi sem történt volna. Azt gondoltam KDE4 miatt lehet, visszaálltam KDE3-ra, de ugyanaz a helyzet. Valami ötlet? Köszönöm Tibor Kálmán Kéménczy írta:
Ennél prózaibb a helyzet. A begyűjtött log kerül kiértékelésre. Abból már sok minden kiderül. A reprodukálás ez alapján manuálisan zajlik, ha rá tudunk fókuszálni a hibára. Sajnálom, ha nem annyira űrrakéta, ahogy gondoltad :)
Hát azt hittem ennél misztikusabb a dolog :) Persze, aki SLES-t/SLED-et használ, az megérdemli a manuális kezelését a problémának. A Hollóházira is kézzel festik a mintát :)
Az egész problémát rossz oldalról fogtam meg. Én a konfig fájlokat gondoltam fontosabbnak, de persze, a log fájlok sok mindent elárulnak.
nem pontosan írtam: nem csak log, hanem config is. aztán minderre van analizátor, tehát nem annyira kézihajtány.
k
Ezeknek a közös része a xul, de azért kérlek adj meg egy
verziószámot vagy repot, ahonnan telepítettel.
k
2009/7/22 Nagy Tibor
Ha már a hibabejelentésnél tartunk és általában bejelentem a hibákat, de van valami amivel nem tudok mit kezdeni, mert a jelenség nem reprodukálható.
OpenSuse 11.1-et használok. Mind a firefox, mind a thunderbird a legváratlanabb pillanatban lefagy. Aztán újraindítva megint megy, mintha mi sem történt volna. Azt gondoltam KDE4 miatt lehet, visszaálltam KDE3-ra, de ugyanaz a helyzet.
Valami ötlet?
Köszönöm
Tibor
Kálmán Kéménczy írta:
Ennél prózaibb a helyzet. A begyűjtött log kerül kiértékelésre. Abból már sok minden kiderül. A reprodukálás ez alapján manuálisan zajlik, ha rá tudunk fókuszálni a hibára. Sajnálom, ha nem annyira űrrakéta, ahogy gondoltad :)
Hát azt hittem ennél misztikusabb a dolog :) Persze, aki SLES-t/SLED-et használ, az megérdemli a manuális kezelését a problémának. A Hollóházira is kézzel festik a mintát :)
Az egész problémát rossz oldalról fogtam meg. Én a konfig fájlokat gondoltam fontosabbnak, de persze, a log fájlok sok mindent elárulnak.
nem pontosan írtam: nem csak log, hanem config is. aztán minderre van analizátor, tehát nem annyira kézihajtány.
k
Sztandard SuSe UPdater-t használok ntibor@ntiborhp:~(1003)>rpm -qa | grep -i firefox MozillaFirefox-3.0.11-0.1.1 MozillaFirefox-branding-openSUSE-3.0.3-3.11 beagle-firefox-0.3.8-46.34.1 MozillaFirefox-translations-3.0.11-0.1.1 ntibor@ntiborhp:~(1004)>rpm -qa | grep -i thunder MozillaThunderbird-2.0.0.22-0.1.1 MozillaThunderbird-translations-2.0.0.22-0.1.1 ntibor@ntiborhp:~(1005)>rpm -qa | grep -i xul mozilla-xulrunner190-translations-1.9.0.11-1.1.1 mozilla-xulrunner190-1.9.0.11-1.1.1 mozilla-xulrunner190-gnomevfs-1.9.0.11-1.1.1 Tibor Kálmán Kéménczy írta:
Ezeknek a közös része a xul, de azért kérlek adj meg egy verziószámot vagy repot, ahonnan telepítettel.
k
2009/7/22 Nagy Tibor
: Ha már a hibabejelentésnél tartunk és általában bejelentem a hibákat, de van valami amivel nem tudok mit kezdeni, mert a jelenség nem reprodukálható.
OpenSuse 11.1-et használok. Mind a firefox, mind a thunderbird a legváratlanabb pillanatban lefagy. Aztán újraindítva megint megy, mintha mi sem történt volna. Azt gondoltam KDE4 miatt lehet, visszaálltam KDE3-ra, de ugyanaz a helyzet.
Valami ötlet?
Köszönöm
Tibor
Kálmán Kéménczy írta:
Ennél prózaibb a helyzet. A begyűjtött log kerül kiértékelésre. Abból már sok minden kiderül. A reprodukálás ez alapján manuálisan zajlik, ha rá tudunk fókuszálni a hibára. Sajnálom, ha nem annyira űrrakéta, ahogy gondoltad :)
Hát azt hittem ennél misztikusabb a dolog :) Persze, aki SLES-t/SLED-et használ, az megérdemli a manuális kezelését a problémának. A Hollóházira is kézzel festik a mintát :)
Az egész problémát rossz oldalról fogtam meg. Én a konfig fájlokat gondoltam fontosabbnak, de persze, a log fájlok sok mindent elárulnak. nem pontosan írtam: nem csak log, hanem config is. aztán minderre van analizátor, tehát nem annyira kézihajtány.
k
Kérlek vedd fel innen a megfelelő repot és teszteld ezzel a verzióval is.
http://download.opensuse.org/repositories/mozilla/
ez itt 3.5-re frissít.
a 3.0.12 is javít hasonló hibát, de talán jobb 3.5-re frissíteni.
k
2009/7/24 Nagy Tibor
Sztandard SuSe UPdater-t használok
ntibor@ntiborhp:~(1003)>rpm -qa | grep -i firefox MozillaFirefox-3.0.11-0.1.1 MozillaFirefox-branding-openSUSE-3.0.3-3.11 beagle-firefox-0.3.8-46.34.1 MozillaFirefox-translations-3.0.11-0.1.1 ntibor@ntiborhp:~(1004)>rpm -qa | grep -i thunder MozillaThunderbird-2.0.0.22-0.1.1 MozillaThunderbird-translations-2.0.0.22-0.1.1 ntibor@ntiborhp:~(1005)>rpm -qa | grep -i xul mozilla-xulrunner190-translations-1.9.0.11-1.1.1 mozilla-xulrunner190-1.9.0.11-1.1.1 mozilla-xulrunner190-gnomevfs-1.9.0.11-1.1.1
Tibor
Kálmán Kéménczy írta:
Ezeknek a közös része a xul, de azért kérlek adj meg egy verziószámot vagy repot, ahonnan telepítettel.
k
2009/7/22 Nagy Tibor
: Ha már a hibabejelentésnél tartunk és általában bejelentem a hibákat, de van valami amivel nem tudok mit kezdeni, mert a jelenség nem reprodukálható.
OpenSuse 11.1-et használok. Mind a firefox, mind a thunderbird a legváratlanabb pillanatban lefagy. Aztán újraindítva megint megy, mintha mi sem történt volna. Azt gondoltam KDE4 miatt lehet, visszaálltam KDE3-ra, de ugyanaz a helyzet.
Valami ötlet?
Köszönöm
Tibor
Kálmán Kéménczy írta:
Ennél prózaibb a helyzet. A begyűjtött log kerül kiértékelésre. Abból már sok minden kiderül. A reprodukálás ez alapján manuálisan zajlik, ha rá tudunk fókuszálni a hibára. Sajnálom, ha nem annyira űrrakéta, ahogy gondoltad :)
Hát azt hittem ennél misztikusabb a dolog :) Persze, aki SLES-t/SLED-et használ, az megérdemli a manuális kezelését a problémának. A Hollóházira is kézzel festik a mintát :)
Az egész problémát rossz oldalról fogtam meg. Én a konfig fájlokat gondoltam fontosabbnak, de persze, a log fájlok sok mindent elárulnak. nem pontosan írtam: nem csak log, hanem config is. aztán minderre van analizátor, tehát nem annyira kézihajtány.
k
Kálmán! azt hiszem, hogy itt a probléma a 11.1-el. (gondolok a default installer DVD-ére [kde4.1 ...]) Különböző repokból lehet összevadászni egy használható rendszert. Nekem pl KDE factory-ból kellett kde4.3-at telepítenem, hogy használható legyen a desktop. A kernelben levő ath5k wlan driver ősrégi. alapból 1Mbs -el képes menni és 11Mbs-ig lehet felhúzni. Ha viszont letöltöd és lefordítod a Linux wireless compatibility package http://linuxwireless.org/en/users/Download-et akkor kapásból 54Mbs-el megy. Ez több hónappal fiatalabb egy csomó fejlesztés van benne és ez már stabilként van deklarálva. Persze Mi linux szakértők utána nézünk a dolgoknak, olvassuk a fórumokat néhány heti munkával kipofozzuk a rendszerünket majd büszkélkedünk vele, hogy nálunk minden tökéletesen működik. Ha valaki pedig esetleg más véleményt fogalmaz meg, akkor neki esünk. (ld. az elmúlt napok polémiáját. Magáért beszél) Üdv, Sanyi Kálmán Kéménczy írta:
Kérlek vedd fel innen a megfelelő repot és teszteld ezzel a verzióval is. http://download.opensuse.org/repositories/mozilla/ ez itt 3.5-re frissít. a 3.0.12 is javít hasonló hibát, de talán jobb 3.5-re frissíteni.
k
2009/7/24 Nagy Tibor
: Sztandard SuSe UPdater-t használok
ntibor@ntiborhp:~(1003)>rpm -qa | grep -i firefox MozillaFirefox-3.0.11-0.1.1 MozillaFirefox-branding-openSUSE-3.0.3-3.11 beagle-firefox-0.3.8-46.34.1 MozillaFirefox-translations-3.0.11-0.1.1 ntibor@ntiborhp:~(1004)>rpm -qa | grep -i thunder MozillaThunderbird-2.0.0.22-0.1.1 MozillaThunderbird-translations-2.0.0.22-0.1.1 ntibor@ntiborhp:~(1005)>rpm -qa | grep -i xul mozilla-xulrunner190-translations-1.9.0.11-1.1.1 mozilla-xulrunner190-1.9.0.11-1.1.1 mozilla-xulrunner190-gnomevfs-1.9.0.11-1.1.1
Tibor
Kálmán Kéménczy írta:
Ezeknek a közös része a xul, de azért kérlek adj meg egy verziószámot vagy repot, ahonnan telepítettel.
k
2009/7/22 Nagy Tibor
: Ha már a hibabejelentésnél tartunk és általában bejelentem a hibákat, de van valami amivel nem tudok mit kezdeni, mert a jelenség nem reprodukálható.
OpenSuse 11.1-et használok. Mind a firefox, mind a thunderbird a legváratlanabb pillanatban lefagy. Aztán újraindítva megint megy, mintha mi sem történt volna. Azt gondoltam KDE4 miatt lehet, visszaálltam KDE3-ra, de ugyanaz a helyzet.
Valami ötlet?
Köszönöm
Tibor
Kálmán Kéménczy írta:
> Ennél prózaibb a helyzet. A begyűjtött log kerül kiértékelésre. Abból > már sok minden kiderül. > A reprodukálás ez alapján manuálisan zajlik, ha rá tudunk fókuszálni a hibára. > Sajnálom, ha nem annyira űrrakéta, ahogy gondoltad :) > > Hát azt hittem ennél misztikusabb a dolog :) Persze, aki SLES-t/SLED-et használ, az megérdemli a manuális kezelését a problémának. A Hollóházira is kézzel festik a mintát :)
Az egész problémát rossz oldalról fogtam meg. Én a konfig fájlokat gondoltam fontosabbnak, de persze, a log fájlok sok mindent elárulnak.
nem pontosan írtam: nem csak log, hanem config is. aztán minderre van analizátor, tehát nem annyira kézihajtány.
k
Persze Mi linux szakértők utána nézünk a dolgoknak, olvassuk a fórumokat néhány heti munkával kipofozzuk a rendszerünket majd büszkélkedünk vele, hogy nálunk minden tökéletesen működik. Ha valaki pedig esetleg más véleményt fogalmaz meg, akkor neki esünk. (ld. az elmúlt napok polémiáját. Magáért beszél)
Én nem vagyok Linux szakértő és éppen ezért nem használok extrém telepítési forrást és nem fordítok magamnak semmit. Talán az egyetlen különbség, hogy én alapvetően gnome asztali környezetet használok. Sokszor elgondolkodom, hogy mitől lehet egy rendszer stabil, és itt a rendszer alatt az egész ecosystemet értem, és alapvetően három alappillér van: a) támogatott hardver b) egységes szoftver c) szakértői támogatás Nagyon sok probléma abból adódik, hogy olyan hardverrel van dolgunk, amelyhez nincs megfelelő illesztőprogram (az Apple nem véletlenül árulja együtt a hardvert és a szoftvert, hiszen ezzel rengeteg hibát kiküszöbölnek). A szoftvereket szintén megfelelő helyekről kell beszerezni. Ki kell választani azokat a repokat, amelyekben lehet bízni és nem törik meg a rendszer integritását. Egy integritásteszt nem egyszerű feladat. Éppen ezért a kockázat nem elhanyagolható, amikor a kiadott KDE 4.1-et KDE 4.2 majd 4.3 frissítünk bármilyen repobol is. Megjegyzem a gnome frissítéskor is van ilyen probléma. Pontosan ezért kell meggondolni, hogy pontosan mit és hogyan használ az ember. Amikor a fenti kettő megvalósul egy olyan stabil mechanizmus áll ellő, amely mögé felsorakoztathatók szakemberek, hiszen nem egy reménytelen ámokfutás kezdődik a hardverelemek, illesztőprogramok és repok között. Valahogy ezt kellene megvalósítani. A nyílt forrású rendszerek fejlesztése azonban azzal kecsegtet, hogy mindig a legfrissebb dolgokat kapjuk kézhez, ennek azonban megvan annak a veszélye, hogy egy rendkívül instabil rendszert kapuk, frusztrált felhasználóval és tanácstalan támogatóval. k
Ha nem csal a szemem, 2009. július 25. szombat keltezéssel Kálmán Kéménczy alábbiakat küldte drótpostán: Hali!
A szoftvereket szintén megfelelő helyekről kell beszerezni. Ki kell választani azokat a repokat, amelyekben lehet bízni és nem törik meg a rendszer integritását. Akkor talán nagyon hangsúlyosan közzé kellene tenni, hogy melyek azok a repok. Mert így még a hozzáértők is beleszaladnak olyan meglepetésekbe, melyek kijavítása sok időt vesz igénybe.
Egy integritásteszt nem egyszerű feladat. Éppen ezért a kockázat nem elhanyagolható, amikor a kiadott KDE 4.1-et KDE 4.2 majd 4.3 frissítünk bármilyen repobol is. Ez teljesen igaz, csak éppen egy win-ről vagy netán KDE 3.xről áttérő felhasználó számára a KDE 4.1 használhatatlan és mivel az újabb verziókat mindig úgy harangozzák be, hogy azok már megoldanak "minden" problémát frissít rá az ember.
Amikor a fenti kettő megvalósul egy olyan stabil mechanizmus áll ellő, amely mögé felsorakoztathatók szakemberek, hiszen nem egy reménytelen ámokfutás kezdődik a hardverelemek, illesztőprogramok és repok között. Na igen, de ehhez nem elhanyagolható a hadvergyártók hatékony együttműködése. Talán, ha már a fejlesztési folyamat során bevonnának szoftver fejlesztőket...
jókat: .~. /V\ /( )\ Zsiráf ^^ ^^ openSUSE 11.1 / 2.6.27.7 / KDE 4.2.4 / OpenOffice.org 3.1.0
A szoftvereket szintén megfelelő helyekről kell beszerezni. Ki kell választani azokat a repokat, amelyekben lehet bízni és nem törik meg a rendszer integritását. Akkor talán nagyon hangsúlyosan közzé kellene tenni, hogy melyek azok a repok. Mert így még a hozzáértők is beleszaladnak olyan meglepetésekbe, melyek kijavítása sok időt vesz igénybe.
Igen, ezeket kiválasztása fontos, ez a mi feladatunk.
Egy integritásteszt nem egyszerű feladat. Éppen ezért a kockázat nem elhanyagolható, amikor a kiadott KDE 4.1-et KDE 4.2 majd 4.3 frissítünk bármilyen repobol is. Ez teljesen igaz, csak éppen egy win-ről vagy netán KDE 3.xről áttérő felhasználó számára a KDE 4.1 használhatatlan és mivel az újabb verziókat mindig úgy harangozzák be, hogy azok már megoldanak "minden" problémát frissít rá az ember.
Szét kell tudnunk választani a marketinget a valóságtól.
Amikor a fenti kettő megvalósul egy olyan stabil mechanizmus áll ellő, amely mögé felsorakoztathatók szakemberek, hiszen nem egy reménytelen ámokfutás kezdődik a hardverelemek, illesztőprogramok és repok között. Na igen, de ehhez nem elhanyagolható a hadvergyártók hatékony együttműködése. Talán, ha már a fejlesztési folyamat során bevonnának szoftver fejlesztőket...
ez olyasmi, amire nincs ráhatásunk. hardvervásárlás előtt kell ezt tudatosítani az emberekben a másik fontos dolog, hogy a Novell-nél ingyenes a hardverteszt, amivel az SLE termékekre nemzetközi tesztet végzünk. Nem tudom, hogy még hogy ezek a tesztek, hogyan vezethetők át az openSUSE-ra, de az lenne a jó, ha a hardeverforgalmazók készítenének olyan hardver-összeállítást, amelyek leminősítenének és úgy árulnánk, ezt követően jobban tudnák ők támogatni is. Szeptemberre tervezek egy ilyen kampányt a kiskereskedésekben. k
Ha nem csal a szemem, 2009. július 25. szombat keltezéssel Kálmán Kéménczy alábbiakat küldte drótpostán:
Akkor talán nagyon hangsúlyosan közzé kellene tenni, hogy melyek azok a repok. Mert így még a hozzáértők is beleszaladnak olyan meglepetésekbe, melyek kijavítása sok időt vesz igénybe. Igen, ezeket kiválasztása fontos, ez a mi feladatunk. Mármint kinek a feladata? Azt egyébként nem lehetne egyeztetni a külsős repok (pl. packman, VLC) fenntartóival, hogy figyeljenek oda az integritásra?
Szét kell tudnunk választani a marketinget a valóságtól. Ebben egyetértek, viszont akkor a KDE4 esetében erősen felmerül a Novell/openSUSE csapat felelőssége.
hardvervásárlás előtt kell ezt tudatosítani az emberekben Szerinted ez hogyan valósítható meg?
Nem tudom, hogy még hogy ezek a tesztek, hogyan vezethetők át az openSUSE- ra, Szerintem a Novell felügyelete mellett lehetne találni rá embereket a közösségből.
jókat: .~. /V\ /( )\ Zsiráf ^^ ^^ openSUSE 11.1 / 2.6.27.7 / KDE 4.2.4 / OpenOffice.org 3.1.0
Akkor talán nagyon hangsúlyosan közzé kellene tenni, hogy melyek azok a repok. Mert így még a hozzáértők is beleszaladnak olyan meglepetésekbe, melyek kijavítása sok időt vesz igénybe. Igen, ezeket kiválasztása fontos, ez a mi feladatunk. Mármint kinek a feladata? Azt egyébként nem lehetne egyeztetni a külsős repok (pl. packman, VLC) fenntartóival, hogy figyeljenek oda az integritásra?
a közösségé, akik segítenek azoké... én pl. a packmant sem használom, mert nalam problémákat okozott, de valószínű egy megfelelő prioritásbeállítás kell csak. Nem hiszem hogy a mi feladatunk szolni az intergritas javitasarol (max hibabejelentest. Olyan feladatokat celszeru megnevezni, amit az ember hazon belul meg tud oldani, kulonben elszall az egesz.
Szét kell tudnunk választani a marketinget a valóságtól. Ebben egyetértek, viszont akkor a KDE4 esetében erősen felmerül a Novell/openSUSE csapat felelőssége.
Ez nem a mi teruletunk szinten.
hardvervásárlás előtt kell ezt tudatosítani az emberekben Szerinted ez hogyan valósítható meg?
tudatositani kell az emberekben es a kiskereskedokben is. a nagykereskedelmet (pl. mediamerkt) ez nem erdekli
Nem tudom, hogy még hogy ezek a tesztek, hogyan vezethetők át az openSUSE- ra, Szerintem a Novell felügyelete mellett lehetne találni rá embereket a közösségből.
igen, csak nem tudjuk, hogy technikaliag hogyan mukodik ez openSUSE-n k
Ha nem csal a szemem, 2009. július 25. szombat keltezéssel Kálmán Kéménczy alábbiakat küldte drótpostán:
a közösségé, akik segítenek azoké... Hm. Nos akkor talán a tapasztalatok alapján jó feltűnő írást kellene közzé tenni a repok használatával kapcsolatban. Nemrégiben olvastam valakitől egy írást a repok prioritását illetően, amivel előtte nyilvánosan sehol nem találkoztam. Esetleg egy ilyen figyelmeztetést be lehetne tenni a YaST megfelelő moduljába.
Nem hiszem hogy a mi feladatunk szolni az intergritas javitasarol A mi alatt kit értesz? Azt elfogadom, hogy az openSUSE fejlesztőknek nem feladatuk, de nem is érdekük? Na és a projekt mögött álló Novell-nek?
Ebben egyetértek, viszont akkor a KDE4 esetében erősen felmerül a Novell/openSUSE csapat felelőssége. Ez nem a mi teruletunk szinten. Amennyiben? Az openSUSE fejlesztők döntöttek úgy, hogy egy olyan grafikus felületet neveznek ki alapértelmezettnek, ami a megelőző verzió töredékét sem nyújtja.
tudatositani kell az emberekben es a kiskereskedokben is. a nagykereskedelmet (pl. mediamerkt) ez nem erdekli Tévedésben vagy. Az említett mutinacionális cég ugyanolyan kiskereskedő, mint a sarki számtech bolt, csak több alkalmazottal. Amúgy nem lesz könnyű feladat még a kiskereskedőkkel sem megértetni.
Szerintem a Novell felügyelete mellett lehetne találni rá embereket a közösségből. igen, csak nem tudjuk, hogy technikaliag hogyan mukodik ez openSUSE-n Mit értesz az alatt, hogy technikailag?
jókat: .~. /V\ /( )\ Zsiráf ^^ ^^ openSUSE 11.1 / 2.6.27.7 / KDE 4.2.4 / OpenOffice.org 3.1.0
a közösségé, akik segítenek azoké... Hm. Nos akkor talán a tapasztalatok alapján jó feltűnő írást kellene közzé tenni a repok használatával kapcsolatban. Nemrégiben olvastam valakitől egy írást a repok prioritását illetően, amivel előtte nyilvánosan sehol nem találkoztam.
igen, erre van szükség
Esetleg egy ilyen figyelmeztetést be lehetne tenni a YaST megfelelő moduljába.
ilyen már most is van. a megfelelő közsségi repokat kulon lehet feltenni.
Nem hiszem hogy a mi feladatunk szolni az intergritas javitasarol A mi alatt kit értesz? Azt elfogadom, hogy az openSUSE fejlesztőknek nem feladatuk, de nem is érdekük? Na és a projekt mögött álló Novell-nek?
feladatuk és érdekük, de én nem vagyok openSUSE fejlesztő és itt a novellt sem képviselem. A Novell egyre inkább nem szól bele a fejlesztésbe, hiszen emiatt amugy is sokan tamadjak. Teljesen kulon emberek fejlesztik az SLE és az open vonalat. a ketto egymástól átvesz dolgokat, de mivle mindket disztronak mas a celkozonsege ezert nem szol bele. A Novell anyagilag támogatja a projektet, de fejlesztesi iranyvonalak nincsen nala.
Ebben egyetértek, viszont akkor a KDE4 esetében erősen felmerül a Novell/openSUSE csapat felelőssége. Ez nem a mi teruletunk szinten. Amennyiben? Az openSUSE fejlesztők döntöttek úgy, hogy egy olyan grafikus felületet neveznek ki alapértelmezettnek, ami a megelőző verzió töredékét sem nyújtja.
ezt a project listan lehet megbeszelni, itt nem ez a feladat. aki segiteni akar nekik vagy biralni akarja oket az megtejeti az adott helyen. Itt abbol kell epitkezni, amit a projekt ad.
tudatositani kell az emberekben es a kiskereskedokben is. a nagykereskedelmet (pl. mediamerkt) ez nem erdekli Tévedésben vagy. Az említett mutinacionális cég ugyanolyan kiskereskedő, mint a sarki számtech bolt, csak több alkalmazottal. Amúgy nem lesz könnyű feladat még a kiskereskedőkkel sem megértetni.
Nem vagyok tevedesben es gondold at melott ilyet jelentesz ki. Nem veletlenul irtam amit irtam.
Szerintem a Novell felügyelete mellett lehetne találni rá embereket a közösségből. igen, csak nem tudjuk, hogy technikaliag hogyan mukodik ez openSUSE-n Mit értesz az alatt, hogy technikailag?
A teszteles technikai folyamat. k
Ha nem csal a szemem, 2009. július 25. szombat keltezéssel Kálmán Kéménczy alábbiakat küldte drótpostán:
Esetleg egy ilyen figyelmeztetést be lehetne tenni a YaST megfelelő moduljába. ilyen már most is van. a megfelelő közsségi repokat kulon lehet feltenni. Nem nincs. Egész egyszerűen csak külön választhatók ki a közösségi telepítési források. Én valami olyasmire gondoltam, mint amit akkor dob, ha a Rendszer- Particionálás modult választod.
feladatuk és érdekük, de én nem vagyok openSUSE fejlesztő és itt a novellt sem képviselem. Akkor ez egy nagyon faramuci helyzet.
ezt a project listan lehet megbeszelni, itt nem ez a feladat. aki segiteni akar nekik vagy biralni akarja oket az megtejeti az adott helyen. Itt abbol kell epitkezni, amit a projekt ad. Részemről nem bírálat volt, csak rámutattam egy fogyatékosságra, ami miatt szerintem elveszthet "híveket" az openSUSE. Gondolom van valamilyen szintű átjárás a két lista között.
Nem vagyok tevedesben es gondold at melott ilyet jelentesz ki. Nem veletlenul irtam amit irtam. Nagyon átgondoltam és tisztában vagyok vele. Nagykereskedő akkor lenne, ha ő szolgálná ki a sarki számtech boltokat, de nem így van. A "hülye azért nem vagyok" típusú áruházláncok kiskereskedelmi boltnak minősülnek, mert a végfelhasználóknak adnak el. Az más kérdés, hogy a mögöttük lévő anyagi bázis és bolthálózat révén milyen piaci részesedést érnek el.
igen, csak nem tudjuk, hogy technikaliag hogyan mukodik ez openSUSE-n A teszteles technikai folyamat. Evvel tisztában vagyok. ;-)
jókat: .~. /V\ /( )\ Zsiráf ^^ ^^ openSUSE 11.1 / 2.6.27.7 / KDE 4.2.4 / OpenOffice.org 3.1.0
Esetleg egy ilyen figyelmeztetést be lehetne tenni a YaST megfelelő moduljába. ilyen már most is van. a megfelelő közsségi repokat kulon lehet feltenni. Nem nincs. Egész egyszerűen csak külön választhatók ki a közösségi telepítési források. Én valami olyasmire gondoltam, mint amit akkor dob, ha a Rendszer- Particionálás modult választod.
azt a projekt listan kell feldobni, kivul esik ezen a hataskoron.
feladatuk és érdekük, de én nem vagyok openSUSE fejlesztő és itt a novellt sem képviselem. Akkor ez egy nagyon faramuci helyzet.
miert is?
ezt a project listan lehet megbeszelni, itt nem ez a feladat. aki segiteni akar nekik vagy biralni akarja oket az megtejeti az adott helyen. Itt abbol kell epitkezni, amit a projekt ad. Részemről nem bírálat volt, csak rámutattam egy fogyatékosságra, ami miatt szerintem elveszthet "híveket" az openSUSE. Gondolom van valamilyen szintű átjárás a két lista között.
ez szinten a projekt listan kell megtenni
Nem vagyok tevedesben es gondold at melott ilyet jelentesz ki. Nem veletlenul irtam amit irtam. Nagyon átgondoltam és tisztában vagyok vele. Nagykereskedő akkor lenne, ha ő szolgálná ki a sarki számtech boltokat, de nem így van. A "hülye azért nem vagyok" típusú áruházláncok kiskereskedelmi boltnak minősülnek, mert a végfelhasználóknak adnak el. Az más kérdés, hogy a mögöttük lévő anyagi bázis és bolthálózat révén milyen piaci részesedést érnek el.
meg egy sor dolgot nem veszel figyelembe
igen, csak nem tudjuk, hogy technikaliag hogyan mukodik ez openSUSE-n A teszteles technikai folyamat. Evvel tisztában vagyok. ;-)
akkor mi nem volt vilagos? k
On Sat, 25 Jul 2009 20:42:23 +0200, Zsiráf
Nem vagyok tevedesben es gondold at melott ilyet jelentesz ki. Nem veletlenul irtam amit irtam. Nagyon átgondoltam és tisztában vagyok vele. Nagykereskedő akkor lenne, ha ő szolgálná ki a sarki számtech boltokat, de nem így van. A "hülye azért nem vagyok" típusú áruházláncok kiskereskedelmi boltnak minősülnek, mert a végfelhasználóknak adnak el. Az más kérdés, hogy a mögöttük lévő anyagi bázis és bolthálózat révén milyen piaci részesedést érnek el.
Szerintem nem a szavakon kéne lovagolni. Két, egymástól teljesen eltérő üzleti modellről van szó, és bár mindkettő végfelhasználóknak ad el, mégis teljesen másról beszélünk. Ezt csak az nem érti, aki nem akarja. Bár ez már nem tartozik a listához... Üdv. András
Ha nem csal a szemem, 2009. július 25. szombat keltezéssel Andras Dosztal alábbiakat küldte drótpostán: Hali!
Szerintem nem a szavakon kéne lovagolni. Két, egymástól teljesen eltérő üzleti modellről van szó, és bár mindkettő végfelhasználóknak ad el, mégis teljesen másról beszélünk. Ezt csak az nem érti, aki nem akarja. Nem a szavakon lovaglás. Van jelentősége annak, amit Kálmán írt, csak nem abban a formában, ahogy ő gondolta. Egyébként, ha valaki, akkor én valóban tisztában vagyok vele, hogy mi a különbség és szerintem elsődlegesen nem a kiskereskedőket kellene megcélozni egy ilyen "kampánnyal".
jókat: .~. /V\ /( )\ Zsiráf ^^ ^^ openSUSE 11.1 / 2.6.27.7 / KDE 4.2.4 / OpenOffice.org 3.1.0
Szia ! 2009. július 25. dátummal Kálmán Kéménczy ezt írta:
de valószínű egy megfelelő prioritásbeállítás kell csak.
És az egyes csomag-tárhelyekről honnan tudunk olyan információt kapni amely alapján eldönthető, melyik tárhely mekkora prioritást kapjon ? Azaz valóban hasznos lenne tudni, mely tárhelyek azok, melyek általában problémásak lehetnek. Így ezek alacsony prioritást kapnának és csak akkor használja a telepítő ha másutt nincs meg a kérdéses csomag. A SUSE kézikönyvben szó van róla ami javasolja is a prioritás-beállítást. Ezzel nyilván jó pár problémát kiküszöbölhetnénk. Üdv : <txtch>
txtch írta:
Szia !
2009. július 25. dátummal Kálmán Kéménczy ezt írta:
de valószínű egy megfelelő prioritásbeállítás kell csak.
És az egyes csomag-tárhelyekről honnan tudunk olyan információt kapni amely alapján eldönthető, melyik tárhely mekkora prioritást kapjon ? Azaz valóban hasznos lenne tudni, mely tárhelyek azok, melyek általában problémásak lehetnek. Így ezek alacsony prioritást kapnának és csak akkor használja a telepítő ha másutt nincs meg a kérdéses csomag.
A SUSE kézikönyvben szó van róla ami javasolja is a prioritás-beállítást.
Ezzel nyilván jó pár problémát kiküszöbölhetnénk.
Üdv : <txtch>
Szia ! Én ezt több éves tapasztalattal állítottam be idáig... Nagyon sok hasznos és jól működő packman csomagot találtam. Felvettem a a KDE közösséget is és a KDE frissítések valamint a KDE 3.5.x repot is. Eddig, ha ezek közül valahol volt újabb verzió egy csomagból azt simán frissítette hiszen egyszer volt jelen. A káosz akkor kezdett eluralkodni amikor p.l. a digikam és a KDE3-digikam külön programként szerepelt, hurrá ! Magyarán kétszer is felrakhattad, ha akartad, de ha az egyik repot kivetted, akkor más programokat nem találsz meg. OK lemondok a megszokott reporól... Csakhogy a KDE3-digikam akármiért elszállt...stb nem folytatnám milyen anomáliákat okozott. De végül néhány program lelakatolásával "rend lett", Valahogy jó lenne ezeken a megmagyarázhatatlan dolgokon átlátható egységet alkotni. Lenne a FŐ telepítési forrás, a LICENCES szoftverek MEGHAJTÓPROGRAMOK a YOU és az e g y é r t el m ű szabályra építkező opensuse-közösség. Nem tudom elképzelni, hogy ez az elvárás feloldhatatlan ellentéteket képezne . -- Üdv: Karesz _____________________ www.kareszka.hu
2009. július 25. dátummal Szágyi Károly ezt írta:
txtch írta:
Szia !
2009. július 25. dátummal Kálmán Kéménczy ezt írta:
de valószínű egy megfelelő prioritásbeállítás kell csak.
És az egyes csomag-tárhelyekről honnan tudunk olyan információt kapni amely alapján eldönthető, melyik tárhely mekkora prioritást kapjon ? Azaz valóban hasznos lenne tudni, mely tárhelyek azok, melyek általában problémásak lehetnek. Így ezek alacsony prioritást kapnának és csak akkor használja a telepítő ha másutt nincs meg a kérdéses csomag.
A SUSE kézikönyvben szó van róla ami javasolja is a prioritás-beállítást.
Ezzel nyilván jó pár problémát kiküszöbölhetnénk.
Üdv : <txtch>
Szia !
Én ezt több éves tapasztalattal állítottam be idáig... Nagyon sok hasznos és jól működő packman csomagot találtam. Felvettem a a KDE közösséget is és a KDE frissítések valamint a KDE 3.5.x repot is. Eddig, ha ezek közül valahol volt újabb verzió egy csomagból azt simán frissítette hiszen egyszer volt jelen.
A káosz akkor kezdett eluralkodni amikor p.l. a digikam és a KDE3-digikam külön programként szerepelt, hurrá ! Magyarán kétszer is felrakhattad, ha akartad, de ha az egyik repot kivetted, akkor más programokat nem találsz meg. OK lemondok a megszokott reporól... Csakhogy a KDE3-digikam akármiért elszállt...stb nem folytatnám milyen anomáliákat okozott. De végül néhány program lelakatolásával "rend lett", Valahogy jó lenne ezeken a megmagyarázhatatlan dolgokon átlátható egységet alkotni.
Lenne a FŐ telepítési forrás, a LICENCES szoftverek MEGHAJTÓPROGRAMOK a YOU és az e g y é r t el m ű szabályra építkező opensuse-közösség. Nem tudom elképzelni, hogy ez az elvárás feloldhatatlan ellentéteket képezne .
Szia ! Igen és ez egy sarkalatos pontja a használhatósági minőségnek. Ez alatt azt értem, hogy ha egy újonnan SUSE-ra áttért felhasználó/számítástechnikus belefut ilyesmikbe akkor 1./ vagy addig babrál vele míg a neki megfelelő nem lesz 2./ vagy elmegy a kedve a rendszertől és mind ez, ""csak"" egy a bosszantó zavar miatt. Azaz a SUSE mint rendszer valóban nagyon jó, de ha ilyesmi probléma keletkezik akkor ez elrontja a használhatóságot, mivel ez más esetben is bármikor előállhat. Pl amit írtál az egy Linux-ban kezdő számára nagyon nagy probléma lenne, ha mégsem akkor is bosszantó. Magam részéről mázlista vagyok. Nekem alig voltak repók által okozott gondjaim, de persze bármikor lehetnek. És ami talán -- illetve talán éppen ezért nem voltak -- szerencse, maradtam a 11.0-nál és a már réginek számító KDE 3.5.9 -nél. Hümm... a KDE 3 -és KDE 4 programok.... :-) Mikor megjelent és feltelepítettem -- már jó régen -- a 11.0-t meglepett számos hiba, működési zavarok, stb... a KDE 4-ben. Úgy döntöttem, hogy maradok a régi KDE-nél, e szerint is válogattam a "dolgokat". Egyébként nagyon kíváncsi vagyok milyen lesz a 11.2 és benne az újabb KDE. :-) Üdv : <txtch>
És ami talán -- illetve talán éppen ezért nem voltak -- szerencse, maradtam a 11.0-nál és a már réginek számító KDE 3.5.9 -nél.
Nekem is már csak 2 gépet kell downgrade-elni 11.0 3.5.9-re ebből az egyik egy mobilnetes gép és már nem emlékszem hogyan hegesztettem meg működőképesre :)
Egyébként nagyon kíváncsi vagyok milyen lesz a 11.2 és benne az újabb KDE. :-)
Részemről nagyon várom a 4.3-as KDE-t várhatóan végre összeáll. -- Üdv: Karesz _____________________ www.kareszka.hu
Ugyanez jutott ma eszembe. Valami olyasmire gondoltam, hogy az
opensuse.hu-n lenne egy magyar hibabejelentő, aminek a bejelentéseit
megkapja levélben egy adott csoport, és ők (mi) bejelent(ik/jük) a hibát.
Nagyjából hasonló felépítést kéne csinálni, mint a Novell bugzillán:
- Verzió (a Product Line-t kihagyhatjuk, itt csak opensuse lesz)
- Komponenes
- HW platform
- Tárgy
- Leírás
- Reprodukálhatóság
- Hogyan reprodukálható?
- Milyen eredmény született?
- Milyen eredményt vártál?
- Csatolmány
- Egyéb információ
A kérdés, hogy egy ilyen kérdőívet - még ha magyarul is van - hányan
képesek és hajlandók kitölteni. Pl. egy kezdő felhasználó nem tudja, hogy
az adott hibát a Gnome vagy a Firefox okozza, ezért nem lesz tsztában
azzal, melyik komponenst jelölje meg.
Ki kéne találni, hogy melyik mező legyen kötelező és melyik opcionális.
Üdv.
András
On Tue, 21 Jul 2009 20:59:11 +0200, Tamas Sarga
Sziasztok!
Az "Ez is egy vélemény" szál olvasásakor jutott eszembe egy ötlet. Felmerült a tud angolul, írjon bug reportot dolog, illetve a magyar hibabejelentő rendszer.
participants (9)
-
Andras Dosztal
-
Bognár Sándor
-
Kálmán Kéménczy
-
Kálmán Kéménczy
-
Nagy Tibor
-
Szágyi Károly
-
Tamas Sarga
-
txtch
-
Zsiráf