Java má dnes 30. narozeniny. Veřejnosti byla představena 23. května 1995.
1. července Mozilla vypne službu Fakespot pro detekci podvodných recenzí v internetových obchodech. Mozilla koupila Fakespot v květnu 2023.
8. července Mozilla vypne službu Pocket (Wikipedie) pro ukládání článků z webu na později. Do 8. října si uživatelé mohou vyexportovat data. Mozilla koupila Pocket v únoru 2017. Několik měsíců byl Pocket integrovanou součástí Firefoxu.
Turris OS má aktuálně problém s aktualizací související s ukončením podpory protokolu OCSP u certifikační autority Let's Encrypt.
Nevidomý uživatel Linuxu v blogu upozornil na tristní stav přístupnosti na linuxovém desktopu (část první, druhá, závěr), přičemž stížnosti jsou podobné jako v roce 2022. Vyvolal bouřlivou odezvu. Následně např. Georges Stavracas shrnul situaci v GNOME. Debata o jiném aspektu přístupnosti, emulaci vstupu pod Waylandem, také proběhla na Redditu.
DevConf.CZ 2025, tj. open source komunitní konference sponzorovaná společností Red Hat, proběhne od 12. do 14. června v Brně na FIT VUT. Publikován byl program a spuštěna byla registrace.
Byla vydána nová major verze 28.0 programovacího jazyka Erlang (Wikipedie) a související platformy OTP (Open Telecom Platform, Wikipedie). Přehled novinek v příspěvku na blogu.
Český telekomunikační úřad zveřejnil Výroční zprávu za rok 2024 (pdf), kde shrnuje své aktivity v loňském roce a přináší i základní popis situace na trhu. Celkový objem přenesených mobilních dat za rok 2024 dosáhl dle odhadu hodnoty přibližně 1,73 tis. PB a jeho meziroční nárůst činí zhruba 30 %. Průměrná měsíční spotřeba dat na datovou SIM kartu odhadem dosáhla 12,5 GB – v předchozím roce šlo o 9,8 GB.
Z novinek představených na Google I/O 2025: Přehledy od AI (AI Overviews) se rozšiřují do dalších zemí. Užitečné, syntetizované přehledy od generativní AI jsou nově k dispozici i českým uživatelům Vyhledávače.
Šestice firem označovaných jako „MAMAAN“ – tedy Meta (Facebook, Instagram), Alphabet (Google), Microsoft, Apple, Amazon a Netflix – je zodpovědná za více než padesát procent světového internetového provozu. Dalšími velkými hráči jsou TikTok a Disney+. Společně tak zásadně určují podobu digitálního prostředí, spotřebitelského chování i budoucích trendů v oblasti technologií. I přesto, že se podíl těchto gigantů od roku 2023 o něco snížil, jejich dominantní postavení zvyšuje volání po regulaci.
Greg Kroah-Hartman se rozhodl ignorovat oficiální bugzillu linuxového jádra. Uzavřel 160 nahlášených chyb souvisejících s USB podsystémem s tím, že tyto chyby patří do diskusního listu linux-usb@vger.kernel.org a pokud nebyly doteď vyřešeny, je potřeba je tam přeposlat. Klasické diskusní listy mu vyhovují více než bugzilla.
Tiskni
Sdílej:
23.2.2012 11:02
Bedňa | skóre: 34
| blog: Žumpa
| Horňany
Na mailing listech je to lepsi tam my aspon odpovedi - i kdyz "hochu jestli chces prispivat tak musis podle nas a o tohle nemame zajem" (k*rva ja nechci prispivat a honit si ego ze jsem OSS ninja - ja chci aby to fungovalo!!)
Jo a IRC ... kde reknu spravcovi "cau" a chci s nim poresit bug co jsem nahlasil v bugzille a on mi ani neodpovi tak si rikam ze tam neni a pak se zacne bavit s nekym jinym. Takhle funguje kolaborace v OSS - btw vyvojari ten bug pak asi po mesici samy patchnulu a uzavreli.
(a mimochodem vyvojaru co si takto stezuje na urcite OSS projekty je plno ale jmenovat nebudu)
Mam dojem, ze se panove snazi nejak ospravedlnit, ze se jim ty bugy proste nechce resit.Taky mám ten dojem. Tohle je "řešení" typu hurá zpět na stromy.
23.2.2012 13:13
Nikola Ciprich | skóre: 23
| blog: NiX_blog
| Palkovice
A kecy o "Čo si spravil pre slovenský hip-hop? Jaký prínos do hip-hopu?" si laskavě nech.Ty kecy by byly irelevantní v případě slovenského hip-hopu. Jenže GK-H je významný vývojář Linuxu. Pokud nejsi taky, tak proč by měl někdo dát na tvoje kydy, jak se má při vývoji Linuxu postupovat?
24.2.2012 12:39
pavlix | skóre: 54
| blog: pavlix
Ty kecy by byly irelevantní v případě slovenského hip-hopu. Jenže GK-H je významný vývojář Linuxu. Pokud nejsi taky, tak proč by měl někdo dát na tvoje kydy, jak se má při vývoji Linuxu postupovat?Ty kecy jsou přinejmenším irelevantní, pokud ty sám nejsi významným vývojářek kernelu :).
24.2.2012 16:24
Stanislav Brabec | skóre: 45
| Praha
Třeba má nějaký nástroj, který mu mejly převede do nějakého interního todo seznamu, co já vím.Jasně, že má:
git-am -i /var/spool/mail/gregkh
Averzi k bugzille nechápu, osobně o ničem lepším nevím. Samozřejmě pro malé projekty je to jako jít s kanónem na komára, tak výborně poslouží např. ten Trac.
Trac mi přijde pochopitelný i pro normální lidi.
Problém není v bugzille jako v nástroji, ale v obsahu té bugzilly. Problém je právě v principu, že každý bugreport je zachován na věky a nezmizí, dokud někdo z vývojářů nesedne a něco s ním neudělá - bez ohledu na to, jestli reportera vůbec ještě zajímá. Na první pohled to zní jako super myšlenka, ale bohužel jen do chvíle, než se podíváte, jak to funguje v praxi. U rozsáhlejších open source projektů jsou výsledkem desetitisíce až statisíce nahlášených bugů, z nichž smysl má tak desetina (a to se obávám, že jsem ještě příliš velký optimista). Většina bugreportů jsou buď úplné nesmysly, duplikáty nebo hlášení, která možná popisují skutečný problém, ale tak, že jsou stejně bez delšího výslechu nepoužitelná. Pokud budeme trvat na tom, že ke každému takovému reportu musí bezpodmínečně sednout vývojář a řešit ho, výsledkem bude smrt projektu, protože vývojář pak nebude dělat nic jiného než tuhle úředničinu.
Neříkám, že se mi líbí, jak se k tomu problému Greg postavil, nebo že znám lepší řešení (myšlenka spoléhat se jen na mailing listy se mi taky nelíbí), ale nebylo by poctivé namlouvat si, že problém neexistuje. A podívám-li se do té diskuse a přečtu-li si, co napsali Dave Miller nebo Neil Brown, je to přinejmenším námět k zamyšlení, který si netroufnu šmahem odbýt nějakou urážkou, jak to udělala většina zdejších diskutujících. Další námět k zamyšlení je skutečnost, že bugzilla.kernel.org byla několik měsíců mimo provoz a nevypadalo to, že by nějak zvlášť chyběla; vývoj jádra pokračoval dál (a pokud byly nějaké problémy, tak spíš kvůli výpadkům gitových repozitářů) a žádný dramatický nárůst chyb se také nekonal.
Problém je právě v principu, že každý bugreport je zachován na věky a nezmizí, dokud někdo z vývojářů nesedne a něco s ním neudělá - bez ohledu na to, jestli reportera vůbec ještě zajímá.Patrně se vychází z toho, že problém obvykle sám od sebe nezmizí, což mi přijde jako rozumná myšlenka?
Ostatně, vyřešení problému snad má smysl i pro ostatní, nejen pro toho, kdo ho nahlásil? Já teda hlásím i bugy, které náhodně objevím a nijak mě nepálí, protože danou věc zase dalších pět let nepoužiju... Jistě je kernel specifický v tom, že závažnost bugů se může sama od sebe snižovat např. s tím, jak odpadá výskyt HW, který je chybou postižen. Nicméně i v tom případě by snad měli smysl chybu někde alespoň zdokumentovat (errata), když už není zájem/čas ji opravit - a poté příslušné hlášení zavřít jako WONTFIX.
Většina bugreportů jsou buď úplné nesmysly, duplikáty nebo hlášení, která možná popisují skutečný problém, ale tak, že jsou stejně bez delšího výslechu nepoužitelná.RESOLVED INVALID/DUPLICATE/NEEDINFO?
Pokud budeme trvat na tom, že ke každému takovému reportu musí bezpodmínečně sednout vývojář a řešit ho, výsledkem bude smrt projektu, protože vývojář pak nebude dělat nic jiného než tuhle úředničinu.
Další námět k zamyšlení je skutečnost, že bugzilla.kernel.org byla několik měsíců mimo provoz a nevypadalo to, že by nějak zvlášť chyběla; vývoj jádra pokračoval dál (a pokud byly nějaké problémy, tak spíš kvůli výpadkům gitových repozitářů) a žádný dramatický nárůst chyb se také nekonal.Pokud většina kernel bugzilly "funguje" tak, jako v případě GKH, tak skutečně asi příliš nikomu nechybí. Tedy, ne že by ty chyby samy od sebe zmizely, ale lidi asi rezignovali? Víte, můj dojem z toho je, že evidentně kernelu chybí někdo, jehož hlavní náplní práce by byla právě ta bugzilla a s tím související otravování jak toho, kdo problém nahlásil, aby poskytnul potřebné informace, tak vývojářů, aby s těmi informace, když už jsou k dispozici, něco dělali - ne aby ten bug roky hnil, až vyhnije.
Víte, můj dojem z toho je, že evidentně kernelu chybí někdo, jehož hlavní náplní práce by byla právě ta bugzilla a s tím související otravování jak toho, kdo problém nahlásil, aby poskytnul potřebné informace, tak vývojářů, aby s těmi informace, když už jsou k dispozici, něco dělali - ne aby ten bug roky hnil, až vyhnije.
(a samozřejmě i předběžné vyhodnocování priority bugů) Jistě, to je jedno z možných řešení, obvyklé třeba u komerčních systémů. Tady by to rozhodně nebyla práce pro jednoho člověka, ale spíš pro celý tým. Takže se nabízejí dvě otázy: (1) Našlo by se dost lidí ochotných takovou (ne zrovna povznášející) práci dělat? (2) Našel by se někdo, kdo by takový tým zaplatil?
s člověkem zdiskutují možné cesty opravy a požádají jej o patch. Takže bug reporter musí zapojit i sebe, což mi přijde správné. Navíc se sám něco naučí a příště možná rovnou sám opraví něco jednoduchého a rovnou pošle patch.Aha, rozumím. Co reportér bugu, to programátor. Co myslíte, jak dopadne autoservis, kde se zákazníkem "zdiskutují možné cesty opravy" a pak ho pošlou s autem domů, ať si to opraví sám a s takovou pitomostí je vůbec neotravuje?
Ale no tak, o nějakém "muset poslat patch" nebyla řeč. Psal jsem, že je požádán, aby poslal patch a že musí zapojit své úsilí. Pokud je patch nad jeho síly, vysvětlí a opravy se může ujmout někdo třetí. Ale ten reporter musí poslat relevantní informace a pak to především otestovat, protože je to pro jeho HW, který většinou zrovna těch pár relevantních lidí nemá. Takže se bude většině případů muset naučit aspoň zkompilovat git verzi ovladačů, což jsou všehovšudy tři příkazy. Bugfix něčeho netriviálního bez předchozího otestování na příslušném HW správce alsy do hlavní větve samozřejmě nepřijme. A od toho ten mailing list je, že příslušní lidé a hlavně hlavní správci průběžně vidí, co se zrovna řeší, a mohou zareagovat, když mají něco k věci.hm, pěkný traktátek, ale až pocaď irelevantní, protože to samé platí pro bugzillu
Bugzilla je na takové sledování, co se zrovna děje, daleko nepohodlnější a nedivím se, že ji ti klíčoví vývojáři nepoužívají.nu a tady máme to jádro sporu Běžného Frantu Uživatele absolutně nezajímá co se právě děje - jeho zajímá vlastní práce/zábava a to, jestli je ta otravná blbost, co mu v té vlastní činnosti brání, už spravená nebo ne na co se přihlašovat do nějakého mailinglistu, ze kterého bude chodit tuna spamu a jen nějaká ubohá tisícina promile se bude týkat toho konkrétního problému, a po jeho vyřešení se zase odhlašovat? a s Běžným Frantou Uberbaličem je to to samý v bleděmodrým - jeho též nezajímá, co se kde v projektu šustne, nemá čas to číst, protože mezitím potřebuje dělat na N dalších balíčkách, jeho zajímá tak nanejvejš nějakej -announce list, když vyjde nová verze, aby věděl, že ji má přebalit z opačné strany to ovšem problém není, nikdo nebrání develům dohodnout se, že si maily z bugzilly nechají posílat do svého skvělého mailinglistu, et vice versa, existují rozhraní v opačném směru, čili devel se uživatele na jeho bug (na ty relevantní informace & whatever) může zeptat ve svém oblíbeném mailinglistu, a uživateli to do té bugzilly probublá
Prostě si to chce vyzkoušet, zapojit se do nějakého takového projektu a pak to člověk vidí z praktické perspektivy reálného života projektu.ano, prostě si to chce někdy vyzkoušet ... zkus se takto aktivně zapojit nejen do té své alsy, ale do každého projektu, kde bys rád viděl nějakou opravu
Běžného Frantu Uživatele absolutně nezajímá co se právě děje - jeho zajímá vlastní práce/zábava a to, jestli je ta otravná blbost, co mu v té vlastní činnosti brání, už spravená nebo ne na co se přihlašovat do nějakého mailinglistu, ze kterého bude chodit tuna spamu a jen nějaká ubohá tisícina promile se bude týkat toho konkrétního problému, a po jeho vyřešení se zase odhlašovat? a s Běžným Frantou Uberbaličem je to to samý v bleděmodrým - jeho též nezajímá, co se kde v projektu šustne, nemá čas to číst, protože mezitím potřebuje dělat na N dalších balíčkách, jeho zajímá tak nanejvejš nějakej -announce list, když vyjde nová verze, aby věděl, že ji má přebalitJuchuuuu! Konečně to někdo pochopil!
Jdu si dát pivo!
Já když si v krámě koupím nepoživatelné jídlo, tak …
Vy vývojářům jádra něco platíte?
O tom to snad není?!
Obávám se že je. Vztah mezi platícím zákazníkem a dodavatelem produktu je úplně jiný než vztah mezi uživatelem volně dostupného open source projektu a jeho vývojáři.
Pokud vývojáře hlášení chyb nezajímá, ať to laskavě sdělí narovinu.
Celou dobu se tu - asi marně - snažím vysvětlit, že problém není v tom, že by vývojáře bugreporty nezajímaly. Problém je v tom, že systém, jako je bugzilla, s sebou nese určitou režii a že tato režie je za určitých okolností (jako třeba právě u linuxového jádra) neúnosná.
Celou dobu se tu - asi marně - snažím vysvětlit, že problém není v tom, že by vývojáře bugreporty nezajímaly. Problém je v tom, že systém, jako je bugzilla, s sebou nese určitou režii a že tato režie je za určitých okolností (jako třeba právě u linuxového jádra) neúnosná.Pro mne jako uživatele je to, obávám se, v důsledku naprosto stejné, čili pro mne nezájem. Provoz na těch mailing listech je z hlediska toho, že tam jednou do roka nahlásím chybu, jednoduše naprosto neakceptovatelný. Potřeba vývojářů vyžvaňovat se v rámci workflow na ML se dá - jak již bylo řečeno - snadno řešit posílám komentářů z bugzilla do onoho mailing listu přes CC, i zpětná odezva je možná (mailing list => bugzilla). Ale brodit se kvůli opravě chyby v tisících mailů, které mne vůbec nezajímají, to fakt nebudu.
- sakra takovahle argumentace tady nema co delat - to jako protoze to je volne dostupny open source tak to muze stat za h****?
nakonec se rozhodneš vzít poloviční úvazek tam i tam, jenomže narazíš, neb zjistíš, že den má pouze 24 hodin, které máš díky předchozím třem zaměstnáním plně využité, neb 3*8 = 24Easy, nechá se zaměstnat jako astrolog a provede a prosadí výzkum na to, že den má vlastně 72 hodin. Problem solved :)
Ten mailinglist není placený autoservis.
Když se ti to nelíbí, procházej alsí bugzillu a reportuj do mailinglistu. Nebo někoho takového zaplať. Nikomu se nebrání přiložit ruku k dílu.
Problém není v bugzille jako v nástroji, ale v obsahu té bugzilly. Problém je právě v principu, že každý bugreport je zachován na věky a nezmizí, dokud někdo z vývojářů nesedne a něco s ním neuděláchyba v předpokladu ten report nezmizí ani potom - pouze se zavře ... a to je právě jedna z těch krásných vlastností toho principu (ano, ta historie se dost často hodí)
- bez ohledu na to, jestli reportera vůbec ještě zajímá. Na první pohled to zní jako super myšlenka, ale bohužel jen do chvíle, než se podíváte, jak to funguje v praxi. U rozsáhlejších open source projektů jsou výsledkem desetitisíce až statisíce nahlášených bugů, z nichž smysl má tak desetina (a to se obávám, že jsem ještě příliš velký optimista). Většina bugreportů jsou buď úplné nesmysly, duplikáty nebo hlášení, která možná popisují skutečný problém, ale tak, že jsou stejně bez delšího výslechu nepoužitelná.ok, a jak se to liší od situace, kdy se reporty místo do bugzilly budou posílat do nějakého mailinglistu? je bariéra registrace v mailinglistu o tolik vyšší než bariéra registrace v bugzille, takže tam budou posílat maily pouze lidé vysoce inteligentní se spoustou volného času, kteří problém dokážou krásně popsat a nejlépe i vyřešit a jen poslat patch k začlenění?
Pokud budeme trvat na tom, že ke každému takovému reportu musí bezpodmínečně sednout vývojář a řešit ho, výsledkem bude smrt projektu, protože vývojář pak nebude dělat nic jiného než tuhle úředničinu.viz výše, a jak se to liší od situace, kdy bychom trvali, že má vývojář bezpodmínečně sednout ke každému mailu a řešit ho? - jinak tedy krásný argumentační úkrok ... například proto, že značnou část této vývojářské práce mohou řešit (a často řeší) roboti, jako třeba zjištění, jestli je bugreport po nějaké době ještě platný (a reportér má zájem na jeho řešení) ostatně protipříkladem, že výše uvedené není pravda, jest například to, že RHEL ještě nezemřel, přestože se držíme pravidla řešit každý report (přičemž ale připomínám, že řešit != vyřešit ve smyslu spravit)
... ale nebylo by poctivé namlouvat si, že problém neexistuje.a to tady někdo dělá?
A podívám-li se do té diskuse a přečtu-li si, co napsali Dave Miller nebo Neil Brown, je to přinejmenším námět k zamyšlení, který si netroufnu šmahem odbýt nějakou urážkou, jak to udělala většina zdejších diskutujících.pro některé zdejší diskutující je totiž práce s chybami denním chlebem, a více než nějaké pseudoikoně, která si zatím jejich respekt nezískala (byť programátor je to třeba dobrej), ze své vlastní praxe raději věří lidem, kteří se optimalizací příslušných procesů léta zabývají ...
a žádný dramatický nárůst chyb se také nekonal.[Citation needed] - jak jste ten nárůst chyb měřil?
jak se to liší od situace, kdy se reporty místo do bugzilly budou posílat do nějakého mailinglistu?
Tím, že v mailing listu reporty typu "napíšu (neúplný) report a jdu pryč" samy od sebe upadnou v zapomnění.
jak se to liší od situace, kdy bychom trvali, že má vývojář bezpodmínečně sednout ke každému mailu a řešit ho?
To by se moc nelišilo. Takový model ale nikdo nenavrhuje.
ostatně protipříkladem, že výše uvedené není pravda, jest například to, že RHEL ještě nezemřel, přestože se držíme pravidla řešit každý report (přičemž ale připomínám, že řešit != vyřešit ve smyslu spravit)
To není protipříklad, to je úplně jiná situace. RHEL je komerční distribuce, kde bugy reportují platící zákazníci - a jakkoli nevidím do vnitřní politiky Red Hatu, jsem si celkem jistý, že to, jak intenzivně se tím bugem zabýváte, závisí (mimo jiné i) na tom, jaký kontrakt ten zákazník má. To není případ jádra. Nebo se snad pravidlo "snažíme se každý bugreport řešit" vztahuje na cokoli, co napíše do bugzilly kdokoli, kdo si založil účet? Vztahuje se i na Fedoru?
pro některé zdejší diskutující je totiž práce s chybami denním chlebem
Třeba pro mne. :-)
více než nějaké pseudoikoně, která si zatím jejich respekt nezískala
Označit Davida Millera za pseudoikonu, to nemůžu hodnotit jinak než jako projev ignorance.
[Citation needed] - jak jste ten nárůst chyb měřil?
Vážně? Nepřipadá vám tenhle úhybný manévr trochu laciný?
a proč tedy totéž uvádíte proti bugzille?jak se to liší od situace, kdy bychom trvali, že má vývojář bezpodmínečně sednout ke každému mailu a řešit ho?To by se moc nelišilo. Takový model ale nikdo nenavrhuje.
ach ano, jistě - nehodí se to do krámu, tak je to jiná situace ...ostatně protipříkladem, že výše uvedené není pravda, jest například to, že RHEL ještě nezemřel, přestože se držíme pravidla řešit každý report (přičemž ale připomínám, že řešit != vyřešit ve smyslu spravit)To není protipříklad, to je úplně jiná situace.
RHEL je komerční distribuce, kde bugy reportují platící zákaznícizdaleka nejen ti (tedy, chtěli-li bychom být precizní, tak ti právě skoro vůbec, neb "bugzilla is not a support tool" - na to je IT ... tedy, opět, nikoli mailinglist)
- a jakkoli nevidím do vnitřní politiky Red Hatu, jsem si celkem jistý, že to, jak intenzivně se tím bugem zabýváte, závisí (mimo jiné i) na tom, jaký kontrakt ten zákazník má. To není případ jádra.jakože na jádře nepracují placení vývojáři? - že jádro nepoužívají ti, co za jeho vývoj platí?
Nebo se snad pravidlo "snažíme se každý bugreport řešit" vztahuje na cokoli, co napíše do bugzilly kdokoli, kdo si založil účet? Vztahuje se i na Fedoru?ano, a ano (i když u Fedory toho spoustu "vyřeší" roboti ...)
nevím za projev čeho mám označit takovýto trapný pokus o záměnu předmětu - psal zde snad někdo něco urážlivého na adresu Dave Millera, popř. Neila Browna? ... anebo se snad výroky o demenci a aroganci týkaly spíše Grega Kroah-Hartmana?více než nějaké pseudoikoně, která si zatím jejich respekt nezískalaOznačit Davida Millera za pseudoikonu, to nemůžu hodnotit jinak než jako projev ignorance.
za prvé, nepřijde mi to jako úhybný manévr, nýbrž jako validní otázka - mimochodem, věta "Nepřipadá vám tenhle úhybný manévr trochu laciný?" je velmi krásnou ukázkou sloučené otázky a za druhé, nepřijde mi to o nic "lacinější" nežli rádobyargument, na který jsem tím reagoval[Citation needed] - jak jste ten nárůst chyb měřil?Vážně? Nepřipadá vám tenhle úhybný manévr trochu laciný?
Co sa tyka jadra, tak tam nepochybne najviac prace urobili ludia, co Bugzillu nemaju radi.ehm, ehm - psal jsem "jsou ochotni používat", nikoliv "milují" a to tvé "nepochybně" bych si dovolil lehce zpochybnit tím, že pět největších přispěvatelů, kteréžto společnosti bugtracking systémy využívají, dává dohromady přes třetinu práce na kernelu (pročež stačí najít jen 15% z dalších přispěvatelů, abychom se přehoupli přes půlku a "nejvíc" zneplatnili ...)
Bugzilla je dobra tak na sledovanie bugov (resp. ich skladovanie a pozorovanie, ako hniju).výborně, takže aspoň částečně účel bugzilly chápeš ...
Pre jadro je nedostatocna, pretoze komunikacii brani namiesto toho, aby ju podporovala (nutnost registracie, zadavanie cez hrozny web interface, komentare su len linearne - ziadne vlakna).s tou nutností registrace si snad děláš srandu ne? - to můžeš zrovna tak říct, že třeba git brání vývoji, pokud nelze přispívat anonymně bez registrace ... a především, viz co bylo řečeno výše, bugzilla není obecný komunikační nástroj - takže vyčítat jí věci typu že neumí videokonferencing je naprosto zcestné existence záznamu v bugzille nijak neimplikuje, že komunikace musí probíhat právě tam - ale tuto komunikaci velmi usnadňuje tím, že je na co odkázat, záznam má nějakou svoji strukturu, jsou tam přílohy (v mailinglistech často zakázané), dá se sledovat jen ten jeden konkrétní bug (a věci navazující), apod.
viz to Gentoo, za podobny chovani by v kterymkoli tymu i ten nejvetsi borec dostal obratem kick.Takže sice v té době mělo sice Gentoo jako maintainera udev jeho hlavního upstream vývojáře, ale stav udev byl asi nejkatastrofálnější ze všech distribucí. Docela absurdní.
24.2.2012 00:47
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
26.2.2012 22:02
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
Tady vzhledem k tomu ze bugzilla neni "oficialni" bych to i bral.To je pak trochu bordel, ne?
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz