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

[Michal Čihař]

Nic ti nebrání si pomocí bzr nebo gitu udělat branch svn a vyvíjet lokálně .

[Martin Böhm]

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.

[Michal Čihař]

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í.

[Martin Böhm]

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>

[Käyttäjä 11133]

Když už tak Wikipedia. Wiki je název pro skupinu softwarových produktů.

[Martin Böhm]

To vím. Kdybych napsal Wikipedie, vyčteš mi, že tohle je jedna z vlastností, které děla wiki tak populární :o)

[Käyttäjä 11133]

Njn, už jsem takovej.

[Michal Čihař]

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.

[Michal Čihař]

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).

[Martin Böhm]

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.

[Käyttäjä 11133]

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ň.

[Michal Čihař]

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ší).

[Ctirad Feřtr]

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é ;)

[Martin Böhm]

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.

[Josef Kufner]

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...

[Michal Čihař]

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.

[ajikdpoe]

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.

[Martin Böhm]

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.

[michich]

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í.

[Michal Čihař]

To samé může dělat nad SVN (minimálně bzr, svk a git mu to umožní).

[michich]

No... ano, SVN není úplně ztracený případ, když se napřed převede na git

[disorder]

svn malo byt cvs bez svojich nedostatkov, nie distribuovany. takze aka chyba? navyse to svk je stavane priamo nad svn...

[thingie]

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...

[Michal Čihař]

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 .

[Käyttäjä 11133]

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 :)

[disorder]

tazko povedat, ci by toto niekto dokazal ocenit ako maturitu...

zlaty emacs :P

[Käyttäjä 11133]

Mno když uznali tyhle... :)

[disorder]

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...

[Käyttäjä 11133]

No pokud nenajdu nic dostatečně zajímavého a prospěšného pro linuxovou komunitu tak udělám miliontý první CMS :)

[disorder]

no vidis, teraz uz chapes :D a ked si zvolis spravny jazyk tak to za chvilu mas ;)

[thingie]

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.

[Jan Kundrát (jkt)]

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.

[Martin Böhm]

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í.

[Jan Kundrát (jkt)]

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.

[Martin Böhm]

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.

[Jan Kundrát (jkt)]

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.