Otvírání otevřeného software

3.1.2012 01:02 | Přečteno: 1755× |

Ač je drtivá většina zápisku o jedné prezentaci a věcech v ní obsažených, hlavní cílem toho zápisku je iniciovat diskuzi, co by podle vás usnadnilo přispívání do open-source software.

Proto, zejména pro ty, co nebudou mít sílu/chuť číst to celé, prvně ony otázky, na které bych vás poprosil odpovědět v diskuzi: Přispíváte do open-source software? Jestli ano, co je pro vás největší opruz, který byste změnili, kdybyste mohli? Jestli nepřispíváte, co je hlavní faktor, který vás od toho odrazuje (když pomineme různé, ať již zástupné nebo skutečné, důvody typu nemám na to čas)? Stalo se vám už někdy, ze jste do OSS nepřispěli jen kvuli tomu, že se vám celý proces zdál přiliš komplikovaný? Zvýšilo by (podstatně) vaši chuť přispívat, kdyby proces vytvoření a odeslání patche byl dostatečně jednoduchý (např. pro vytvoření nové funkce není nutné studovat celý system, ale jen příslušný modul, měli byste automaticky commit práva, pokud by build prošel testy, nová funkce by šla automaticky do dalšího releasu a pod.)?

Různých projektů s otevřeným zdrojovým kódem je nepřeberné množství, takže snad téměř každý si může najít pro něj dostatečně zajímavý projekt, do kterého by mělo smysl přispívat (a pokud takový oprvadu neni, tak je možná na čase, aby jej vytvořil sám . Krom možnosti podílet se na něčem zajímavém (vybrali jste si přece projekt pro vás zajímavý) to má navíc tu výhodu, že daný kus software obvykle používá víc (často velmi mnoho) lidí, takže je to veskrze užitečně strávený čas. V neposlední řadě se často něčemu zajímavému přiučíte. Toto platí zejména pro studenty. Zde bych mohl pokračovat dlouhým výčtem, proč by studenti (různých IT oborů) měli přispívat do open-source, ale to už velmi dobře (rozhodně líp, než bych to zvládnul já) shrnul Sešívaný v článku Proč studenty zapojit do open-source projektu v časopise Open source & praxe (je to úplne poslední článek v tomto čísle). Sám jen poznamenám, že když už různé praktické školy/studijní obory (je podobnost se zvlašními skolami, přejmenovanými na praktické, čistě náhodná? preferují výuku rozličných "předmětů z praxe" před výukou abstrakních nesmyslů (čti ruzných matematických disciplin), nechápu, jak takovou školu může student absolvovat, aniž by přispěl jedinou řádkou do nějakého open-source projektu (u státních škol se divím dvojnásob).

Můžeme se spokojit s odpovědí, že lidi jsou líní a raději berou než dávají a pod. Ač je to odpověď v mnoha případech pravdivá, nejsu si jistý, jestli je zcela uspokojivá. Část důvodů může spočívat v tom, že mnoho projektů s otevřeným zdrojový kódem je otevřených ve smyslu že si kód může každý stáhnout a prostudovat, nicméně ve smyslu možnosti do něj přispět to již zdaleka neni tak triviální. Toto na první pohled vypada logicky. O nemálo lidí se asi pokusí mrkákoty při představě, že by do jejich oblíbeného projektu mohl commitovat kde jaký jouda to, co mu právě přišlo jako docela dobrý nápad. Před nějakým časem jsem ale viděl slidy od Nicolase De Loofa z prezentace Opening opensource the Jenkins way, a od té doby si pohrávám s myšlenkou, že rozdávat commit práva na potkání možná není až tak hloupý nápad, jak se může na první pohled zdát.

Nemá cenu sem opisovat celou prezentaci, kdo chce, ať si to prokliká sám. Hlavní myšlenky jsou přibližně následující. Přispívat do OSS projetu někdy není úplně jednoduché a dostat nějaká práva (např. právo commitu do SCM) je velmi často běh na dlouhou trať, který zahrnuje i hromady dalších věcí jako odpovídání nováčkům na fóru, psaní dokumentace atd., což je pro mnoho lidí (dřív nebo později) vcelku demotivující. Dochází tak ke ztrátě části programátorů, případně daný člověk ani nezačne přispívat. Řešení je vcelku jednoduché a to, jak už asi tušíte, dát prava commitu každému, kdo si o ně řekne. To pochopitelně není celé. Navhuje těchto 6 bodů:

• snížit vstupní bariéru
aneb dát commit práva každému, kdo si o ně řekne,
• provádět často release,
• na nástorojích záleží
aneb přejít ze SVN na git, konkrétně dát zdrojáky na github,
• všechno by mělo být maximálně trasparetní
- pravidla, veškerá rozhodnutí a diskuze, nic by se nemělo řešit privátně (na mailu/ soukromem IRC kanále atd.),
• vybrat si dobrý model pro vedení projektu
- zde je asi spíš myšleno hlavne najít vhodnou osobu/osoby, která bude dostatně technicky zdatná aby mohla vést projekt, intezivně do něj přispívat a zárověň dostatečně sociálně zdatná, aby budovala komunitu kolem projetu (tj. ne egocentrik, ktery se domnívá, že to, co nenapsal on, je špatné),
• navrhnout software tak, aby byl snadno rozšiřitelný
aneb coz nejvíce funkcionality implementovat jako pluginy.

Přispívající by si měli být vědomi, že s velkou mocí přichází i velká odpovědnost, ale zároveň by stále měli mít možnost dát svůj příspěvěk k revizi kódu, kdykoli si nejsou zcela jisti kvalitou kódu.

Jednoduché, ne? Osobně mě ani tak nevadí to, že někde nemám právo commitu, ale docela mi vadí, pokud někam poslu patch a ten tam leží nepovšimnutý, lidi s commit právy daný bug/feature nezajímá nebo zkratka nemají čas a tak to tam leží měsíce. Nejen proto se mi líbí myšlenka snížit stupní bariéru na minimum. Líbí se mi i přístup samotný, kdy komunita kolem takového projektu tím dává vcelku jasně najevo, že si velmi váží každého příspěvku (i za cenu, že to třeba rozbije build) a takto apriori projevená důvěra je, aspoň pro mě, poměrně velkou motivací, abych ji nezklamal a kód před commitem pečlivě otestoval (ideálně i napsal jednotkové testy). Použití distribuovaného verzovacího systemu (jako git), kde se snadno tvoří větve a je možno snadno vybírat do hlavní větve jen jednotlivé commity z větví, usnadní případné opravy a celkově velmi usnadní práci. IMHO jedna z nejdůležitějších věcí je mít dobré pokrytí testy a ideálně po každém commitu je spustit. Takto se případná chyba odhalí velmi rychle. Druhá, neméně důležitá, věc je navrhnout software dostatečně modulárně a s podporou pluginů tak, aby je jedna část šla jednoduše vyměnit za jinou. Je jasné, že dřív nebo později dojde k tomu, že programátor A navrhne a implementuje funkci A, kterou bude považovat za geniální, zatímco progmátor B to bude považovat za naprosté zlo, které je potřeba odstranit a udělat to celé jinak. Pokud ale daná věc půjde implementovat jako plugin, oba dva si to udělají po svém, budou spokojení a uživatel si navíc bude moct vybrat, co se mu líbí víc. Toto navíc umožňuje trochu zmírnit onen radikální princip dát commit právo každému. Pokud se do vašeho projektu budou snadno psát pluginu, pro začátek můžete dávat commit práva jen pro pluginy.

pavlix v diskuzi vedle (která vlastně způsobila, že jsem tenhle zápisek konečně napsal) dodává, že je třeba, aby byl systém snadno testovatelný. To se v oné prezentaci ani nezniňuje, IMHO proto, že to autor považuje za automatické. Např. v při vývoji pluginu pro Jenkins stači v adresáři s pluginem dát mvn hpi:run, což spustí Jetty, provede na něm deploy pluginem požadované verze Jenkins a pluginu samotného a po každém uložení změn provede znovunačtení změn (Jenkins ještě donedávna neuměl hot deploy, takže se to řeší trochu nešikovně restartem Jetty, nicméně to se snad časem zmení, protože AFAIK hot deploy pluginu už je implementovaný).

Popravdě, já sám nejsu úplně přesvědčený a kdybych byl autorem nějakého úspěšného OSS projektu (jako že nejsu), tak bych asi docela přemýšlel, jestli bych do toho šel. Každopádně se mi ta myšlěnka líbí a praxe ukazuje, že to může být velmi úspěšná strategie. Tou praxí myslím projekt Jenkins, což to asi jediný větší projekt, o kterém vím, že se drží výše uvedených pravidel. Já vím, jedna vlaštovka jaro nedělá a co funguje zde nemusí fungovat jinde. Nicméně to, že tato strategie nevedla k naprostému chaosu a rozpadu projektu, ale k tomu, že příspěvky značně vzrostly a nyní projekt AFAIK patři k jedněm z nejaktivnějších na celém githubu a roste i počet stažení (tj. stává se patrně ještě víc oblíbený i mezi uživateli) zní vcelku povzbudivě. Ještě si pamatuju, jak se na nekolika OSS projektech řešilo, jestli přejít ze SVN na git a vcelku častým argumentem proti bylo, že distribuovaný verzovaci systém zpusobí naprostý chaos. Dnes je git (nebo jiný distribuovaný systém) de facto standard, resp. obavy, že přechoz způspbí chaos jsou už asi jen ojedinělé, pokud vůbec jaké. Tak si říkám, jestli to za dva tři roky nebude podobné i s těmi commit právy a to, co se dneska jeví jako přinejmenším odvážný nápad, se nestane standardem.

Tak co na to říkáte? Líbí se vám to? Přispělo by to k tomu, abyste víc přispívali do OSS? Kde vy vidíte hlavní překážky přispívání do OSS?

       

Anketa

Komentáře

[kralyk z abclinuxu]

Například když chci reportovat bug, dokáže mě dost odradit, když je kvůli tomu potřeba založit účet na bugzille, to je na hlavu. To má smysl jen pro uživatele, kteří na dané bugzille chtějí působit delší dobu, pro typického "kolemjdoucího" nebo jen občasného návštěvníka je to ale zbytečná přítěž.

Spíš než přihlášení by před reportováním mělo být poviným krokem hledání, aby se pokud možno zamezilo duplicitním bugům, a tenhle krok stejně slušnej člověk musí províst tak jako tak.

[pavlix]

To má smysl jen pro uživatele, kteří na dané bugzille chtějí působit delší dobu, pro typického "kolemjdoucího" nebo jen občasného návštěvníka je to ale zbytečná přítěž.

To je dobře, protože kdo na bugzille není ochotný působit delší dobu, ten je zase zbytečná přítěž pro vývojáře. Myšleno, pokud dvacet lidí zadá bugreport, ke kterému si vývojáři vyžádají feedback a z nich jen jeden se vrátí, kdo z nich nějak přispěl ke zlepšení daného software?

Spíš než přihlášení by před reportováním mělo být poviným krokem hledání, aby se pokud možno zamezilo duplicitním bugům, a tenhle krok stejně slušnej člověk musí províst tak jako tak.

Dlouhodobá působnost duplicitní bugy taky řeší, protože duplicitní bugy vznikají. Zvlášť z automatizovaných nástrojů typu ABRT. Ale třeba já osobně si většinu duplicitních bugů nakonec zavírám sám.

[kralyk z abclinuxu]

To je dobře, protože kdo na bugzille není ochotný působit delší dobu, ten je zase zbytečná přítěž pro vývojáře. Myšleno, pokud dvacet lidí zadá bugreport, ke kterému si vývojáři vyžádají feedback a z nich jen jeden se vrátí, kdo z nich nějak přispěl ke zlepšení daného software?

Tak stále mi to přijde lepší, než když tam ten člověk přijde s ochotou reportovat bug, ale radši se na to vykašle, když vidí registrační formulář, případně další komplikace. Pak se o tom bugu třeba neví vůbec. Krom toho neregistrovaný uživatel může mít například povinnost zadat při bugreportu e-mail, tam ho můžou pak kontaktovat... Čili taková "registrace light"

[Mandarinka]

Amen. Z vlastní zkušenosti bych řekl, že ten uživatel je mnohem ochotnější tam opakovaně lézt aby se podíval na stav svého anonymního bugu, než nakolik je ochotný se někde registrovat, aktivovat si účet přes email a tak.

[JS]

Zajimavy paradox, ale neco na tom bude.

[Michal Kubeček]

Také jsem si dřív myslel, že když někoho bug zajímá natolik, aby ho nahlásil, bude ho dál sledovat i bez registrace a e-mailových notifikací. Bohužel je to nezřídka spíš naopak. Třeba tady měl reporter docela vážný problém, ale přesto si za měsíc nenašel čas, aby vyzkoušel (na stříbrném podnose předložený) balíček s opravou a napsal, jestli mu pomohla.

[XXX]

Nejde jen o vyplneni formulare, ale musim cekat na prijem mailu, nekdy je to v radu minut, coz je opruz. Nejaka aktivace, vyplnovani kodu z captchy. Pak prihlaseni a konecne zadani bugu.

Po pul roce se dockam krasneho prani k narozeninam, pak treba nejake newslettery. Abych si je mohl vypnout, musim se prihlasit, coz uz ale treba nemuzu, protoze si nepamatuju nick a heslo.

Samozrejme se tak nedeje vsude, ale bohuzel neznam vsechny bugtrackovaci systemy a jejich otravnosti. Krom toho hodne projektu pouziva klasicke BB systemy.

Pritom staci formular na zadani bugu a volitelne zadani mailu s volitelnou moznosti upozorneni.

[Michal Kubeček]

Pritom staci formular na zadani bugu a volitelne zadani mailu s volitelnou moznosti upozorneni.

To je spolehlivá cesta do pekel. Anonymně nahlášený bug bez možnosti vyžádání si dodatečných informací nebo feedbacku je v naprosté většině případů k ničemu. Jen se do nějaké bugzilly (nebo třeba do zdejší poradny) podívejte: zjistíte, že většina uživatelů použitelný bugreport napsat neumí a že teprve dodatečným výslechem se dá něčeho smysluplného dobrat - a nebo zjistit, že to byl nesmysl od samého počátku.

[pavlix]

+1, i když od začátku točíme jedno a to samé vysvětlení proč bugzilla bez registrace ne.

[Filip Jirsák]

Pokud je pro vás ta chyba tak málo důležitá, že vám nestojí ani za to vyplnění formuláře a počkání na e-mail, tak ji vůbec nehlašte. Vývojáři se aspoň budou moci věnovat chybám, které někomu jinému vadí víc.

Ono se často na hlášení chyb dívá jako na dobrodiní, které altruističtí uživatelé dělají pro vývojáře. Jenže uživatel zpravidla hlásí chybu, která vadí jemu; a pochybuju, že by v nějakém projektu vývojáři neměli do čeho píchnout a s napětím čekali, až jim někdo konečně nahlásí nějakou chybu. Takže když nějakou chybu nenahlásíte, vývojáři se budou zabývat jinou chybou – a ještě ušetří čas, který by jinak věnovali přečtení vašeho hlášení a jeho zařazení. Takže ve výsledku se mohou vývojáři věnovat opravám chyb, které někoho opravdu trápí.

[Fluttershy, yay!]

Ale jistě, tak to v řadě projektů také funguje, zvláště jde o ty vedené (většími) firmami. Vývojáři mají svou vizi a pokud jí (nahlášené) chyby nevyhovují, jsou ignorovány nebo značkovány WONTFIX. Jenže pokud funguje konkurence (u řady projektů je irelevantní, u řady projektů je to klíčová věc vzhledem k financování vývoje), pak to pro projekt může být fatální z hlediska přísunu financí.

[Pavel Stárek]

Ano, přesně, a typickým příkladem je AOSP (Android Open Source Project). Tam ani nenapíší to WONTFIX, tam nenapíší nic. Možná to bude třebas mojí blbou angličtinou, nevím. Drobný kosmetický bug je nahlášen zde, pro AOSP 2.1 Eclair, v té době už běželo Froyo, ve kterém je ten nepřesný a špatný termín ohledně ukládání geolokačních informací do fotek taky, no a v Gingerbreadu je jakbysmet. Takže ono kolikrát ani nebaví člověka chyby hlásit. Naopak mám dobrou zkušenost s Red Hatí bugzillou, tam to aspoň někdo zavře

[XXX]

Tezistem prispevku neni to, ze by mi vadilo cekat na email, ale to, ze kvuli napsani bugreportu musim mit nekde "ucet". Klidne tam napisu kontaktni email a vyplnim captchu, ale nechci zadny ucet ...

[Filip Jirsák]

Jaký je rozdíl mezi „vyplnit e-mail“ a „mít účet“? Vyplnění e-mailu k založení účtu bohatě stačí.

[xkucf03]

Pro některé lidi to bude asi psychologický problém – když se to nazve „Registrace“ a „Vytvoření uživatelského účtu“, tak k tomu budou mít apriori odpor. Ale když je pořádáš o vyplnění e-mailu (v rámci formuláře, kde hlásí třeba tu chybu), účet jim vytvoříš na pozadí, heslo vygeneruješ a pošleš e-mailem (nebo nepošleš a počkáš, až si o něj požádají), tak s tím takový problém mít nebudou a přitom je to ve výsledku to samé (v databázi byl vytvořen jejich účet).

[Fluttershy, yay!]

To heslo je ten problém. A ten lokální e-mail taky. Je rozdíl, když migruju e-mail*, prostě změnit nastavení jednoho globálního účtu oproti tomu, že bych musel řešit X lokálních účtů, na které se nedostanu, když se k jejich změně nedostanu.

* to se mi stalo za posledních cca pět let aspoň dvakrát

[kralyk z abclinuxu]

Vyplnění e-mailu k založení účtu bohatě stačí.

Bohužel nestačí. Obvykle mají ještě nutkání ten e-mail ověřovat odesláním odkazu, což pro uživatele znamená nutnost vlézt do svého mailu a pohrabat se v poště, případně ve spam folderu. Dále musí člověk obvykle ještě nastavit heslo a případně přihlašovací jméno. Dále si musí pamatovat, že to už udělal a s jakými údaji, když se na bugzillu vrátí po nějakém čase.

Když už teda bugzilly tak strašně nutně potřebují mít uživatele zaregistrované, ať si laskavě implementují OpenID.

[Filip Jirsák]

XXX psal, že mu čekání na e-mail nevadí. Nicméně ověření e-mailu by se pravděpodobně dělalo vždy, ať už se tomu říká registrace nebo ne. Ověření e-mailu je celkem rozumná věc, vzhledem k tomu, že chcete hlášení jen od uživatelů, kteří budou schopní a ochotní na ten e-mail reagovat.

[kralyk z abclinuxu]

Mně je jedno, jak se tomu říká, opruz je to furt stejnej. A rozumná věc to není, protože 1. OpenID, 2. Mailinator a 3. Ochota a schopnost kliknout na odkaz v mailu při registraci nijak nezaručuje ochotu a schopnost reagovat na maily ohledně daného bugreportu.

[Filip Jirsák]

Neochota kliknout na e-mail při registraci zaručuje neochotu spolupracovat při opravě chyby.

[Fluttershy, yay!]

Neochota obětovat za úplňku pannu* kvůli registraci zaručuje neochotu spolupracovat při opravě chyby.

* možno dosadit libovolnou další hovadinu, třeba vyplňování psychotestů, cílem je přece odfiltrovat všechny, pro které neplatí, že opravdu, ale opravdu touží po nahlášení chyby

[kralyk z abclinuxu]

Asi tak.

[Filip Jirsák]

Já jsem psal o opaku - odfiltrovat ty, kteří určitě nebudou při opravě chyby spolupracovat.

[Fluttershy, yay!]

Mezi kliknutím na nějaký fucking odkaz a ochotou později spolupracovat je naprosto minimální korelace už z definice jednotlivých úkonů.

[Michal Kubeček]

Teoreticky ano. Praxe ukazuje, že je ta korelace dost značná.

[kralyk z abclinuxu]

No, takže v podstatě se může před bugreport dát jako prerekvizita víceméně jakýkoli trošku složitý krok, aby se otestovala výdrž / ochota reportujícího... [cynický smajlík].

[Michal Kubeček]

Asi byste i tak dostal kladnou korelaci, ale pokud se jedná o krok, který má přímou souvislost právě s tím poskytováním zpětné vazby, je to o dost praktičtější.

[Filip Jirsák]

Asi by to fungovalo. Jenže pro komunikaci o chybě je potřeba mít nějaký funkční komunikační kanál, v dnešní době nejlépe e-mail. Takže byste tam musel mít ten jakýkoli krok, a pak ještě získání a ověření e-mailu. Jednodušší je spojit to do jednoho...

[kralyk z abclinuxu]

odfiltrovat ty, kteří určitě nebudou při opravě chyby spolupracovat.

Což se nepodařilo. Jak už píše davkol, ta souvislost tam je naprosto minimální...

[pavlix]

odfiltrovat ty, kteří určitě nebudou při opravě chyby spolupracovat.

Což se nepodařilo. Jak už píše davkol, ta souvislost tam je naprosto minimální...

Podařilo. Jak už píše Michal, korelace tam je. Teď se můžeme pohádat, kdo z nich je větší autorita :D.

[Fluttershy, yay!]

A něco jiného než důkaz autoritou nemáš?

[Michal Kubeček]

Můžete si zkusit dohledat, jak často se stává, že projekt zavede registraci do bugzilly proto, aby zvýšila relevance a použitelnost hlášení, a jak často se naopak stává, že ji zruší, aby se zvýšil počet hlášených chyb.

[xkucf03]

Znáš někoho, kdo se vykašlal na hlášení chyby kvůli tomu, že by se musel registrovat?

A pokud ano, dal (by) si tu práci a prohledal databázi chyb, aby zjistil, jestli už není nahlášená? Dal (by) si práci s podrobným popisem a dodáním postupu, jak lze chybu reprodukovat?

Např. já jsem se na hlášení chyb už hodně krát vykašlal, ale bylo to kvůli tomu, že se mi nechtělo prohledávat bugzillu, zjišťovat, kde přesně ta chyba je, zjišťovat, zda náhodou už v nové verzi není opravená… prostě mne to tolik netrápilo, abych si dal tu práci. Ale nikdy to nebylo kvůli tomu, že bych musel procházet přes CAPTCHu nebo nějakou registraci.

[Fluttershy, yay!]

Ano. Ano. Ano.

Nejlepší zkušenosti mám s hlášením chyb mimo bugzillu, typicky v mikroblogu. Komunikace téměř v reálném čase. Vyplnění reportu de facto dodatečně jako formalita. Jenže to by musela existovat vůle potíže řešit.

[XXX]

A jeste k tomu dobrodini - pokud autorum na poctu uzivatelu zalezi (coz plati minimalne u komercniho softu), tak jim zalezi i na bugreportech. Za kazdy reportovany bug je totiz minimalne 10 uzivatelu, ktere ten bug take trapi, ale tise mlci a dost mozna prejdou jinam.

[Filip Jirsák]

No právě. Za každou oznámenou chybou je mnohem víc uživatelů, které ta chyba trápí, než za chybou, kvůli které je někomu za těžko se zaregistrovat. Takže je to taková přirozená selekce, která vybírá ty důležitější chyby.

[Fluttershy, yay!]

Demagogie non-plus-ultra?

[pavlix]

Z vlastní zkušenosti bych řekl přesný opak.

[pavlix]

Tak stále mi to přijde lepší, než když tam ten člověk přijde s ochotou reportovat bug, ale radši se na to vykašle, když vidí registrační formulář, případně další komplikace.

Nejsem si tím úplně jistý, IMO je to klasický spor mezi kvantitou a kvalitou.

Tak registrace light bude když se ten e-mail ještě ověří. Podle mě by bohatě stačilo, kdyby se na bugzillách všude člověk během pár vteřin přihlásil s nějakou společnou identitou aspoň částečně vázanou na e-mail (OpenID).

[Ivorne]

Já bych to nehrotil. Já si myslím, že když po uživateli bude člověk chtít rozumné věci a je tam ten příslib veřešení problému, tak tam uživatel klidně zadá pravý email i bez nutnosti verifikace.

Já bych to viděl tak, že musí stačit zadat popis problému, nějaká debug data která vyhodí ten program a svůj email bez nějaké verifikace a mělo by to být v pohodě. Tomu, aby se tam uživatel vrátil, se pomůže tak, že se mu při odpovědi na bug pošle email a je to. Ono spousta lidí to tam třeba může dát a pak na to zapomenou. Když si vezmete, kolik času lidi stráví čekáním na facebooku na to, než tam někdo pošle nějakou stupidní hlašku, tak si myslím, že když mu přijde email, že se někde mluví o jeho problémech, tak si rád počte. Jediný probém je lenost - pamatovat si, že jsem dal bug report, pak ho zase hledat, vzpomínat si na přihlašovací údaje atd. Když bude nahlášení bugu zahrnovat popsání chyby a zadání emailu a pak po týdnu když mu přijde email mu stačí kliknout na odkaz v emailu a počíst si, tak si myslím, že by to mohl zvládnout.

[pavlix]

Ok. Já myslím, že řešíme neexistující problém. Registrovat se na bugzillách mi vadilo v době, kdy jsem se bugreportům nechěl dál věnovat. Pravdou je, že tehdy za mě pár lidí napsalo bugreport třeba díky hlášení na IRC.

V době, kdy mě fakt zajímá opravování chyb, kdy postupuju od počátečního pouhého hlášení přes starání se o chyby, doplňování informací, a další... mě nějaká registrace fakt netrápí. OpenID by pomohlo, ale registruju se i bez něj.

[Fluttershy, yay!]

OpenID by bylo ideální. Udržovat X registrací je opruz. Naštěstí je aspoň většina projektů na SF/GH nebo má bugtracker pro více projektů (KDE), takže to vesměs není tak strašné.

[D-Evil]

Pro přispívání do některejch projektů je vyžadovaná určitá kvalita kódu, což může bejt velká bariéra. Zatímco napsat nějakej funkční celek obvykle neni až tak těžký a něco rozcházet může bejt nakonec i docela zábavnej proces, onanovat nad funkčním kódem, aby prošel nějakou kontrolou kvality, to je už jenom vopruz. A pro "začátečníka" co se týká přispívání do podobnejch projektů to může bejt i důvod, proč se jeho příspěvek do projektu nikdy nedostane.

[Miloslav Ponkrác]

Jako člověk, který se několikrát pokusil do open source projektů přispět to vidím jinak.

Základním problémem jsou nosánky nahoře a neuvěřitelné hulvátsví lidí kolem open source projektů.

Bariéry na přispění do open source projektů rostou rok od roku a přívětivost správců se blíží rok od rok u většiny open source projektů přívětivosti popravčí čety. Zhruba pomyslného vrcholu asi dosahuje projekt dosbox, doporučuji masochistům vyzkoušet.

Některé další problémy: nedostatek dokumentace, nebo záhadný styl autora, který trvá na exotických debilitách v code style (konkrétně třeba případ Inkscape nebo vimu). Nebo prostě není čas na věnování se cizímu kódu – což ale většinou prochází přívětivě.

Život mě naučil, že tak 95 % projektů končí na lidské (rozuměj společenské či empatické) neshodě. Na technických problémech, tedy i kvalitách vývojářů končí zanedbatelný počet problémů. A zjistil jsem, že v open source je to stejné. Většina problémů je v lidech samotných nikoli v technice nebo kvalitě kódu.

I když jsem možná zaujatý tím, že po 25 letech praxe nevidím problémy začátečníků.

[Miloslav Ponkrác]

P.S.: Mimochodem jeden z okrajových způsobů jak si nespolečensky svými móresy odhánějí pomocníky je právě výše zmíněná povinná registrace do bugzilly.

Díky tomu jsem se vytentoval na hlášení chyb do všech projektů vyjma asi tří, které mě eminenetně zajímají. Ostatním jsem nakakinkal.

[xkucf03]

Když si spočítáš, kolik času by člověk měl věnovat prohledávání bugzilly* a psaní smysluplného hlášení – izolovat chybu, poskytnout návod, jak ji zopakovat, přiložit logy a data…, tak ta registrace je nakonec jen formalita. Vždyť kolik to zabere času? Minutu? Půl minuty? To je to nejmenší.

A je otázka, jestli člověk, který nebyl ochotný věnovat tu půlminutu, byl ochotný věnovat třeba desítky minut shánění podkladů a sepisování nějakého smysluplného hlášení chyby.

*) aby tam nezadával duplicity a neokrádal autory o jejich čas (který mohli věnovat vývoji a místo toho řeší nějakou pitomou administrativu)

[Michal Kubeček]

onanovat nad funkčním kódem, aby prošel nějakou kontrolou kvality, to je už jenom vopruz

Doporučuji zkusit něco opravit v (cizím) projektu, který se nedrží rozumného coding style a je plný zpraseného neokomentovaného kódu. Třeba se pak na ten "opruz" začnete dívat jinak…

[dementni.lojzik]

Doporučuji zkusit něco opravit v (cizím) projektu, který se nedrží rozumného coding style

treba vyse uvedeny jenkins zadne coding style nema, resp. v jenkins core AFAIK v podstate plati jedine pravidlo a to pouzivat mezery misto tabu a i tak na tom asi nikdo netrva, pokud s tim mas nejaky zasadni problem (aspon tak chapu cast ohledne coding conventiones v governance dokumentu, kde se pise, ze With that said, we do not believe in rigorously enforcing coding convention, and we don’t want to turn down contributions because their code format doesn’t match what we use.) a nejak jsem zatim nepozoroval, ze by citelnost kodu byla vyrazne horsi nez u jinych projektu

a je plný zpraseného neokomentovaného kódu. Třeba se pak na ten "opruz" začnete dívat jinak…

toto nejak implicitne predpoklada, ze lidi budou ve velkem commitovat hromady spraseneho kodu. Je ale tento prepoklad opravneny? Ja treba, kdyz si nejsu jisty, jak moc dobry je kus kodu, co jsem prave vytvoril, tak jej necommitnu primo, ale udelam pull request. Krom toho, ze pak nejsou v kodu prasarny, tak se treba i poucim, jak to priste udelat lip a IMHO tohle je win-win situace, kdy obe strany muzou byt spokojene. Toto plati zcela obecne. Zkratka neverim tomu, ze zkuseny programator je neomylny a vzdy produkuje skvely cisty kod. Moje zkusenost je spis naopak ta, ze onen geek casto vyprodukuje vysoce optimalizovany kod, ale je zapsan takovym zpusobem ze vetsina lidi, co to po nem ctou ma docela problem pochopit, o co tam jde

[D-Evil]

O tom to neni. Já neřikám, že se ten prasáckej kód má rovnou začlenit. Ale zahazovat ho kvůli nějakejm formálním nedostatkům (například) je podle mě taky špatně. O opravy nebo vylepšení opensource softwaru se pokoušej samozřejmě i laický programátoři a týrat je striktníma pravidlama znamená zabíjet jejich nadšení.

O komentářích jsem nemluvil, protože komentovanej kód považuju za základ a lpění na něm považuju za logickej a oprávněnej požadavek v jakymkoliv projektu, nejen v opensource SW.

[Michal Kubeček]

O tom to neni. Já neřikám, že se ten prasáckej kód má rovnou začlenit. Ale zahazovat ho kvůli nějakejm formálním nedostatkům (například) je podle mě taky špatně.

Většinou ho nikdo nezahodí, ale upozorní autora, že patch nesplňuje příslušná pravidla a že je potřeba ho opravit. Jak byste si to představoval jinak? Že "učesání" kódu budou provádět core vývojáři místo oprav chyb a implementace featur, které "náhodný kolemjdoucí" nezvládne?

[xkucf03]

dát commit práva každému, kdo si o ně řekne

Tahle myšlenka se mi nelíbí – je to jednak nebezpečné a jednak zbytečné.

1) Uživatelé očekávají nějakou úroveň kvality a určitě by neměli radost, kdyby do daného softwaru mohl dělat změny každý, kdo šel jen tak kolem. To je možná přijatelné u překladů (lokalizace), ale pro zásahy do spustitelného kódu určitě ne.

