abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
    dnes 13:33 | Zajímavý článek

    Fedora Magazine rozebírá restartování a offline aktualizování Fedora Linuxu. První Fedora s offline aktualizováním byla v lednu 2013 vydaná Fedora 18. Tenkrát ještě s kódovým označením Spherical Cow.

    Ladislav Hagara | Komentářů: 0
    dnes 12:55 | IT novinky

    The Qt Company dnes představila platformu Qt Digital Advertising 1.0 pro monetizaci Qt aplikací.

    Ladislav Hagara | Komentářů: 0
    včera 22:22 | Nová verze

    Byla vydána nová major verze 5.0 kolekce svobodného softwaru umožňujícího nahrávání, konverzi a streamovaní digitálního zvuku a obrazu FFmpeg (Wikipedie). Jedná se o LTS vydání. Přehled novinek v oznámení a v příspěvku na blogu. Kódové označení Lorentz bylo vybráno na počest Hendrika Lorentze.

    Ladislav Hagara | Komentářů: 0
    včera 09:00 | Nová verze

    Byla vydána nová stabilní verze 1.4.230 (první z řady 1.4.x, viz změna číslování verzí) open source program pro hlasovou komunikaci Mumble (Wikipedie, GitHub). Přehled novinek v příspěvku na blogu.

    Ladislav Hagara | Komentářů: 0
    včera 08:00 | Nová verze

    Byly vydány nové verze JACK Audio Connection Kitu (Wikipedie): JACK1 0.126.0 a JACK2 1.9.20. Nástroje a příklady byly vyčleněny do nového samostatného repozitáře jack-example-tools verze 1. To usnadní balíčkování JACKu a PipeWire (pipewire-jack) v linuxových distribucích. Vydán byl také New Session Manager 1.5.3.

    Ladislav Hagara | Komentářů: 0
    včera 07:00 | Nová verze

    Byla vydána nová verze 7.5.0 správce digitálních fotografií a videí digiKam (Wikipedie). Přehled novinek i s náhledy v oficiálním oznámení. Nejnovější digiKam je ke stažení také jako balíček ve formátu AppImage. Stačí jej stáhnout, nastavit právo ke spuštění a spustit.

    Ladislav Hagara | Komentářů: 2
    včera 06:00 | Nová verze

    Byla vydána verze 9.00 linuxové distribuce SystemRescue, původně SystemRescueCd. Přehled novinek v changelogu. Linux byl povýšen na verzi 5.15.14. Vylepšena byla podpora NTFS.

    Ladislav Hagara | Komentářů: 0
    15.1. 23:44 | IT novinky

    Společnost PINE64 stojící za telefony PinePhone a PinePhone Pro nebo notebooky Pinebook a Pinebook Pro publikovala na svém blogu lednový souhrn novinek (YouTube).

    Ladislav Hagara | Komentářů: 6
    15.1. 23:33 | Komunita

    Uživatelé Linuxu vlastnící audio zařízení od společnosti Universal Audio (Wikipedie) by rádi jejich podporu také v Linuxu. Podepisují petici na Change.org a snaží se Universal Audio přesvědčit v diskusním fóru.

    Ladislav Hagara | Komentářů: 9
    15.1. 14:22 | Nová verze

    Byla vydána verze 8.0.0 knihovny libvirt (Wikipedie) zastřešující různé virtualizační technologie a vytvářející jednotné rozhraní pro správu virtuálních strojů. Přehled novinek v poznámkách k vydání.

    Ladislav Hagara | Komentářů: 0
    Jestliže jste používali distribuci CentOS Linux, jejíž konec byl oznámen před rokem, kam jste přešli?
     (33%)
     (1%)
     (6%)
     (18%)
     (1%)
     (6%)
     (36%)
    Celkem 160 hlasů
     Komentářů: 14, poslední 14.1. 14:44
    Rozcestník

    Zápory správy větších FLOSS projektů, část první

    1.7.2007 14:19 | Přečteno: 1250× | Výběrový blog

    Každý větší svobodný projekt využívá sadu nástrojů a programů, které mu ulehčují jeho existenci. Už v prvních lekcích je budoucím programátorům vysvětlováno, jak správně používat systém pro správu verzí, "bugzillu", mailing listy, IRC kanály a další.

    Tyto nástroje jsou samozřejmě velice prospěšné, mohou však i uškodit. A to hlavně tak, že se používají na úkony, na které by se používat neměly. V dnešním zápisku a několika příštích nastíním několik situací, které jsou podle mého dost nešťastně vyřešeny.

    Dnešní problém: Systém na správu verzí je používán jako řešení přístupových práv.

    Bohužel, ve větších projektech (například v KDE, ale hádám, že i v GNOME a dalších) existuje prakticky jen binární řešení práv: máš přístup k editaci všeho/nemáš přístup k úpravám ničeho. To vede k tomu, že se aktivní komunita rozdělí na "vyvolené" a "plebs" a vzniká v ní tlak (nespokojenost, frustrace). Také to vede k velice přísným pravidlům pro ty, kdo přístup mají. Jistě, taková přísná pravidla mají jistě smysl pro jádro projektu (kdelibs, kdecore), ale takto platí pro celý projekt, včetně trunk/ a playground/.

    První příklad:Bořivoj slyšel o té nové Plasmě v KDE4, četl si pár článků na kde.org a linux.com, a napadlo ho, že by si pár plasmoidů taky napsal. Nakonec ho odradilo, že by musel někoho prosit, aby se jeho plasmoidy dostaly do KDE SVN. Navíc Bořivoj rád commituje i v případě, kdy kód nejde zatím zkompilovat, což v KDE SVN nesmí, jak se dočetl.

    Druhý příklad (z praxe):Frank a Bob jsou kamarádi, kteří se rozhodli napsat skvělý nástroj KFoo pro prostředí KDE. Bohužel, jen Frank má přístup do KDE SVN. I když by Frankovi stačilo, kdyby jeho prvotní kód byl v adresáři playground/, nemůže si správu verzí u KDE dovolit, protože pak by nemohli po večerech s Bobem commitovat vlastnosti, které je zrovna napadly. Nakonec tedy použijí sourceforge.net nebo si založí vlastní VCS server.

    Skrytá hrozba v druhém příkladu je ta, že projekt KDE se tímto distancuje od malých projektíčků, které časem může absorbovat - a nebo taky ne, protože ve světě svobodného softwaru se zklamání příliš netoleruje.

    Řešení: Jedním z možných řešení je přidání více úrovní práv (ať už rozmělněním jednoho SVN, či jinak). "Důvěryhodní" programátoři mají přístup pro zápis i do knihoven, "Nováčci" jen do aplikací. Do playground/ by mohl zapisovat skoro každý.

    Otevřený přístup projektu k nováčkům (někdy se používá pojem hacktivační energie) je velmi důležitý pro zdravý růst komunity. Svobodná encyklopedie Wikipedie je toho důkazem.

    A samozřejmě: překladatelé by měli mít svůj systém úplně jiný, ale o tom až příště.

           

    Hodnocení: 100 %

            špatnédobré        

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    Komentáře

    Vložit další komentář

    1.7.2007 14:33 Michal Čihař | skóre: 61 | blog: Bláboly | Praha
    Rozbalit Rozbalit vše Re: Zápory správy větších FLOSS projektů, část první
    Nic ti nebrání si pomocí bzr nebo gitu udělat branch svn a vyvíjet lokálně :-).
    1.7.2007 14:42 Martin Böhm | skóre: 17 | blog: Martinův stánek | Je mi to MFFUK
    Rozbalit Rozbalit vše Re: Zápory správy větších FLOSS projektů, část první
    Můj zápisek je o tom, kde je to použití nástrojů omezující, a jak by se to mohlo napravit. Pokud sis četl druhý příklad, tak tam je podobný "workaround" popsán poměrně jasně.

    Jak píši výše, skrytý problém není to, že by to nešlo obejít. Problémem je, že to zvyšuje onu "hacktivační energii". A jsem si jist, že pokud existují dva srovnatelné projekty, z nichž jeden si nováčků váží a je velice jednoduché v něm začít vypomáhat, a ten druhý jim hází zbytečné klacky pod nohy, více práce půjde do toho prvního.
    5 z 0 přetečení bufferu doporučuje Korespondenční seminář z programování (pro středoškoláky programátory).
    1.7.2007 15:52 Michal Čihař | skóre: 61 | blog: Bláboly | Praha
    Rozbalit Rozbalit vše Re: Zápory správy větších FLOSS projektů, část první
    Neznám projekt, který by komukoliv hned dal přístup pro zápis do repository. Prostě musí existovat určitá důvěra, že kód který přidáš vypadá rozumně, udržovatelně a nerozbíjí moc jiných věcí.
    1.7.2007 16:06 Martin Böhm | skóre: 17 | blog: Martinův stánek | Je mi to MFFUK
    Rozbalit Rozbalit vše Re: Zápory správy větších FLOSS projektů, část první
    Wiki? :o)

    Nechci se hádat, ale píšu docela jasně, že řešením je "rozvrstvení" přístupových práv, ne jejich anihilace. Dokonce se i zmiňuji o tom, že pro přístup do knihoven současná politika dává smysl. Ta chyba je v tom, že přístupová práva v tomhle případě jsou binární - všechno nebo nic. To taky píšu.

    <vtip>Pokud i Tvoje příští otázka bude už zodpovězena v textu, asi už se neuráčím odpovědět, nezlob se :o)</vtip>
    5 z 0 přetečení bufferu doporučuje Korespondenční seminář z programování (pro středoškoláky programátory).
    1.7.2007 16:17 Käyttäjä 11133 | skóre: 58 | blog: Ajattelee menneisyyttä
    Rozbalit Rozbalit vše Re: Zápory správy větších FLOSS projektů, část první
    Když už tak Wikipedia. Wiki je název pro skupinu softwarových produktů.
    1.7.2007 16:21 Martin Böhm | skóre: 17 | blog: Martinův stánek | Je mi to MFFUK
    Rozbalit Rozbalit vše Re: Zápory správy větších FLOSS projektů, část první
    To vím. Kdybych napsal Wikipedie, vyčteš mi, že tohle je jedna z vlastností, které děla wiki tak populární :o)
    5 z 0 přetečení bufferu doporučuje Korespondenční seminář z programování (pro středoškoláky programátory).
    1.7.2007 16:26 Käyttäjä 11133 | skóre: 58 | blog: Ajattelee menneisyyttä
    Rozbalit Rozbalit vše Re: Zápory správy větších FLOSS projektů, část první
    Njn, už jsem takovej.
    1.7.2007 16:33 Michal Čihař | skóre: 61 | blog: Bláboly | Praha
    Rozbalit Rozbalit vše Re: Zápory správy větších FLOSS projektů, část první
    Psaní textu a psaní kódu je trochu rozdíl. Ve wiki se nic nebezpečného stát nemůže, pokud by "náhodný kolemjdoucí" mohl přispívat do nějakého programu, nebude jeho kód moc důvěryhodný. Pak se totiž může velmi snadno stát, že si tam ten kolemjdoucí přidá nějaký exploitovatelný kód, který hodlá v budoucnu využít. To je ten důvod proč musí existovat určitá vstupní bariéra.
    1.7.2007 16:37 Michal Čihař | skóre: 61 | blog: Bláboly | Praha
    Rozbalit Rozbalit vše Re: Zápory správy větších FLOSS projektů, část první
    A ještě jedna věc - nevidím naprosto žádný důvod, proč by playground pro nováčky mělo být v SVN projektu. Není problém projekt později přemigrovat, pokud za to stojí (viz třeba KMobileTools).
    1.7.2007 16:55 Martin Böhm | skóre: 17 | blog: Martinův stánek | Je mi to MFFUK
    Rozbalit Rozbalit vše Re: Zápory správy větších FLOSS projektů, část první
    Playground není pro nováčky, ale pro projekty, které ještě nemají zavedenou "pozici" ve struktuře KDE, nebo ještě nejsou dostatečně dospělé. Příklad: Plasmoidy pro vývojovou verzi KDE4.
    5 z 0 přetečení bufferu doporučuje Korespondenční seminář z programování (pro středoškoláky programátory).
    1.7.2007 16:40 Käyttäjä 11133 | skóre: 58 | blog: Ajattelee menneisyyttä
    Rozbalit Rozbalit vše Re: Zápory správy větších FLOSS projektů, část první
    Psaní textu a psaní kódu je trochu rozdíl. Ve wiki se nic nebezpečného stát nemůže
    Ne nadarmo se říká, že pero je nejmocnější zbraň.
    1.7.2007 17:06 Michal Čihař | skóre: 61 | blog: Bláboly | Praha
    Rozbalit Rozbalit vše Re: Zápory správy větších FLOSS projektů, část první
    To sice ano, ale když někdo ve wiki narazí na nesmysl, tak ho může okamžitě odstranit. Pokud se vydá exploitovatelný sotftware, tak nejspíš ještě bude žít roky (obzvlášť u menších projektů nikdo ani distribuce bezpečnost moc zásadně neřeší).
    1.7.2007 17:53 Ctirad Feřtr | skóre: 43 | Praha
    Rozbalit Rozbalit vše Re: Zápory správy větších FLOSS projektů, část první
    No spíš se říká, že pero je mocnější meče. Ovšem někteří k tomu dodávají, že pouze pokud je meč velmi malý a pero velmi ostré ;)
    1.7.2007 16:54 Martin Böhm | skóre: 17 | blog: Martinův stánek | Je mi to MFFUK
    Rozbalit Rozbalit vše Re: Zápory správy větších FLOSS projektů, část první
    Věc první: Stejně tak se stalo i ve wikipedii, že si lidé měnili fakta podle svých představ, takže tu podobnost je.

    Nezapomeň, že jsme ve světě VCS. Pokud funguje (a bavíme se o větších projektech) code review, je velice snadné říct "tenhle commit se mi nelíbí" a vrátit změny zpátky. (Tady na tento bod bys mohl zaútočit a začít hovořit o tom, kdo by tedy měl mít jaká práva, ale došli bychom k nějakému "rozvrstvení" práv, které já navrhuji jako řešení problému v článku. Tak tuhle diskusi vynechme.) Jsem si jist, že pokud Ty nebo já budeme chtít dostat backdoor do KDE SVN, můžeme se chvilku vydávat za "hodné" programátory a dostaneme práva na přístup tak jako tak. Jestli se tam backdoor objeví, záleží (dam dam dam) na code review tak či onak.

    Pokud na chvilku zůstaneme u wikipedie, tak skutečnost, že se tam objevují některé nepravdivé změny, je způsobena podle mého tím, že na ni příspívá daleko větší kvantum lidí, než na některé konkrétně zaměřené wiki (Transformers wiki, Starcraft wiki a nevím co ještě). S tím, jak se zvyšuje počet přispěvatelů, roste úměrně velikost "hluku".

    Teď je otázka, co vlastně chceme. Kdybychom mysleli pořád v rámci binárních přístupových práv, můžeme buď práva vypnout (zvětšení přispěvatelů, zvětšení hluku) a nebo je nechat jak jsou - jen pro vyvolené (prakticky eliminujeme hluk za cenu ztráty nových přispěvatelů). Navíc současný způsob práv prakticky likviduje zlaté pravidlo VCS - "commit early, commit often". (Jasně, jak jsi psal, jde to "obejít", ale obejít jde všechno.)

    Já říkám - nemysleme takhle! Udělejme to tak, že do playground/ (na hřiště) má přístup každý, kdo by rád něco programoval! Udělejme to tak, aby každý mini-projekt uvnitř KDE měl vlastní práva (pokud to tedy jde, nejsem odborník přes SVN)!

    Věc druhá: Všiml sis, že celý Tvůj příspěvek reaguje na jediné slovo v mém komentáři, které sloužilo jako příklad a mělo vskutku málo do činění s problémem jako takovým? Snažme se držet diskuzi u tématu, díky moc.
    5 z 0 přetečení bufferu doporučuje Korespondenční seminář z programování (pro středoškoláky programátory).
    Josef Kufner avatar 1.7.2007 16:59 Josef Kufner | skóre: 70
    Rozbalit Rozbalit vše Re: Zápory správy větších FLOSS projektů, část první
    Problém je, že tenhle hluk musí někdo odstraňovat a lidi nejsou. U wikipedie tohle problém není -- lidí je spousta.

    Řešení s rozdělením na malé části, kterým by se nastavovaly práva samostatně je IMHO nejlepší. Stejně až na pár lidí, kteří to dávají dohromady jako celek, nikdo nepíše víc než ty dva nebo tři malé programy...
    Hello world ! Segmentation fault (core dumped)
    1.7.2007 17:11 Michal Čihař | skóre: 61 | blog: Bláboly | Praha
    Rozbalit Rozbalit vše Re: Zápory správy větších FLOSS projektů, část první
    Já se na to prostě dívám z pohledu projektů, které nemají lidi na to filtrovat hluk. V KDE se moc nepohybuju, ale s tím code review bych to neviděl moc růžově…

    A vůbec proč by si každý měl hrát v rámci existujícího projektu? Založit si vlastní projekt na Sourceforge, Berliosu, Google Code nebo kdekoliv jinde je otázka pár kliknutí. Pokud projekt bude za něco stát, je jedno, kde žije.
    1.7.2007 15:23 ajikdpoe | skóre: 23 | blog: dvh
    Rozbalit Rozbalit vše Re: Zápory správy větších FLOSS projektů, část první
    To co tu popisujes je problem centralizovaneho cvs/svn. Odporucam video z nejakeho google meetingu kde Linus T. hovori preco su tvorcovia SVN idioti. V gite taketo problemy nemas.
    1.7.2007 15:38 Martin Böhm | skóre: 17 | blog: Martinův stánek | Je mi to MFFUK
    Rozbalit Rozbalit vše Re: Zápory správy větších FLOSS projektů, část první
    Přiznám se, že jsem ta videa neviděl, ale tohle není chyba SVN jako takového. Tohle je případ použití SVN tak, jak by se nemělo.
    5 z 0 přetečení bufferu doporučuje Korespondenční seminář z programování (pro středoškoláky programátory).
    michich avatar 1.7.2007 16:59 michich | skóre: 51 | blog: ohrivane_parky
    Rozbalit Rozbalit vše Re: Zápory správy větších FLOSS projektů, část první
    Alespoň trochu to je chyba SVN jako takového. V gitu si každý může vyvíjet na svém lokálním písečku, commitovat a větvit kdykoliv. Až když výsledek za něco stojí, tak to buď pošle jako patche, nebo někoho požádá o potáhnutí.
    1.7.2007 17:02 Michal Čihař | skóre: 61 | blog: Bláboly | Praha
    Rozbalit Rozbalit vše Re: Zápory správy větších FLOSS projektů, část první
    To samé může dělat nad SVN (minimálně bzr, svk a git mu to umožní).
    michich avatar 1.7.2007 17:13 michich | skóre: 51 | blog: ohrivane_parky
    Rozbalit Rozbalit vše Re: Zápory správy větších FLOSS projektů, část první
    No... ano, SVN není úplně ztracený případ, když se napřed převede na git :-)
    1.7.2007 17:30 disorder | blog: weblog
    Rozbalit Rozbalit vše Re: Zápory správy větších FLOSS projektů, část první
    svn malo byt cvs bez svojich nedostatkov, nie distribuovany. takze aka chyba? navyse to svk je stavane priamo nad svn...
    1.7.2007 18:05 thingie
    Rozbalit Rozbalit vše Re: Zápory správy větších FLOSS projektů, část první
    No je to chyba. :-) Ano, můžeš argumentovat, že nová parní lokomotiva je zaměřena na vyřešení některých problémů starých parních lokomotiv a proto není vůbec chyba, že je to i tak morálně zastaralý křáp než vůbec vyjede z depa. Ale... :-)
    1.7.2007 15:57 Michal Čihař | skóre: 61 | blog: Bláboly | Praha
    Rozbalit Rozbalit vše Re: Zápory správy větších FLOSS projektů, část první
    Já vím že podle Linuse jsem tuplovaný idiot, protože používám GNOME a Subversion, ale přesto budu reagovat. Je naprosto jedno co se používá pro ukládání hlavní vývojové větve. Ať už je to git nebo Subversion, vždycky existuje jen omezená množina lidí, kteří mohou do oficiálního repository přispívat.

    Naopak běžné věci jako Subversion či CVS umožňují novým lidem se snáze připojit k vývoji, protože je zná víc lidí a nemusí se učit nový úžasný VCS, který si vybral autor projektu. I když už by konečně někdo měl napsat univerzální nadstavbu, která se bude chovat podle toho v jakém repository zrovna jsem :-).
    1.7.2007 16:20 Käyttäjä 11133 | skóre: 58 | blog: Ajattelee menneisyyttä
    Rozbalit Rozbalit vše Re: Zápory správy větších FLOSS projektů, část první
    I když už by konečně někdo měl napsat univerzální nadstavbu, která se bude chovat podle toho v jakém repository zrovna jsem :-)
    To nevypadá marně. Projekt k dlouhodobé maturitě? :) Pouvažuji nad tím :) Zrovna přes prázdniny si chci něco vymyslet a v září si pro to najít nějakého vedoucího, pokud možno by to mělo být ale něco obecnějšího, abych měl alespoň nějakou nenulovou šanci pro to nějakého vedoucího sehnat :)
    1.7.2007 17:35 disorder | blog: weblog
    Rozbalit Rozbalit vše Re: Zápory správy větších FLOSS projektů, část první
    tazko povedat, ci by toto niekto dokazal ocenit ako maturitu...

    zlaty emacs :P
    1.7.2007 18:26 Käyttäjä 11133 | skóre: 58 | blog: Ajattelee menneisyyttä
    Rozbalit Rozbalit vše Re: Zápory správy větších FLOSS projektů, část první
    Mno když uznali tyhle... :)
    1.7.2007 19:10 disorder | blog: weblog
    Rozbalit Rozbalit vše Re: Zápory správy větších FLOSS projektů, část první
    tak schvali sa vselico, ale ked by si robil nieco rozumne a nejak by to vypadalo, tak by bolo vhodne za to dostat patricne ohodnotenie. len si vyber nieco co naoko vyzera tazko a pritom sa na tom nenadres. za maturitu ti to nestoji...
    1.7.2007 20:00 Käyttäjä 11133 | skóre: 58 | blog: Ajattelee menneisyyttä
    Rozbalit Rozbalit vše Re: Zápory správy větších FLOSS projektů, část první
    No pokud nenajdu nic dostatečně zajímavého a prospěšného pro linuxovou komunitu tak udělám miliontý první CMS :)
    1.7.2007 20:20 disorder | blog: weblog
    Rozbalit Rozbalit vše Re: Zápory správy větších FLOSS projektů, část první
    no vidis, teraz uz chapes :D a ked si zvolis spravny jazyk tak to za chvilu mas ;)
    1.7.2007 18:02 thingie
    Rozbalit Rozbalit vše Re: Zápory správy větších FLOSS projektů, část první
    Nemyslím. Distribuované věci jsou funkčně nadmnožina centralizovaných. Tudíž je možné že nějaký konkrétní centralizovaný SCM je lepší než jiný konkrétní distribuovaný, ale ne kvůli tomu, že je centralizovaný. Distribuovaný je lepší a zvládne to samé a víc. To je tak :-)

    Jo, tam ale není jiná výhoda, než že jsou prostě běžné, všude, je k nim milión klikátek a tak. Kdyby (až bude?) byl tak běžný git, třeba, nikdo po nich neštěkne.
    1.7.2007 18:00 Jan Kundrát (jkt) | skóre: 27 | blog: jkt | Praha - Bohnice
    Rozbalit Rozbalit vše Re: Zápory správy větších FLOSS projektů, část první
    V blogpostu jsi citoval KDE. Vzhledem k tomu, ze jsem tam dostal commit access pomerne nedavno, reknu k tomu asi tohle:

    1) Provoz SVN neco stoji. Musis to bezet na nejakem rozumnem stroji, ktery je dostatecne spolehlivy, dostatecne vykonny, ma k dispozici velky a spolehlivy storage a dobrou sitovou konektivitu. Taky potrebujes mit *velice* dobrou zalohovaci politiku. Pokud budes rozdavat commit access, budes miot problemy s vykonem. Takovou wikipedii muzes krasne paralelizovat a clusterovat, u vetsiny VCS tohle nepujde. Jedine, co muzes nabidnout, je anonymni read-only pristup (coz naprosta vetsina projektu dela), typicky nejaky s malym zpozdenim synchronizovany mirror. Nacvakat tucet RO replik je uz pouze financi problem, skalovat RW pristup je vyrazne narocnejsi.

    2) Predstava, ze kazdy commit nekdo kontroluje, je nesmyslna. Nekontroluje.

    3) I kdyby ho nekdo kontroloval, nebude to bez chyb. Posledni uzivatelsky patch, ktery jsem commitoval, kontrolovali krome me dalsi tri lidi, a stejne obsahoval dost podstatnou chybu vedouci k mozne ztrate dat. Patch byl na jednu nebo dve stranky, jeho autor je "dlouholety prispevatel" s velmi dobrou historii.

    4) Pokud by mel pristup kazdy Lojza, nebezpeci neni ani tak v tom, ze by vkladal skodlivy kod, ale spis v tom, ze si dany repozitar zneuzije pro sve soukrome ucely. Jakou vyhodu by melo to, ze si kazdy bude moct zkusit napsat KDE4 aplikaci pro vyber barev podle RGB se trema scrollbarama?

    5) Vubec, proc by melo KDE, e.v. (nebo jak se jmenujou) sponzorovat Frantu Programatora ve vyvoji jeho Super Aplikace, kterou pouzije pet dalsich lidi, a kterou Franta za tri mesice prestane udrzovat?

    6) KDE aplikace se mohou bez problemu vyvijet mimo KDE SVN. Jake tak strasne dulezite vyhody vyvoj v "upstream VCS" prinasi?

    7) K prikladu s "kamaradem, co by chtel taky prispivat, ale jeste nemuze" -- ja jsem zacinal tak, ze jsem nasel hezky program, prihlasil se do jeho ML, v irssi napsal /join #kphotoalbum, na neco se zeptal a uvidel, ze to ma nejaky nedostatky. Poslal jsem par patchu, nacez mi hlavni vyvojar nabidnul, jestli nechci commit access. Nejdriv jsem nechtel, ale za pomerne kratkou dobu me presvedcil. Ted do zmineneho kusu SW pisu ve vlastnim branchi nejakou delsi dobu zadanou featuru, tu a tam v trunku opravim nejaky bug, pripadne aplikuju neci patch, a take si bokem (ve vlastni SVN) vyvijim webove prohlizitko databazi vytvorenych timto programem. Je mozne, ze ho nekdy presunu do KDE SVN.

    8) Prispivani do nejakeho trosku komplikovanejsiho projektu neni jednoduchy, nejakou dobu trva, nez proniknes do kodu, nez zjistis, proc se neco resi tak starsne divne, a ze to treba jinak nejde, a ze ta "oprava", kvuli ktere jsi vlastne zacal, jednoduse napsat nepujde, protoze to jednoduche reseni by pokazilo tri dalsi veci. Kdyz bys mel anonymni rw pristup, prvni Lojza, co by umel napsat `svn commit`, by commitnul ten "jednoduchy" fix.

    9) Ano, v policy sice je, ze nekompilovatelny kod se commitovat nema, ale kazde pravidlo ma vyjimky. Typicky mame aplikaci pro KDE3 a Qt3, portujeme ji na Qt4/KDE4. Neco zvladnou automatizovane nastroje, neco se dela rucne. Po kazdem pusteni nejakeho automatickeho toolu se kod commituje, i kdyz zdaleka neni kompilovatelny. Tohle se samozrejme nedeje v "produkcni" vetvi, ve ktere se normalne orpavuji bugy, ale v necem dedikovanem. Je jedno, jestli tomu rikame trunk a nebo branches/sandbox/testing/foobar, ale proste se vicemene pocita s tim, ze to je obcas rozbity.
    1.7.2007 18:30 Martin Böhm | skóre: 17 | blog: Martinův stánek | Je mi to MFFUK
    Rozbalit Rozbalit vše Re: Zápory správy větších FLOSS projektů, část první
    Díky za názor.

    1) Zase myslíš binárně. Rozšiřovat commit access je věc jedna, rozložit jednu megavětev na víc častí s vlastními právy, třeba i oddělených, věc druhá. Nespravuji žádný SVN server, takže v tomhle nejsem správná kapacita. Nevím, jaké řešení je technicky i lidsky nejvýhodnější, ale tohle se mi nezdá. Do financí KDE taky nevidím - ale nemyslím si, že je lepší nechat systém uzavřený pro nováčky a ušetřit. Ale zas úplně na dně nebudou, sponzorů KDE je poměrně hodně.

    2) To jistě je - zmiňuju to snad někde? Pokud by ale se Jan Programátor najednou rozhodl commitnout něco třeba v Adeptu, věř mi, že to někdo zkontroluje.

    3) viz 2)

    4) Takže je lepší zamezit přístup Lojzovi úplně, jenom pokud pošle emailem pár dobrých patchů? (Omlouvám se všem, kteří stále ještě posílají patche emailem a myslí si, že je to správný postup.)

    5) Sponzorovat? Ne že by commiterům nějak platilo. Proč by ho měl sponzorovat Sourceforge? Launchpad? Odpověz na tyhle dvě otázky a dovtípíš se, proč by to mohlo dělat i KDE. Je to otázka úplně mimo diskuzi.

    6) Viz moje plky na téma "skrytý problém" v článku a v komentářích. Už jsem o tom naplkal docela dost :o)

    7) Gratuluji k Tvým příspěvkům do KDE. Jsem za ně rád. Pokud jde o samotný příklad - samozřejmě, že to takhle jde, i moje příklady naznačily, že pracovat se dá i v současném stavu. Ale "hacktivační energie" je vyšší, než by mohla být. Pokud jde o můj příklad, tak tam šlo třeba o to, že člověk chce s něčím pomoci, ale spousta informací se ztratí, protože ti dva musí spolu pracovat jinde, než na KDE SVN ... ale i o další věci.

    8) Napsat takový plasmoid je komplikované? To bych neřekl. Obecně většinou platí, že lidi "commitují" jen to, o co mají zájem, a mají zájem o to, čemuž už trochu rozumí. Samozřejmě, jen tak patchovat kdelibs není nejjednodušší, a neříkám, že by kontrola přístupu vypnutá.

    9) Není lepší upravit pravidla, aby byla pravdivá, než je beze slov obcházet? Není lepší upravit přístup nováčků, aby byl co nejjednodušší, než abychom je strašili pravidly? Můj příspěvek v kostce :o)

    PS: Pokud se někomu zdá, že autor je zneuznalý programátor, kterému odmítli commit access do KDE SVN a teď se mstí, tak tomu tak není.
    5 z 0 přetečení bufferu doporučuje Korespondenční seminář z programování (pro středoškoláky programátory).
    1.7.2007 20:23 Jan Kundrát (jkt) | skóre: 27 | blog: jkt | Praha - Bohnice
    Rozbalit Rozbalit vše Re: Zápory správy větších FLOSS projektů, část první
    Díky za názor.
    Diky za pomerne zajimavy blogpost.
    1) Zase myslíš binárně. Rozšiřovat commit access je věc jedna, rozložit jednu megavětev na víc častí s vlastními právy, třeba i oddělených, věc druhá. Nespravuji žádný SVN server, takže v tomhle nejsem správná kapacita. Nevím, jaké řešení je technicky i lidsky nejvýhodnější, ale tohle se mi nezdá. Do financí KDE taky nevidím - ale nemyslím si, že je lepší nechat systém uzavřený pro nováčky a ušetřit. Ale zas úplně na dně nebudou, sponzorů KDE je poměrně hodně.
    Pokud je mi znamo, SVN nema rada mergovani "napric repozitarema", tudiz je vicemene podminka, aby bylo vsecko spolu souvisejici v jednom strome, ktery musi byt na jednom stroji. P:ointa bodu jedna je to, ze RW access je fakt drahy.
    4) Takže je lepší zamezit přístup Lojzovi úplně, jenom pokud pošle emailem pár dobrých patchů? (Omlouvám se všem, kteří stále ještě posílají patche emailem a myslí si, že je to správný postup.)
    Ano, je to lepsi (jenom tedy pripominam, ze se nebavime o zamezovani pristupu, ale jsme v situaci, kdy si projekt svuj kod dela na sve infrastrukture a nechce ji zpristupnit *pro zapis* anonymnim uzivatelum). Ma-li user prispet peti patchy a pak se na to vykaslat, je zbytecne mu davat commit access. Patch mailem neni zas tak komplikovany prece... A kdyz uz jsme u toho, jestli ho ulozim z meho MUA a napisu `patch -p0 < nejaka-priloha-mailu` a nebo `favorite-scm --pull-changes scm://franta/blesmrt/trojita/s/matovou/omackou` je celkem jedno...
    5) Sponzorovat? Ne že by commiterům nějak platilo. Proč by ho měl sponzorovat Sourceforge? Launchpad? Odpověz na tyhle dvě otázky a dovtípíš se, proč by to mohlo dělat i KDE. Je to otázka úplně mimo diskuzi.
    Aha, vyjadril jsem se nejednoznacne. "Sponzorovat" nikoli penezmi, ale infrastrukturou, viz bod 1. Navic "mit aplikaci v KDE SVN" ma nektere dlouhodobe vyhody (treba ti provozuji zalohovani, bugzillu, prekladaji dokumentaci a tak).
    6) Viz moje plky na téma "skrytý problém" v článku a v komentářích. Už jsem o tom naplkal docela dost :o)
    Muzu poprosit o link? Mozna upresnim dotaz, necht zni "v cem je vyvoj third-party aplikaci pro KDE mimo KDE SVN omezujici?"
    7) Gratuluji k Tvým příspěvkům do KDE. Jsem za ně rád. Pokud jde o samotný příklad - samozřejmě, že to takhle jde, i moje příklady naznačily, že pracovat se dá i v současném stavu. Ale "hacktivační energie" je vyšší, než by mohla být. Pokud jde o můj příklad, tak tam šlo třeba o to, že člověk chce s něčím pomoci, ale spousta informací se ztratí, protože ti dva musí spolu pracovat jinde, než na KDE SVN ... ale i o další věci.
    Aha, zase jsem se nevymack dobre, snad to neznelo jako honeni trika. Zkusim to jinak -- commit access do KDE SVN *neni* ostre strezene zbozi. Pokud nekdo (typicky nejaky pokrocily KDE programator) potka nekoho, kdo je aktivni, neco umi a je videt, ze jeho prispevky maji hodnotu, tak podle me zkusenosti onen "novacek" dostane commit access velice rychle. Takze dle meho nazoru (podepreneho osobni zkusenosti s kphotoalbum tebou popisovane problemy v KDE nejsou.

    Nicmene honme triko dal -- jsem developer z Gentoo, staram se o preklady ceske dokumentace. Gentoo je pomerne zname tim, ehm, dejme tomu "vysokym prahem pro rozdavani commit accessu", nicmene zase je to dano prakticko-technickymi duvody, vedle bezpecnosti infrastruktury jde o to, ze zatimco v "bezne programovaci praxy" mas typicky nejake pre-release snapshoty pred vydanim samotneho programu a na vydani nove verze se pracuje radove dny, tydny az mesice, doba mezi commitem do Gentoo CVS a stazenim balicku uzivateli je v hodinach. Doufam, ze neni potreba rozebirat, ze povoleni commitu do teto repository je pomerne kriticke, takze adept musi absolvovat nejake kvizy, mit sveho "skolitele" atd. A prave ti "skolitele" maji s "novacky" hafo prace, a proto se typicky pozaduje spousta odvedene prace prave prostrednictvim "posilani patchu mailem" (zde teda rpes bugzillu), nez ti nekdo nabidne, jestli se nechces stat vyvojarem.
    8) Napsat takový plasmoid je komplikované? To bych neřekl. Obecně většinou platí, že lidi "commitují" jen to, o co mají zájem, a mají zájem o to, čemuž už trochu rozumí.
    Vida, je to jednoduche. Kdyz je to jednoduche, zrejme to bude dost malo radku kodu, vyvoj bude typicky kratky a jakmile to bude napsane, nebude do toho potreba nejakou dobu sahat. Proc by teda mel clovek kvuli de-facto jednorazovemu commitu dostat pristup (coz, jak se opakuji, proste stoji penize a cas spousty lidi)? On ten svuj plasmoid muze klidne poslat mailem nebo submitnout do bugzilly.
    Samozřejmě, jen tak patchovat kdelibs není nejjednodušší, a neříkám, že by kontrola přístupu vypnutá.
    Coz zase zavani cenzurou a zvedne kritiku druhe pulky lidi.
    9) Není lepší upravit pravidla, aby byla pravdivá, než je beze slov obcházet?
    Priznam se, ze si pravidla nepamatuju, takze je docela mozne, ze ono "necommitujte nezkompilovatelne" je formulovano jinak. Kazdopadne snad kazdy rozumny clovek chape, ze pravidla jsou k tomu, aby dala jakousi orientaci, pomocnou ruku, a ze se *vzdy* da najit vyjimka, a ze *sebelepsi* pravidla nebudou dokonala. Takze prosim s kritikou pravidel pockej do te doby, nez te za jejich "ferove prekroceni" serve, coz se ti, doufam, nestane.

    Není lepší upravit přístup nováčků, aby byl co nejjednodušší, než abychom je strašili pravidly? Můj příspěvek v kostce :o)
    Pristup k hotovemu programu -- dle meho pozorovani je snadny uz ted. Tvorba noveho programu -- neni duvod, aby byl hned od pocatku v KDE SVN.
    1.7.2007 21:24 Martin Böhm | skóre: 17 | blog: Martinův stánek | Je mi to MFFUK
    Rozbalit Rozbalit vše Re: Zápory správy větších FLOSS projektů, část první
    Pokud je mi znamo, SVN nema rada mergovani "napric repozitarema", tudiz je vicemene podminka, aby bylo vsecko spolu souvisejici v jednom strome, ktery musi byt na jednom stroji. P:ointa bodu jedna je to, ze RW access je fakt drahy.
    To trochu souvisí s polemikou o centralizovaných a decentralizovaných VCS o pár komentářů výše. Trochu to nahrává těm decentralizovaným systémům (nemusí se mirrorovat všechno všude pro zápis).
    Ma-li user prispet peti patchy a pak se na to vykaslat, je zbytecne mu davat commit access. Patch mailem neni zas tak komplikovany prece... A kdyz uz jsme u toho, jestli ho ulozim z meho MUA a napisu `patch -p0 < nejaka-priloha-mailu` a nebo `favorite-scm --pull-changes scm://franta/blesmrt/trojita/s/matovou/omackou` je celkem jedno...
    Příjde mi, že už drahnou dobu nejsi nováčkem, stejně jako já :o) Správa patchů pomocí emailů není nemožná, je to jen zbytečně složitá. Takové hloupoučké přirovnání: buď počítači řekneš, ať se aktualizuje, nebo si necháš poslat poštou CD s updaty a pak to nainstaluješ ručně. Čím méně příkazů musím napsat, čím méně příloh musím stahovat, tím lépe. Alespoň pro mne.

    Asi bych si na email měl vyhradit samostatný blogpost.

    Myslím si také, že u FLOSS projektů nejde jen o samotný kód a nástroje, ale také o přístup. Pokud projekt bude mít všechno nastavené, ale jeho vývojový tým bude nepřátelský a nebude chtít nováčky přijímat, je jasné, že tomu projektu se moc dobře vést nebude. Na druhou stranu takový projekt, který bude mít příjemné webové stránky, přátelskou komunitu a nedej bože taky nějaký Marketing tým, na sebe strhne hodně pozornosti. Protože KDE aktivně používám, byl bych rád, aby i jeho vztahy s veřejností, i jeho nástroje byly stejně na úrovni, jako je samotný kód.

    Stejně jako leckterá distribuce je vlídná k nováčkům, měly by být i softwarové projekty vlídné k nováčkům programátorům. Člověk by se měl cítit jako doma, ať už v IRC kanálu, na mailing listu nebo i v samotném VCS. Nikde by ho neměly stresovat přísnými pravidly či politikami. Pokud chce přispět, ať přispěje, a nikdo mu za to nemá trhat hlavu. Neměli by být děšeni, že jejich prosba o lepší infrastrukturu "stojí čas a peníze spoustu lidí". Takhle chudáky dobrovolníky, co si to tu čtou, nestraš. To stanovisko je nadsazené, zas tolik peněz to nestojí - podívej se, kolik firem to nabízí, a asi z toho nekrachují (a některé i bez reklam apod.).

    Pokud si mohu vybrat, jak chci, aby se cítili dobrovolníci v FLOSS projektu, tak řeknu "jako doma" - no a doma mi rozhodně nikdo nevyčítá, že ho "stojím čas a peníze". Hrůzná myšlenka, nemyslíš? :o)

    Vývoj odděleně by byl fajn, jenže tato "oddělenost" projektu jen škodí, místo aby pomáhala. Kdyby bylo jednotné místo pro všechny KDE projekty (ach, ty ideály), mohl bych si po práci na svém KFoo pohrát s Frankovým KBar, opravit pár chyb, udělat commit nebo dva. Hodně lidí ztrácí motivaci taky proto, že má pocit, že není vítáno. To vím z vlastní zkušenosti.

    Jasně, proč by tu nemohlo být nějaké externí VCS, na které by se z kde.org odkazovalo a které by mohlo hostovat VCS pro maličké projekty (no, i 300 řádek je hodno commitu). Taky dobré řešení. Jenže mám strach, že takové věci v KDE málokdo řeší. Nezapomeňme, že nešvary nejsou vidět zevnitř, ale hlavně zvenku. Když zaplátujeme tyto chyby ( odstraníme elitární infrastrukturu, "otevřeme se" nováčkům, ať už jakkoli), dostaneme další pracovní sílu, která nám pomůže zaplátovat chyby v kódu.

    Při čtení Tvého příspěvku jsem se sám zalekl, kolik "přísných testů" musí překladatel dokumentace do češtiny v Gentoo podstoupit. "Honění trika" bych se vyhnul úplně - kdyby Richard Feynman honil triko před Nielsem Bohrem, asi by takoví kamarádi nebyli.
    5 z 0 přetečení bufferu doporučuje Korespondenční seminář z programování (pro středoškoláky programátory).
    1.7.2007 22:43 Jan Kundrát (jkt) | skóre: 27 | blog: jkt | Praha - Bohnice
    Rozbalit Rozbalit vše Re: Zápory správy větších FLOSS projektů, část první
    Správa patchů pomocí emailů není nemožná, je to jen zbytečně složitá. Takové hloupoučké přirovnání: buď počítači řekneš, ať se aktualizuje, nebo si necháš poslat poštou CD s updaty a pak to nainstaluješ ručně. Čím méně příkazů musím napsat, čím méně příloh musím stahovat, tím lépe. Alespoň pro mne.
    Jasne, dlouhodobe je to blbost. Ale proste je jednodussi nechat potencialniho prispevatele nechat absolvovat uvodnich X dbi/tyndu/mesicu posilani patchu mailem/pres bugzillu a pak mu dat commit. Z jisteho hlediska to dokonce muze nektere uzivatele motivovat. Ja si vzpominam, ze kdyz jsem pred par lety zacinal v Gentoo, chtel jsem mit @gentoo.org mail :). Takze IMHO ta "prestiz" nebo "odmena" muze mit neco do sebe.

    Jeste jednou, dlouhodobe posilani mailu s patchema mi prijde jako velky opruz, ale z kratkodobeho hlediska to (pripadne rpes bugzillu) proste funguje.
    Myslím si také, že u FLOSS projektů nejde jen o samotný kód a nástroje, ale také o přístup. Pokud projekt bude mít všechno nastavené, ale jeho vývojový tým bude nepřátelský a nebude chtít nováčky přijímat, je jasné, že tomu projektu se moc dobře vést nebude. Na druhou stranu takový projekt, který bude mít příjemné webové stránky, přátelskou komunitu a nedej bože taky nějaký Marketing tým, na sebe strhne hodně pozornosti. Protože KDE aktivně používám, byl bych rád, aby i jeho vztahy s veřejností, i jeho nástroje byly stejně na úrovni, jako je samotný kód.
    Jiste. Na druhou stranu to ale neznamena, ze kdyz nekdo neco po#$%^&, tak mu to (slusne, s uctou a respektem) nevysvetli.
    Nikde by ho neměly stresovat přísnými pravidly či politikami. Pokud chce přispět, ať přispěje, a nikdo mu za to nemá trhat hlavu.
    Ano, ale ten prispevek ma v prvni rade prospet danemu projektu. Uprimne receno neverim, ze tuna primitivnich Plasma aplikaci je to, co KDE potrebuje...
    Neměli by být děšeni, že jejich prosba o lepší infrastrukturu "stojí čas a peníze spoustu lidí". Takhle chudáky dobrovolníky, co si to tu čtou, nestraš. To stanovisko je nadsazené, zas tolik peněz to nestojí - podívej se, kolik firem to nabízí, a asi z toho nekrachují (a některé i bez reklam apod.).
    Je hezke, co sourceforge dela zadarmo. Nezapomen ale, ze SF pouziva uplne jine technologicke reseni. SF je spousta malych projektu, proto muze zcela bez problemu paralelizovat, coz KDE (ktery ma vsechno v jedne obrovske SVN repository) proste nemuze.

    Rozhodne nechci potencialni contributory vystrasit, ale vidim, ze navrhujes neco, co podle meho nazoru a) se nevyplati, b) je zbytecne, c) nebude mit kyzeny efekt.
    Pokud si mohu vybrat, jak chci, aby se cítili dobrovolníci v FLOSS projektu, tak řeknu "jako doma" - no a doma mi rozhodně nikdo nevyčítá, že ho "stojím čas a peníze". Hrůzná myšlenka, nemyslíš? :o)
    Ted nechapu, proc tohle pises. Bud jsem se seredne spatne vyjadril, nebo jsi to nepochopil a nebo prekroutil.
    Vývoj odděleně by byl fajn, jenže tato "oddělenost" projektu jen škodí, místo aby pomáhala. Kdyby bylo jednotné místo pro všechny KDE projekty (ach, ty ideály), mohl bych si po práci na svém KFoo pohrát s Frankovým KBar, opravit pár chyb, udělat commit nebo dva. Hodně lidí ztrácí motivaci taky proto, že má pocit, že není vítáno. To vím z vlastní zkušenosti.
    Uvadis nejake tvrzeni, ale jeste jsi ho nicim nedolozil. Co konkretne je spatne na tom, ze si lidi vyvijeji svoje KDE aplikace bokem od oficialniho KDE? Tvoje idea je sice hezka, ale dokazu si predstavit spoustu lidi, co z nejruznejsich duvodu (od technickych po politicke) proste do KDE SVN nechteji. Pokud by byl model natolik otevreny, ze by mohl commitovat opravdu *kdokoli* bez jakekoli predchozi, ehm, "prirozene selekce", verim, ze by spousta projektu z podobneho prostredi utekla, protoze proste lidi nechteji, aby se jim v jejich kodu vrtal nekdo, koho neznaji. Vsechno je nakonec o lidech a teprve potom o financich ci technologii, ze.
    Jasně, proč by tu nemohlo být nějaké externí VCS, na které by se z kde.org odkazovalo a které by mohlo hostovat VCS pro maličké projekty (no, i 300 řádek je hodno commitu). Taky dobré řešení. Jenže mám strach, že takové věci v KDE málokdo řeší.
    Pozor, prijde obvykla reakce na podobne navrhy :) -- je skvele, ze vidis moznost zlepseni. Zkus to. Rozjed nejake VCS pro KDE projekty, nabidni vyvojarum vyhody, ktere je presvedci migrovat kod ze SF/Berliosu/Googlu k tobe, nabidni jim srovnatelne nebo lepsi sluzby, sezen si na ne sponzory. Nikdo z KDE to (afaik) nedela, zrejme proto, ze proste nema motivaci nebo se mu to nezda. Pokud veris, ze to je dobry napad, jdi do toho.
    Nezapomeňme, že nešvary nejsou vidět zevnitř, ale hlavně zvenku. Když zaplátujeme tyto chyby ( odstraníme elitární infrastrukturu, "otevřeme se" nováčkům, ať už jakkoli), dostaneme další pracovní sílu, která nám pomůže zaplátovat chyby v kódu.
    Otazka je, jestli opravdu chceme masy "zaplatovacu", kteri budou commitovat vicemene bez uvazeni, a nebo jestli chceme mene kvalitnich programatoru, kteri jsou vysoce motivovani, protoze prekonali uvodni prudu posilani patchu mailem.
    Při čtení Tvého příspěvku jsem se sám zalekl, kolik "přísných testů" musí překladatel dokumentace do češtiny v Gentoo podstoupit.
    Popsana procedura plati pro "balickovace", tedy lidi, co pracuji s ebuildy (=balicky, +/-). na prekladech muze spolupracovat kdokoliv, pristup do CVS se rozdava zpravidla po mesici (ci nekolika malo mesicich) vyrovnane aktivity.

    Založit nové vláknoNahoru

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.