2) Díky distribuovaným verzovacím systémům si nový vývojář může naklonovat úložiště a v něm si vést vlastní vývoj (nikomu nemůže uškodit a zároveň má zcela volné ruce). Služby jako Github, Bitbucket nebo SourceForge jsou na to jako dělané, stačí jednou kliknout. Ale ani nejsou potřeba, člověk si může udělat třeba hg clone na svůj desktop (to vlastně musí udělat stejně) a svůj příspěvek pak poslat e-mailem nebo pověsit někam na web.

Nový vývojář se proto dokonce ani nemusí nikoho doprošovat, aby mu (byť jen tak na řeknutí) dal práva zápisu – on je totiž vůbec nepotřebuje a nemusí se nikoho na nic ptát.

Dávat „náhodným kolemjdoucím“ práva zápisu (byť do oddělených větví) na server, který používají kmenoví vývojáři, je zbytečnost.

Jinak celkem souhlas, otevřenost a přívětivost je dobrá. Akorát se to nesmí přehánět – bugzilla zaneřáděná duplicitami a nesmysly přestává být užitečná a úložiště plné nekvalitního kódu (který jsme přijali bez pořádné kontroly) je horší, než menší množství kvalitního kódu.

[dementni.lojzik]

vezmu to odzadu: ano, distribuovane verzovaci systemy bezpochyby velmi usnadnuji vyvoj a servry jako github umoznuji bezbolestne verejne sditel moje upravy a nove funce. Co ale delat ve chvili, kdy bych je rad dostal do upstreamu (az uz proto, ze me nebavi udrzovat vlastni fork nebo si myslim, ze by to ocenili i dalsi uzivatele, kteri pochopitelne neprochazi forky projektu a nezkoumaji, jestli tam neni neco uziteneho i pro ne), ale na muj pull request se nikdo uz mesic/mesice nepodival, takze moje prace byla castecne zbytecna (neprinesla uzitek vic lidem, jak jsem puvodne cekal, ale jen me, a to je jeste otazka, protoze musim udrzovat svuj fork) a navic me to ani nikam neposunuje, protoze chybi zpetna vazba od ostatnich vyvojaru. To same plati o hrani si na vlastnim pisecku u sebe na localhostu. Je to treba pekna zabava, ale to je cele. Kdyz ten kod nekde sdilim, tak to ma vetsi uzitek jak pro me, tak i ostatni lidi.

V podstate je cele o tom, proc by mel byt lepsi pristup verit jen ten co se osvedcili a neverit nove prichozim, pred pristupem verit apriori vsem a neverit jen tem, co se ukazali jako spatni/neschopni (presne takhle je to fomulovano ve vyse zminovanem jenkins governance dokumentu: This is partly achieved by not requiring new contributors to “prove themselves” before they are admitted to the committership. Instead, we assume they are good until proven otherwise, and this principle applies to anybody without arbitrary discrimination.)

Cimz se dostavam k tomu prvnimu bodu a totiz kvalite. Opet, jak jsem psal vyse, obavy o kvalitu obsahuji implicitni predpoklad, ze prispevky od nahodnych kolemjdoucich budou spatne. Nejsu si ale moc jisty, jestli je tenhle predpoklad opodstatneny. Rozhodne stoji za dukladne zamysleni, ale myslim, ze dobrymi testy a vecmi jako kontinulani integrace lze ten problem pomerne dobre minimalizovat.

Projekt Jenkins je pro me docela silnym dukazem zivotaschopnosti tehle myslenky z nemale casti i proto, ze to neni zadny software, ktery by mel monopol. Presne naopak, pred necelym rokem se odstepil od puvodniho projektu Hudson a prejit na nej z Jenkins je velmi jednoduche. V te dobe Oracle, ktery spolu se Sonatype a dalsimi pokracuje ve vyvoji Hudsonu, IMHO sazeli na to, ze Jenkins nebude schopen diky zivelnemu vyvoji drzet dostatecnou kvalitu a drtiva vetsina uzivatelu prejde k Hudsonu, u ktereho zavedli v Oracle QA, presna pravidla pro prispevky, vyvojovy cyklus atd. (a Jenkins na tento velmi otevreny vyvoj vsadil v dobe, kdy mel hodne co ztratit). Je tezke srovnavat, protoze statistiky pouzivanosti Hudsonu jsem zatim nevidel (a pochybuji, ze jsou nekde verejne), pouzivanost u Jenkins ale roste, coz svedci minimalne o tom, ze uzivatele neodchazi a predpoklad nezivotashocpnosti takoveho projektu se ukazal jako mylny. Abych to bylo fer, tak je ale jeste nutno dodat, ze i Jenkins ma LTS (long term support), co je starsi verze s asi 3 mesicnim releas cyklem, ktera se testuje pecliveji.

[Filip Jirsák]

Pokud nikdo z upstreamu nereaguje na požadavek na přetažení, stejně asi nesestaví novou verzi ani nebude s projektem dělat nic jiného. Takže jej můžete požádat o plný přístup k projektu a stát se novým správcem, nebo udělat fork. Pokud nikdo nereaguje na požadavek, ale vývoj normálně dál běží, vašeho commitu by si nikdo nevšímal a ten by proplul až do finální verze bez povšimnutí, utíkal bych od takového projektu co nejdál.

Opet, jak jsem psal vyse, obavy o kvalitu obsahuji implicitni predpoklad, ze prispevky od nahodnych kolemjdoucich budou spatne. Nejsu si ale moc jisty, jestli je tenhle predpoklad opodstatneny.

Jenže tímhle neumožníte přispívat jen náhodným kolemjdoucím, ale také záměrným škůdcům. A u těch už je ten předpoklad o špatných příspěvcích opodstatněný.

[dementni.lojzik]

Pokud nikdo nereaguje na požadavek, ale vývoj normálně dál běží, vašeho commitu by si nikdo nevšímal a ten by proplul až do finální verze bez povšimnutí, utíkal bych od takového projektu co nejdál.

tohle je IMHO castejsi pripad, ze si pull requestu nikdo nevsima a vyvoj bezi dal. Nasledny commit pak chapu jako o uroven duraznejsi pull request. Sice nemam uplne podrobnou znalost, jak to funguje na Jenkins projektu, ale nechce se mi verit tomu, ze by nikdo nekontroloval nove commity. Toto delat by bylo pochipitelne dost pochybne, eufenimisticky receno.

Jenže tímhle neumožníte přispívat jen náhodným kolemjdoucím, ale také záměrným škůdcům. A u těch už je ten předpoklad o špatných příspěvcích opodstatněný.

ano, tady je to opodstatnene, ale kdyz se nekdo rozhodne skodit, tak je to vzdycky problem. Nejsu si ale jisty, jak moc casty by to byl problem, resp. resil bych to, az by se neco takoveho stalo.

[pavlix]

ano, tady je to opodstatnene, ale kdyz se nekdo rozhodne skodit, tak je to vzdycky problem. Nejsu si ale jisty, jak moc casty by to byl problem, resp. resil bych to, az by se neco takoveho stalo.

Jo, když někdo neví, jak strašně moc je ztráta důvěry drahá, to je potom docela problém.

[dementni.lojzik]

jak se od commitu skodliveho kodu dostavam ke ztrate duvery? Nechybi tam nahodou mezikrok, ze musim jeste releasnu build s tim skodlivym kodem? A jak v tom komentari pisu, pokud se commity nekontroluji, pak to vidim jako podstatny problem.

[pavlix]

Nechybi tam nahodou mezikrok, ze musim jeste releasnu build s tim skodlivym kodem?

Nechybí. Repozitář je přeci veřejný.

[dementni.lojzik]

Nechybí. Repozitář je přeci veřejný.

to me prijde stejne kvalitni argument jako ze wikipedie je krajne neduveryhodna, protoze nahodny kolemjdouci muze zmenit co chce a nez to nekdo revertne, tak si to muze precist hromada lidi...

[pavlix]

to me prijde stejne kvalitni argument jako ze wikipedie je krajne neduveryhodna, protoze nahodny kolemjdouci muze zmenit co chce a nez to nekdo revertne, tak si to muze precist hromada lidi...

Až zkusíš citovat Wikipedii jako důvěryhodný zdroj, možná pochopíš. Nedůvěryhodnost patří mezi její základní vlastnosti, se kterými musí průměrně vzdělaný uživatel počítat.

[dementni.lojzik]

hm, zajimave posunuti argumentace. Ja myslel, ze byla rec o duveryhodnosti projektu ne o tom, jak moc duveryhodne je citovat wikipedii. Pro me je to duveryhodny projekt a rekl bych, ze pro nemalo lidi zrovna tak. Jsem si vedom, ze tam muzou byt neprosnosti a nebo dokonce naproste lzi (zamerne prepsana stranka) a pocitam s tim, proto pri prebirani nejake dulezite informace si ji snazim overit odjinud. Kdyz ale budu prebirat nejaky dulezity kod z repozitare nejakeho projektu, prijde mi naproste logicke udelat totez, bez ohledu na to, kdo tam ma prava commitovat (nemyslim ted overeni z vic zdroju, ale ze si ten kod prostuduju, co dela a neudelam copy-paste). Jestli to bude projekt, kde budou mit commit prava hodne lidi, budu o to opatrnejsi, ale v zadnem pripade to (ze se v repu na chvili muze objevit skodlivy kod) v mych ocich z toho projektu nebude delat neduveryhodny projekt

[xkucf03]

Pro me je to duveryhodny projekt a rekl bych, ze pro nemalo lidi zrovna tak. Jsem si vedom, ze tam muzou byt neprosnosti a nebo dokonce naproste lzi (zamerne prepsana stranka) a pocitam s tim

A o to právě jde – u Wikipedie s tím lidi počítají, ale u softwaru je běžná jiná praxe – tam je obvyklé, že přispívat můžou jen prověření autoři.

[dementni.lojzik]

u vydaneho software urcenoho uzivatelum ano, ale tam predpokladam, ze se ten skodlivy kod nedostane (a pokud dostane, tak je to spatne), takze tady by k naruseni duvery nemelo dojit. Diskuze ale byla o tom, ze je problem to, ze se ten kod objevi v repozitari. Tady nevidim zadny problem. Jedine, co me napada je, ze nekdo bude chtit prevzit funkci A, ktera bude obsahovat skodlivy kod (stahne si zdrojaky ve chvili, kdy zrovna tam byl skodlivy kod commitnut). Neumim si ale predstavit, ze by nekdo udelal jen ciste copy-paste. Prijde mi naprosto normani zkontrolovat licenci, samotny kod a vedet neco o projektu, ze ktereho to beru. I kdyz pominu to, ze o tom projektu nebudu nic vedet nebo prehlinu, ze tam muze prispivat kde kdo, pokud udelam copy-paste bez kontroly toho kodu, tak su blb ja a muzu si za to sam. Kdyz uz jsem u toho, brat neco z trunku neni uplne dobry napad tak jako tak, protoze tam ta funkce zrovna muze byt rozbita (bez ohledu na to, kolik lidi tam ma pravo commitu), takze osobne bych kod prebiral z nejaky stable vetve nebo aspon posledniho tagu, kde, opet podle predpokladu vyse o kontrole commitu, by se skodlivy kod vyskytovat nemel.

[pavlix]

u vydaneho software urcenoho uzivatelum ano, ale tam predpokladam, ze se ten skodlivy kod nedostane (a pokud dostane, tak je to spatne), takze tady by k naruseni duvery nemelo dojit.

Chyba tvé úvahy je v tom, že přeceňuješ rozdíl mezi commitem tagovaným pro vydání a ostatními commity.

[dementni.lojzik]

precenuji? Jestli nekdo dela release tak, ze ho nezajima stav kodu, ale tak, ze si rekne, to mame dneska hezke odpoledne, co kdyby jsme udelali release, tak pak ano, tohle by slo oznacit neduveryhodny projekt, ale nijak to nesouvisi s tim, kdo vsechno do projektu prispiva

[petr_p]

Jenže teď neřešíme tak přízemní věc jakou je stabilita nebo funkcionalita, ale bezpečnost. Pokud může commitovat jen správce, tak patch zařadí až po té, co jej zkontroluje. Ve vašem otevřeném systému by musel kontrolovat všechny změny od posledního vydání. Najednou. A to nikdo (vynechám „armádní“ vývoj) nedělá. Takže pokud mám některý z modelů označit za nedůvěryhodný, tak ten otevřený.

[dementni.lojzik]

Ve vašem otevřeném systému by musel kontrolovat všechny změny od posledního vydání. Najednou.

proc? AFAIK je staci kontrolovat postupne, jak prichazeji. V podstate to same, by delal pri kontrole patchu, jen je necommituje on, ale nekdo jiny

[xkucf03]

To znamená, že si to bude kontrolovat každý sám – tzn. jedna práce se udělá víckrát*, přestože by kontrolu mohl dělat někdo centrálně za ostatní – pouštět schválené změny do větve/úložiště, odkud si je ostatní s důvěrou stahují.

*) což by v tomto případě nemuselo vadit, ale je otázka, jestli je tým schopný z té vícenásobné kontroly vytěžit nějaký užitek, nebo jestli je to jen zbytečná práce opakovaná několika lidmi. Užitek by mohl spočívat v tom, že by si jeden všiml něčeho, co jiný přehlédl – jenže tady je problém, že když jeden není dostatečně pozorný, může se mu např. zavirovat počítač, vir z něj ukradne přístupové údaje k serveru, kde se vydávají oficiální verze nebo napáchá jiné škody (a ohrozí celý tým + uživatele). Proto nakonec může být lepší, když kontrolu budou dělat jeden/dva lidi, ale pořádně.

[dementni.lojzik]

co bude kontrolovat kazdy sam? Kdo a jak to bude kontrolovat je jen vec domluvy, klidne to muze kontrolovat centralne jen jeden clovek.

[Michal Kubeček]

To znamená, že si to bude kontrolovat každý sám – tzn. jedna práce se udělá víckrát*, přestože by kontrolu mohl dělat někdo centrálně za ostatní – pouštět schválené změny do větve/úložiště, odkud si je ostatní s důvěrou stahují.

To je ta lepší varianta. Také to může teoreticky dopadnout i tak, že si každý řekne: "Teď to nemám čas zkoumat, kdyby tam bylo něco vážného, určitě by si toho někdo všiml." Když má člověk commitnout cizí patch a tím se pod něj "podepsat", tak má přeci jen větší motivaci si ten patch nejdřív pořádně projít.

[petr_p]

Proč? Protože jste psal, že se commituje všechno hned. Zkuste si na týden „udělat“ volno. Třeba přes vánoce v pcre přibylo 50 commitů, z nichž jeden je gigantický „merge UTF-16 branch“.

Jak se pozná zkontrolovaný pach od nezkontrolovaného? Ať už z hlediska správce nebo náhodného vývojáře, který si naklonuje „hlavní“ větev? Bude zvláštní větev, do které se budou jednotlivé commity kopírovat? Ale pak de facto větev revidovaná není veřejná, jak požadujete. A co se stane, když revidovatel najde chybu? Přepíše commit, čímž následující historie nebude aplikovatelná? A kdo ji bude rebasovat? Ten jeden správce? Nebylo by výkonnější říct kolemjdoucím vývojářům, ať to udělají oni?

Pořád mi vychází, že fakticky existuje větěv, kam má přístup jen správce, protože potřebuje mít jistotu, že se mu tam nemění kód pod rukama.

[dementni.lojzik]

tak jeste po 101 napisu, ze nevim, jak "spravne" kontrolovat commity, jestli vas to vsechny opravdu tak trapi, tak ze muzu zkusit preptat vyvojaru Jenkins, jak to delaji. IMHO je to cele o domluve, co ti vyvojari budou povazovat za bezpecne a co ne. Jestli je ten projekt tak aktivni (50 commitu/tyden), tak ma bezpochyby dostatecne velkou kominunitu a dost duveryhodnych vyvojaru (kteri prispivaji delsi cas a osvedcili se), takze jeden nebo dva si urcite budou moct udelat volno a predat kontrolu na cas nekomu jinemu. Dalsi vec je, ze commity od onech "starych znamych" vyvojaru asi moc kontrolovat nemusis, takze je otazka, kolik ti jich vlastne zbude. Ja bych rekl, ze jednotky (schvalne jsem se ted dival na posledni commity v Jenkins core a drtiva vetsina pochazi od lidi, kteri do projektu dlouhodobe prispivaji, navic zmeny tech ostatnich jsou jsou typicky mensiho rozsahu nebo zcela trvialni jako treba opravy v lokalizaci). Dalsi vec je, jestli by se tech 50 commitu vyrazne nezredukovalo, pokud by ten projekt byl rozdeleny na moduly a kazdy mel sveho spravce.

V podstate jedine, co se snazim rict, je, ze semi zda, ze apriori projevovana neduvera (prvne ukaz, co umis a pak te budem brat vazne a dostanes commit prava) je pro OSS horsi a patrne zbytecne odrazuje potencialni vyvojare, nez kdyz se jim apriori projevi duvera (dostanes commit prava kdyz chces, ale kdyz je budes zneuzivat nebo se ukazes jako uplna lama, tak o ne prijdes). Dal jsem priklad pomerne rozsahleho projektu, kde to takto (uspesne) funguje ke spokojenosti vsech. Necht si to kazdy prebere jak chce, jestli je nekdo stale presvedceny, ze je to blbost, co nemuze fungovat a diskredituje dany projekt, je to jeho vec. Me uz presvedcovani prestalo bavit, takze to berte ciste jen jako inspiraci k zamysleni, az nekdo z vas bude zas fnukat, ze do jeho (nebo nejakeho jineho) OSS temer nikdo neprispiva...(ostatne cely ten zapisek vziknul jako rekce na stesky, ze na abicku nikdo nepomaha s jeho vyvojem)

[Michal Kubeček]

ostatne cely ten zapisek vziknul jako rekce na stesky, ze na abicku nikdo nepomaha s jeho vyvojem

To je IMHO do značné míry dáno Javou, která mezi linuxáky není nijak zvlášť populární.

[xkucf03]

To bych neřekl.

[pavlix]

Já ano.

[kralyk z abclinuxu]

To je IMHO do značné míry dáno Javou, která mezi linuxáky není nijak zvlášť populární.

To je možné, ale ta 'uzavřenost' vývoje na tom má imho větší podíl...

[xkucf03]

Spíš bych řekl, že je to o lenosti a/nebo nedostatku času…

Uzavřenost? Který jiný portál dal svoje zdrojáky volně ke stažení? Který portál má bugzillu do které můžou čtenáři zadávat chyby?

[dementni.lojzik]

ja bych rekl, ze je to hromada faktoru a u kazdaho muzou byt jine (a typicky je to kombinace vic dovodu). Krom klasickych jako nedostatek casu, tak je to skala od toho, ze mi nesedi jazyk, nelibi se mi stavajici kod a je obtizne tam neco dodelavat az po to, ze se to spatne testuje ... to jsou vsechno validni duvody, proc si vybrat, ze svuj cas venuju projektu A a ne projektu B. Nicmene tu psychologii bych nepodcenoval. V dobe, kdy najit zajimavy a dobry OSS projekt, do ktereho bych chtel prispival, vazne neni problem, IMHO hraji duvody i tyto "mekke" faktory jako chovani ostatnich vyvojaru, duvera a pod. (jasne, tohle svou roli hralo vzdycky, ale s rustem poctu OSS projektu to ma IMHO cim dal vetsi vyznam, aneb proc se na projektu A nekoho o neco porad prosit, kdyz o kousek vedle na projektu B delaji neco podobneho, ale nebudu se tam potrebovat tak casto neceho doprosovat a cekat, az to udela a celkove se tam ke me budou chovat lip). Ostatne, umim si predstavit, ze celkova pozitivni atmosfera na projektu by mohla pohnout i s nekterymi nerozhodnymi zacatecniky. Sam si pamatuju, jak jsem se kdysi premahal napsat a poslat svuj prvni patch, protoze jsem cekal, ze budu za blbce a rikal si (dobra, tohe si nepamatuju, ale asi to tak bylo), jestli mam travit cas nad necim, s cim se mi pak v upstreamu vysmejou a bude to k nicemu nebo se radeji na to vykaslat a cist si (a skutecne jsem byl se svym prvnim patchem vyfakovan, coz mou naladu prispivat do OSS na nejakou dobu docela schladilo).

[dementni.lojzik]

vlastne, kdyz nad tim premyslim, tak ten muj prvni patch je docela dobry priklad (nevim, nekolik typicky, ale rekl bych, ze to neni zcela ojedinely pripad): dodelal jsem do jednoho softu nejakou funkci, co mi prisla dobra a pouzival bych ji. Patch byl hlavnim vyvojarem (po urgencich, aby se k tomu nejak vyjadril) zamitnut s tim, ze si mysli, ze by to moc lidi nepouzivalo, tak proc to zbytecne komplikovat. Byl to hlavne zpusob argumentace, co me nastvalo, samotne zamitnuti prohelo zcela slusne. Jiste je snad zrejmy rozdil oproti pripadu, kdy by mi napsal neco ve smyslu, ze je mu lito, ale ze si mysli, ze tohle do jadra nepratri, ale soft podporuje pluginy, tak mi navrhuje, abych to udelal jako plugin a uz mi udelal i repozitar a dal prava tam commitovat, abych to mohl jeste doupravit jako plugin a nasledne releasnout.

[kralyk z abclinuxu]

Spíš bych řekl, že je to o lenosti a/nebo nedostatku času…

Jo, to je určitě taky pravda...

Uzavřenost? Který jiný portál dal svoje zdrojáky volně ke stažení?

O tom už se diskutovalo, veřejný source není všechno... Ale samozřejmě souhlasim, že ostatní portály jsou (většinou) uzavřenější...

[pavlix]

precenuji?

Ano.

[pavlix]

Takže díky za uznání, že je můj argument tak kvalitní. I když mám pocit, že kvalitu mého argumentu ještě o trochu přeceňuješ.

[pavlix]

ale na muj pull request se nikdo uz mesic/mesice nepodival

Je to velmi jednoduché. Řeš příčinu, ne symptomy. Jestliže integrátor nefunguje, jsou jen dvě možnosti:

a) Integrátora přesvědčit, aby začal fungovat

b) Integrátora nahradit (někdy to jde v rámci projektu, někdy je k tomu potřeba regulérní fork)

Je to věc, která je odzkoušená a funguje bezvadně, a navíc podstatně lépe než nechávat nedůvěryhodné lidi zasahovat do oficiálních stromů.

[dementni.lojzik]

Je to věc, která je odzkoušená a funguje bezvadně

odzkousena mozna, ale nebyl bych si moc jisty, jestli opravdu vsude tak bezvadne funguje

[pavlix]

Já jsem s tím naprosto spokojený. Narozdíl od tvého modelu, který by mě odradil se k takovým projektům vůbec přiblížit.

[dementni.lojzik]

tak predne to neni muj model. Jinak ti neberu, ze mas byt spokojeny, jestli jsi, tak je to jedine dobre a k cemu se chces nebo nechces priblizovat je jen tvoje vec. Ja jen mam pocit, ze nemalo lidi spokojeno neni a tohle mi prislo jako zajimava myslenka, tak jsem ji sem dal k dizkuzi, to je cele. A zatim nejsem tady nevidel dostatecne padny argument, ze to tohle je cesta do pekel

[pavlix]

A zatim nejsem tady nevidel dostatecne padny argument, ze to tohle je cesta do pekel

Kompromitace počítačů všech vývojářů i uživatelů, kteří si dovolí testovat na živém počítači s živou sítí, ti přijde málo jako cesta do pekel?

Mno jak myslíš. To, že jsi dostatečně pádný argument neviděl bych přisuzoval spíše tvé slepotě než tomu, že by nepadl.

[dementni.lojzik]

tohle je pro zmenu zajimava generalizace Jak mi to, ze se v repu na chvili objevi skodlivy kod, kompromituje pocitace vsech vyvojaru a uzivatelu, co testuji? Pokud ma projekt velmi rychly vyvojovy cyklus, tak se obvykle zadna CR-ka nedelaji, uzivatele "testuji" tak, ze pouzivaji poledni vydanou verzi (ktera se typicky vydava kazdych par dni). Takze uzivatele jsou mimo hru (pokud predpokladame, ze do vydane verze se to nedostane). Vyvojari urcite taky nejsou ohrozeni vsichni, jen tech par prvnich, nez nekdo prijde na to, ze je tam skodlivy kod. Kdyz nepocitam to, ze ten kod samotny se ani nemusi ke me na pocitac dostat abych to zjistil (napr. diky emailove notifikaci commitu), i kdyz si jej z repa stahnu, jeste tim neni ohrozen muj pocitac. Nevim jak ty, ale ja (a rekl bych, ze vetsina normanich vyvojaru) si pri stahovani zmen z repa ty zmeny aspon zbezne prohledne, takze pravdepodobnost, ze to objevim jeste nez se to pokusim zkompilovat a pustit je IMHO vcelku velka. Pokud chces namitat, ze tech zmen bude obrovske mnozstvi, takze je nejde prochazet, pak bud na tom projektu moc casto nedelas (a onen skodlivy kod bude odhalen vyvojari, co na nem delaji denne) nebo je to nejaky obrovsky monst projekt, coz je v rozporu s dalsimi radami udelat ten projekt modularni a co nejvic pluginovatelny (coz znamena pomerne stihle jadro projektu a vetsinu funkcionality v podprojektech, ktere jsou na sobe nezavisle). V neposledni rade, pokud ses paranoidni nebo zkratka nechces porhlizet stahovane commity, muzes to poustet a testovat v nejakem jinem (zabezpecem) prostredi. Ostatne hromada vyvojaru to tak dela normalne (ne kvuli bezpecnosti, ale kvuli nastaveni prostredi a pod)

takze mozna su slepy, ale minimalne ta tva argumentace me moc nepresvedcila...

[pavlix]

Jak mi to, ze se v repu na chvili objevi skodlivy kod, kompromituje pocitace vsech vyvojaru a uzivatelu, co testuji?

Tím, že ho spustí.

Pokud nemáš základní povědomí o tématu, tak s tebou nelze vést smysluplnou diskuzi.

takze mozna su slepy, ale minimalne ta tva argumentace me moc nepresvedcila...

Vidím to na první část tvé věty.

[dementni.lojzik]

Tím, že ho spustí.

cely ten predchozi prispevke byl o tom, ze jsem se ti snazil vysvetli, ze k situaci, kdy se ten skodlivy kod spusti by vubec nemelo dojit. Celt jsi to vubec? Jestli ano, tak mi vysvetli, jak se mi stane, kdyz kontroluju commity a ke kompilaci/spusteni a nasledne do release jdou jen ty dobre komity commity (skodlivy kod je odstranen) se mi stane, ze ten kod spustim u sebe nebo jej spusti uzivatel.

[mich]

Já se přidám k pochybovačům. V "normálním" projektu když chce vývojář udělat třeba bugfix, tak si branchne vývojářskou větev (trunk) a s tou pracuje. Pokud jsem to pochopil správně, tak v tom tvém konceptu by nejdříve musel zkontrolovat předchozí commity (všechny ty, které ještě neviděl), aby zjistil, jestli například nějaký vtipálek nepřidal do nějakého testu řádku ve stylu system("rm -rf ~/");. Pokud by ty commity nezkontroloval, tak by se pak smazání vlastního homu nemohl divit - stačilo by mu jen spustit testy.

Smazání homu je jen hloupý příklad, pointa je v tom, že obecně je trunk chápán jako něco co je v relativním pořádku (dá se to zkompilovat a projde to testy). Pokud by do něj mohl commitovat kdokoli, myslím, že by v mnoha projektech nastal chaos.

[dementni.lojzik]

Pokud jsem to pochopil správně, tak v tom tvém konceptu by nejdříve musel zkontrolovat předchozí commity (všechny ty, které ještě neviděl)

nemusel, staci udelat vetev z podleniho tagu (tj. podlesni duveryhodne verze). Jeslikoz se predpoklada velmi rychly vyvojovy cyklus, pravdepodobnost konfliktu (se znemami odeslanymi po poslednim tagu) je velmi mala.

[Michal Kubeček]

Jak tak přemýšlím o té konstrukci, kterou tu popisujete, nemůžu si odpustit otázku: víte o nějakém netriviálně rozsáhlém a živém projektu, který takhle funguje nebo je to jen hypotetická konstrukce? Výrazem "takhle" rozumím, že právo commitu do master větve (nebo ekvivalentu) má kdokoli, kdo si o něj řekne, a kód se kontroluje až poté, co se vytvoří větev pro oficiální release.

[dementni.lojzik]

tak nejsu su uplne jisty, co je netrivialne rozshaly projekt, ale ono zde nekolikrat zmineny Jenkins, ktery ma na githubu pred 600 repozitaru a pres 300 clenu snad je dostatecne netrivilani. Jak jsem uz jednou zminoval, nevim, jak presne probiha kontrola commitu (a popravde nevim, jestli vubec probiha, kazdopadne oni tvrdi, ze davaji commit prava kazdemu, kdo si rekne. Jeste bych doplnil, ze Jenkins je opravdu siroce pouzivan a pouzivaji jej i organizace jako treba apache nebo jboss, takze rikat o tom projektu ze je neduveryhodny by asi bylo docela odvazne...

[Filip Jirsák]

Mezi „dávají práva každému, kdo si řekne“, a „commitovat může kdokoli“ je propastný rozdíl. V tom prvním případě totiž pořád máte nějakou identitu, můžete zkontrolovat všechny příspěvky od jednoho člověka, můžete se podívat na historii jeho změn… Práva „každému, kdo si řekne“ jsou myslím ve světě OSS celkem běžná věc, ono taky moc nejde každého nějak kádrovat, spousta lidí se zná jenom podle e-mailové adresy – takže prakticky jediný způsob ověření je, že dotyčný už poslal dříve nějaké patche. Ale jak jsem psal, ani to není ve spoustě případů nutné.

[Fluttershy, yay!]

Sorry, ale tohle je triviální školní příklad na sémantické vyplývání.

[pavlix]

A taky typický příklad na rozdíl mezi teorií a praxí. Rozdíl o tom, jestli může commitovat kolemjdoucí, a jestli může commitovat někdo, kdo si dal práci s tím se alespoň představit a požádat o právo zápisu, je propastný.

I když mě osobně v době Gitu nejvíce vyhovuje, když má právo commitovat každý jen u sebe, s výjimkou alespoň trochu vybíraných lidí pro commit do hlavního stromu. Pokud tedy není v daném případě aplikovat model diktátora a vedlejších větví.

[Fluttershy, yay!]

Jo, několik lidí to nasere (GOTO 19 a pokud tvrdíš, že mnou zjištěné chyby nikoho jiného neserou, pak GOTO 46) a kdyby někdo chtěl opravdu škodit (a nebyl to náhodný spammer, což na téhle úrovni dost pochybuju), stejně práva dostane.

[pavlix]

Jo, několik lidí to nasere (GOTO 19

Dejve dal jsi mi špatný odkaz, kde píšeš o problému, který se veřejně čitelných zdrojů netýká. Ten druhý odkaz je taky úplně mimo. Takže se zkus probudit a psát k věci.

[Fluttershy, yay!]

Byl to systém á la Launchpad (ne-li Launchpad přímo), takže veřejně čitelné to je, ale v imbecilním rozhraní. Pro odeslání změn (a teda stažení toho PO pro překlady, které se používalo lehce jiné než z aktuálních zdrojáků, ale to je demence systému, ne věc projektu), tzn. commit, jsem se musel stát členem týmu.

Ale abych tě uklidnil, totéž se mi stalo i s jiným projektem, kam jsem chtěl poslat patch -- ve stromě se vesele vyvíjelo, ale vývojáři nereagovali na e-maily poslané na adresu uvedenou na webu projektu.

[dementni.lojzik]

tak to sorry, jestli doslo k takovemuto nedorozumeni. Nejak mi prislo samozdrejme, ze ten clovek ma ucet na githubu, na mailing listu si rekne o commit a prava a ty dostane, rozhodne jsem to nemyslel tak, ze muze commitovat uplne kdokoli a jeste k tomu anonymne (uznavam, ze to ale tak mohlo vyznivat, zvlaste ty prispevky, kde jsem pouzil "nahodny kolemjdouci" a pod.). Takze timto se snad vyjasnuje jedno nedorozumeni. Jinak ale nesouhlasim s tim, ze tohle je ve svete OSS bezne. Typicky musis mit minimalne dost kvalitnich patchu a nekde je ta latka opravdu hodne vysoko (tusim treba u apache projektu).

[Fluttershy, yay!]

samozdrejme

FUUUUUUUUUUUUUUU-

[dementni.lojzik]

njn, sorry

[Fluttershy, yay!]

Zatím jsem neměl čas projít si pořádně celé, jen jsem to proletěl.

Za hlavní považuju skutečně minimalizaci bariér. Globální identita (jeden účet pro bugzillu nebo rovnou weby celého KDE? luxus!), slušné UI (starší verze Bugzilly jsem upřímně nenáviděl)... Jednou se mi stalo, že jsem nárazově potřeboval jednu aplikaci. Chvíli jsem s ní dělal, čeština byla to totálně zprasená, zavádějící (beztak na tom dělal Frič). Tak jsem vlezl na web, že to opravím. Abych si vůbec mohl stáhnout PO soubor, musel jsem si zažádat o členství v týmu, což musel schválit živý vývojář (otázka několika dnů), tak jsem se na to vysmolil.

[R]

Najlepsie je, ked ludia reportuju bugy (reprodukovatelne aj s postupom, pripadne dokonca aj s patchom) a vyvojari na to seru. Pritom zabugovanost je najvacsi problem open-source SW.

[pavlix]

Najlepsie je, ked ludia reportuju bugy (reprodukovatelne aj s postupom, pripadne dokonca aj s patchom) a vyvojari na to seru.

Což je problém, který jde v opensource celkem elegantně řešit.

Pritom zabugovanost je najvacsi problem open-source SW.

Píšeš, jako by to byl problém specifický pro opensource. Ale specifikum opensource je právě to, že se ten problém dá řešit (pokud někdo chce, samozřejmě).

Tvé pocity dost možná vychází z představy, že opensource znamená, že je někdo povinen opravovat tvé chyby (bez ohledu na to, jestli dáš patch nebo nedáš patch). Ta představa je naprosto lichá.

[biolog]

A jak by to měl řešit? Napsáním patche a commitnutím ho do repozitáře - do kterého nemá práva? Nebo forknutím? To znamená převzít vývoj na svá bedra, to je pěkně velký úkol.

Když autoři nezpracovávají patche a ignorují bugreporty, není jak s nimi spolupracovat na vývoji, tedy je to mimo rámec tohohle blogpostu. (Navíc katedrální model je částečně mimo rámec open sourcu.)

[pavlix]

Když autoři nezpracovávají patche a ignorují bugreporty, není jak s nimi spolupracovat na vývoji, tedy je to mimo rámec tohohle blogpostu. (Navíc katedrální model je částečně mimo rámec open sourcu.)

V bazaar modelu jsou tyhle problém lépe řešitelné než jednou velkou osobností s jedním velkým forkem.

Věc se má tak, že můžeš dlouhodobě udržovat nezačleněné změny (dobře se to dělá s DVCS, ale jde to zvládat i s patchi) a zároveň můžeš změny zveřejnit (větev v DVCS nebo originál+patchset). Udržování patchů samozřejmě stojí nějakou tu práci.

Pokud si půjčíš pojmy z katedrály, tak se na takovou akci dá dívat jako na větev nebo jako na fork. Zajímavé je, že o větvi „všichni“ tvrdí, že její údržba je jednoduchá, o forku „všichni“ tvrdí, že jeho údržba je složitá.

Pokud vývojáři nezačleňují důležité změny, může je začít začleňovat kdokoli, kdo udržuje větev. Přirozeně se utvoří skupina lidí, kteří začnou udržovat společnou větev (ať už ji uržuje jeden člověk nebo skupina), kterou berou jako nový upstream. Původní upstream se pak může a nemusí začleňovat.

Postupně se může nová skupina rozhodnout zvolit nový název, udělat si webovou stránku, a vydávat releases.

A nebo... pokud je to politicky možné, tak noví správci převezmou původní projekt po starých, a z nové větve se udělá hlavní větev. To je ten lepší případ.

[biolog]

Repozitář udělat mohou, ale dokud nevytvoří webstránky, bugtracker, release atd., tak je budou původní programátoři ignorovat (když je ignorovoali před tím).

Pokud nebudou nebudou přijímat změny z původního projektu a ani nebudou mít hodně vlastních programátorů, bude těžké přesvědčit uživatele, že nový branch/fork je lepší. Pokud nebudou vůbec přesvědčiví, původní programátoři to uvidí a budou je ignorovat.

[Fluttershy, yay!]

GitHub, SourceForge,...? Neslyšeli? NIKDY???

AUR, LaunchPad PPA,...? Neslyšeli? NIKDY???

[pavlix]

To co píšeš jsou sice fakta, ale v kontextu mého příspěvku doufám očividná, takže nevím, co si mám vlastně z tvé reakce vzít zajímavého či nového.

[biolog]

GitHub, SourceForge, AUR, LaunchPad PPA... no a? Tyhle nástroje jim něco udělají samy? pavlix: odkud bereš že jsem o nich neslyšel? CAPS LOCK pro silnější argument!

Co si vzít nového? Udělat nový web, vytvořit a zkopírovat bugtracker, mailing-list atd a přesvědčit uživatele je spousta práce. To noví přispěvatelé dělat nechtějí, chtějí programovat (nebo přispívat nějak jinak). Proto taky většina projektů fork nemá, přestože nespokojených přispěvatelů by se našlo. Tedy cesta forku není schůdná, branch v Gitu bez infrastruktury kolem nedostatečný na udělání dojmu na původní autory, tedy dělat si něco sám bez začlenění do původního stromu není zábava.

[Fluttershy, yay!]

Repozitář udělat mohou, ale dokud nevytvoří webstránky, bugtracker, release atd.

GitHub, SourceForge, AUR, LaunchPad PPA... no a? Tyhle nástroje jim něco udělají samy?

Bingo. Součástí minimálně GH a SF jsou tracker a wiki pro každý projekt. Udělat sestavení pomocí AURu nebo zveřejnit balíčky na LP je taky celkem jednoduché.

[pavlix]

pavlix: odkud bereš že jsem o nich neslyšel

biolog, odkud bereš, že něco takového tvrdím? Kup si lepší oči.

[biolog]

dát commit práva každému, kdo si o ně řekne

U git u a podobných je jednodušší udělat si branch na githubu, a nikomu si o práva neříkat. U Subversion a spol by snad nemělo vadit vytvořit extra větev, snad jen problém jak přitom nedat práva do trunku. Samozřejmě zbývá problém se někoho doprosit aby ty změny přetáhl do hlavní větve.

navrhnout software tak, aby byl snadno rozšiřitelný

Tohle je těžké udělat dobře. Pokud základní program má málo funkcí, musí uživatel shánět rozšíření sám. Navíc rozšíření mohou špatně spolupracovat, pokud model spolupráce není určený centrálně. tohle bych doporučil jen velkým projektům.

Ostatní nápady v seznamu jsou žádoucí, ale myslím že situace je momentálně na dobré úrovni.

Nějvíce mě odrazuje to, že nevím, zda mi autoři na patch neodpoví, že:

• uživatel by si to měl dělat ručně
• měl by to měl vědet (že hláška foo znamená bar, že pro smysluplné chování je potřeba přepínač -X, atd)
• měl by přestat řešit svůj problém a snažit vidět krásu nějakého nástroje, strávit s ním víkend atd.

Převážně mě zajímá zvětšení efektivity uživatelů, kteří nejsou experti, a není efektivní, aby jimi byli (protože mají na práci něco jiného).