gitlab.freedesktop.org hledá sponzory na udržení funkcionality CI

Daniel Vetter ve zprávě rozeslané do vícero e-mailových konferencí shrnuje situaci kolem financování služeb poskytovaných projektům Freedesktop.org, zvláště spojeným s X.Org (grafické knihovny atp.). Vzhledem k rostoucí popularitě služeb jako CI (Continuous Integration) rostou také náklady na hosting (očekávané výdaje od 75 tisíc dolarů za rok), a proto se hledá sponzor, nebo bude nutné služby v horizontu několika měsíců omezit.

28.2.2020 15:22 | Fluttershy, yay! | Komunita

Komentáře

[n]

A ja myslel ze je to pod zastitou RH.

+1

[n]

No tak jsem si k tomu nasel nekolik odkazu.

• link
• link
• link
• link

a nektere dalsi. Jen nechapu ty vazby? Spi-Inc je soucasny sponzor ale projekt nevlastni?

[pjoter]

> Spi-Inc je soucasny sponzor ale projekt nevlastni?

Je to takovy spravce, legalni entita, podpisuje smlouvy (prebira legalni zodpovednost), vlastni trademarky, domeny, prijima penize, posila penize atd. za nejakou pevne danou % castku, myslim si, ze to je 5% z financniho obnosu

[xkucf03]

Chápu, že hosting něco stojí a vybírat na něj peníze je OK. Ale ta argumentace s CI mi přijde zvláštní. CI a podobné nástroje se přece zavádějí proto, že přinesou úspory a zvýší efektivitu – tzn. nástroj by si na sebe měl „vydělat“ a ta investice by se měla vrátit. Tzn. celková bilance po zavedení CI by měla být kladná, neměla by to být díra, do které mizí peníze. Tedy pokud to funguje tak, jak se slibuje/očekává.

Rozumnější argumentace by byla: dnes pracujeme efektivněji, děláme méně chyb, opravujeme a vyvíjíme rychleji oproti době, kdy byly náklady na infrastrukturu nižší. Toho, kdo to platí, nezajímá nějaké CI, ale právě ta efektivita týmu a výsledky. Pokud ty vyšší náklady nelze obhájit tou vyšší efektivitou, tak prostě smůla – CI si na sebe nevydělalo a zjevně nemá smysl do něj cpát peníze.

P.S. vím, že tohle je takový dost komerční pohled a vybírání dobrovolných příspěvků či sponzorství funguje trochu jinak, nicméně základní pravidla týkající se hospodárnosti a účelnosti investic by měla platit i tady.

[Josef Kufner]

Provoz CI něco stojí. Ve srovnání s hostingem ty servery něco opravdu dělají a nedají se tedy sdílet s ostatními projekty, neboť jsou plně vytížené. Tedy ty náklady jsou znatelně vyšší než na hosting.

Pokud ten projekt vydělává, tak je z čeho CI zaplatit. Takové náklady pak jsou kompenzovány nižšími naklady na vývoj, neboť CI šetří vývojářům práci a tedy vývojáři jsou efektivnější a tedy i levnější. V součtu se tedy provoz CI vyplatí.

Pokud však projekt nevydělává, což je tento případ, tak není z čeho zaplatit provoz CI. Na kompenzaci lepší efektivitou vývojářů už nedojde, neboť je v první řadě potřeba zaplatit ty náklady. Navíc vývojáři na projektu pracují zadarmo, nebo jsou placeni externě jinou firmou, která projekt využívá. Tak či onak v nákladech projektu není co sčítat. Jediné rozumné řešení je sponzorskými dary, ať už finančními nebo ve formě výpočetního výkonu (např. věnováním nevyužitého výkonu firemního cloudu).

[Michal Kubeček]

Což je nakonec svým způsobem právě to, po čem kolega volal: buď se najde někdo, kdo bude ochoten projektu finančně (nebo v "naturáliích") přispět víc, aby bylo možné CI provozovat v plném rozsahu (takže CI "se zaplatí"), nebo bude CI potřeba zrušit nebo omezit.

[m.]

A pokud CI setri praci (tim neprimo naklady), tak bez CI se pri stejnem obemu financi na vyvoj vyvine mene.

[XYY]

To je ale přesně to, že "CI si na sebe vydělalo"

[Josef Kufner]

Jenže pokud je vývoj zadarmo, tak jakákoliv cena za ušetřené náklady na vývoj je příliš vysoká a nezaplatí se. I když to ušetří práci, finančně to prostě nevyjde.

[xkucf03]

Ale ten vývoj není zadarmo. Buď tě na tom projektu nechává pracovat nějaká firma, která tě platí za každou hodinu, kdy se tomu věnuješ, nebo to děláš ve svém „volném“ čase (který jsi mohl věnovat jiným projektům a/nebo vydělávání peněz, zábavě atd. – takže tam máš náklady obětované příležitosti). Tak jako tak jde o to, aby čas věnovaný tomu projektu byl strávený efektivně (když už).

[Fluttershy, yay!]

Jaké příležitosti jsi obětoval psaním komentářů na AbcLinuxu? To například efektivní je: spočívá-li kýžený efekt v existenci komentářů na AbcLinuxu.

[xkucf03]

Viz výše:

ve svém „volném“ čase (který jsi mohl věnovat jiným projektům a/nebo vydělávání peněz, zábavě atd.

Otázka je, jestli má smysl se těchto diskusí účastnit, jestli to stojí za ty náklady obětované příležitosti. Tyhle diskuse beru částečně jako způsob získávání informací a tříbení si myšlenek – a částečně jako zábavu. Vzhledem k tomu, že kouknout do diskuse a napsat komentář, je na chvilku (byť takových chvilek je dohromady hodně), tak to člověk obvykle moc neřeší a často tomu dá přednost před nějakou užitečnější činností (klasická prokrastinace).

Ale vývoj svobodného softwaru takhle spontánně fungovat nemůže – abys vytvořil nějaký smysluplný příspěvek, tak tomu musíš věnovat mnohem víc souvislého času než nějaké diskusi. Tudíž si lidi spíš rozmyslí, jestli do toho ten čas investovat chtějí nebo ne. U těch delších souvislých časových úseků si taky mnohem snáz vyhodnotíš, kolik tě to stálo: „Věnoval jsem X hodin projektu A, ale mohl jsem místo toho dělat B, C, D, … Nebylo by to smysluplnější?“.

[Fluttershy, yay!]

Vše ostatní stranou, už jen uvedený příklad předpokládá trvalé vývojáře a nikoliv kolemjdoucí, kteří chtějí např. opravit chybu, na niž narazili.

[Josef Kufner]

Kolik ten projekt zaplatí za vývojáře? Ať to ten vývojář dělá pro zábavu, nebo ho platí nějaká firma, z pohledu toho projektu je to pořád nulový výdaj. Provoz CI serveru nulový výdaj není. Pokud CI server ušetří 20 % práce, ušetří tím 20 % z nuly výměnou za nenulové náklady.

Nezapomínej, že se tu bavíme o cash-flow daného projektu a jeho existenčních problémech, nikoliv o celkové ekonomice všech zúčastněných stran. Motivace, přínosy a náklady různých účastníků mohou být velmi různorodé, nepřímé a nemusí být finanční, avšak pro přežití projektu je potřeba, aby to finančně fungovalo.

[trekker.dk]

Nebuďte jak ve státním, tam mají taky různé kapsy a na něco peníze jsou a na něco ne, protože špatná kapsa. To, že vývojáře platí firma, není nulový náklad (někdo ty peníze musí dát a třeba je nebude chtít dát, když uvidí prd výsledky.) Nula bude akorát v účetnictví, ten vývojář furt odvede nějakou práci a projektu se zvýší hodnota. O kolik, to záleží na tom, jak efektivně ten vývojář pracuje, což samozřejmě může být argument pro složitější a nákladnější infrastrukturu.

[Josef Kufner]

Jenže když je v účetnictví nula, tak není z čeho zaplatit CI.

[trekker.dk]

Přečtěte si pořádně, na co reagujete, žádná taková příčinná souvislost tam není.

[j]

Ty ses tatar ze?

Kdyz mam holou rit, tak holt nemuzu jet na dovolenou. TECKA. Kdyz na dovolenou (pouzivat CI) jet chci, tak na to NEJDRIV musim mit prachy. TECKA. Rozhodne to nefunguje tak, ze si na web hodim "chci jet na dovolenou, poslete prachy!".

Co na tom nechapes?

A pro ty tupejsi, dovolena snizuje stres, zvysuje tim padem produktivitu prace, a tudiz byste mi ji zaplatit meli. Nebo jeste lip, na dovoleny uz sem byl, tady mate fakturu ... takhle to delas?

[sid]

Tam nejde ani tak o CI ako o traffic.

[Petr]

co to vubec je?

[n]

CI

[Petr]

Ani z toho článku jsem to nepochopil. Samá buzzwords.

Lze to sdělit nějak lidsky ve dvou větách, nebo je to nějaký superhyper koncept, který běžný smrtelník nedokáže pojmout?

[Cabrón]

Zkompiluje a otestuje každý commit, co pošlete do repozitáře, a řekne "dobrý" nebo "špatný".

Správně se to dělá na všech podporovaných platformách (kartézský součin LTS verzí distribuce a podporovaných architektur), takže není vzácné, že jeden commit např. do xorgu vygeneruje desítky hodin CPU času v kompilacích na všech možných architekturách a všech možných verzích knihoven.

[dustin]

Co se stane, kdyby se kompilovalo po každém třeba pátém pushi, příp. častěji on demand? Když CI zdetekuje chybu, příslušný vývojář bude ve většině případů umět najít příčinu i mezi více commity, příp. se pustí bisect. CI nám běží při pushi, nad všemi pushnutými commity. Nalezení problému bývá obvykle jednoduché. Dovedu si představit to spouštět jen jednou denně včas před vygenerováním nějakého devel releasu, aby se to stihle doopravit. Jiné projekty budou mít jiné časování, ale princip je stejný. Chyba se obvykle celkem rychle najde i mezi více commity, vývojáři to ještě mají v hlavě a téměř vždy je jim příčina chyby jasná na první pohled.

Ale věřím, že tak základní otázku mají dávno vyřešenou.

[xkucf03]

Je potřeba vycházet z toho, jaké chyby chceš, aby ti CI odhalilo, a podle toho to nastavit. Jsou např. triviální chyby typu: uživatel zapomene zaverzovat jeden soubor, takže u něj kompilace projde, ale u ostatních už ne, případně to závisí na nějakých jiných souborech u něj na disku, proměnných prostředí, instalovaných balíčcích atd. Ostatní si pak tu chybu stáhnout a nemůžou kompilovat, což je zdržuje (a tohle zdržení se násobí počtem vývojářů, takže čím větší tým, tím spíš je potřeba těmto chybám předcházet). Proti tomuhle je ochrana celkem levná, stačí program sestavit na jedné platformě a většinu těchto chyb vychytáš tak, že danému vývojáři přijde e-mail, že to rozbil a dost možná to stihne opravit dřív, než si ostatní jeho chybu stáhnou. Vývoj může probíhat i v oddělených větvích, takže si to rozbije jen u sebe – push do větví, které používají ostatní bude povolený jen, když sestavení prošlo.

A pak jsou různé obskurní chyby, které se projevují jen za velmi specifických podmínek, např. na big endian platformě s nějakým vzácným CPU a netypickým OS. Na to potřebuješ ten kartézský součin – sestavit produkt na všech podporovaných kombinacích. Ale tohle jsou chyby, které moc často nenastávají a nemá smysl proti nim bojovat tím, že bys dělal sestavení pro všechny kombinace HW/OS/atd. po každém commitu. Tady bývá lepší přijmout určité riziko a ušetřit výrazně výpočetní zdroje – dělat taková sestavení třeba jen jednou za den, nebo jen když se blíží vydání nové verze.

Obecně je vždy potřeba přemýšlet nad tím, kolik mne to stojí a co mi to přinese – porovnávat náklady a výnosy a průběžně ověřovat, že se mi to vyplatí, že platí původní předpoklady z doby, kdy jsme o zavedení daného nástroje rozhodovali. Pokud se dostaneš do situace, kdy ti CI (nebo jiný nástroj) požírá podstatné množství finančních a dalších zdrojů a ty vlastně ani pořádně nevíš, co ti to přináší (jen všude čteš o tom, že všichni daný nástroj používají a je děsně super), tak je něco špatně a je na místě to přehodnotit.

[xxx]

1) Pokud si nekdo rozbiji master a resi to tak, ze tam rychle doda opravu, pak jeho problem neresi CI, ale mel by se zamyslet nad tim, jak a jake prostredky pro vyvoj pouziva. A take jetsli ta spuluprace vyvojaru neni blbe navrzena.

2) Ohledne toho kdy buildit, tak vzdy kdyz se neco prestava byt soukromym piseckem vyvojare a stava se verejne (ve smyslu projektu) dostupnym. v dobe Gitu typicky Pull/Merge request.

3) Ohledne toho co buildit. Tak tady je jednoznacna odpoved: vsechno! Ano, je to drahe, ale bohuzel je to jedine co ma smysl. Chyba se totiz zasadne objevi tam, kde ji nikdo neceka, a ne tam, kde ji ceka. Snaha o usporu tady vede akorat k tomu, ze zisk jde k nule.

Navic uplne opomijis, ze CI neni primarne nastroj pro vyvojare, ale predvsim pro ostatni ucastniky projektu. Testri, QA a predvsim dalsi teamy, ktere tak maji po ruce vzdy vysledky prace ostatnich.

[trekker.dk]

Testri, QA a predvsim dalsi teamy, ktere tak maji po ruce vzdy vysledky prace ostatnich.

Až moc často mám ten pocit, že (nejen) u open source jako testeři slouží uživatelé...

[xkucf03]

S tím nemůžu souhlasit a připomíná to dogmatismus. Náklady by měly být vynaložené účelně – na to přijdeš nejpozději ve chvíli, kdy budeš v roli toho, kdo to platí (a ne jen toho, kdo navrhuje, aby se utratily peníze – např. vývojář či admin ve firmě, který chce, aby mu koupili novou hračku).

Po městě se taky obvykle nepohybuješ v obrněném autě vyzbrojený kulometem jen pro případ, že by tě náhodou mohl někdo přepadnout. Taková ochrana by byla nepřiměřená danému riziku a byly by to neefektivně vynaložené prostředky.

Při vývoji SW máš taky různá rizika. V extrémním případě může někdo zemřít nebo přijít o hodně peněz. U takových systémů má smysl do ochrany investovat hodně. Ale většina rizik při vývoji SW je mnohem menší – nikdo nezemře a přijdeš případně jen o málo peněz + pravděpodobnost, že se to stane, je celkem malá. Tam nemá smysl do ochrany/prevence investovat (nepřiměřeně) mnoho peněz. I ten zákazník s určitou chybovostí nebo občasným zdržením dodávky počítá – a je to pro něj lepší volba, než několikrát vyšší cena. V podstatě nikdo se nespoléhá, že vše půjde 100% podle plánu a jede zcela bez rezerv (pokud ano, tak je to nezodpovědný hazardér).

Co se týče testerů/QA a dalších rolí – ano, ti používají artefakty, které vypadnou z CI, ale nemá např. moc smysl testovat něco, co se může před vydáním ještě pětkrát změnit – výsledek takového testu je téměř k ničemu. Není proto nutné dělat kompletní build po každém commitu/pushi. Pokud máš servery, které se flákají a sestavit celý projekt je pro ně hračka, tak to klidně dělej, je to fajn a ničemu to neškodí. Ale pokud ti tahle zábava začne generovat podstatné náklady, tak to bude jedna z prvních věcí, která se proškrtá, protože ty peníze je účelnější vložit do něčeho jiného (i takové lepší kafe pro vývojáře může mít větší pozitivní efekt).

P.S. Ještě k původnímu tématu: nevím, kolik vývojářů (pracujících naplno) ten CI používá, ale asi jich bude docela dost – tím pádem ty náklady na CI nejsou až tak vysoké a budou tvořit asi jen zlomek nákladů na programátory, takže by neměl být problém to zaplatit. Pozastavoval jsem se primárně nad tou argumentací.

[dustin]

Sleduji diskusi na mailing listu gstreameru, kterého se to také týká, a řeší tam právě optimalizaci, co musí být a jak často. Dosud nebyl důvod to řešit, tak se tím nezdržovali. Vlastně je to docela zdravé.

[xxx]

To neni dogmatismus, ale zkusenosti z praxe. A te je bohuzel takova ze je to bud vsechno nebo nic. Tedy pokud nezvladas buildit "vsechno a vzdycky", jak jsem popsal, pak ten uzitek jde tak rychle dolu, ze za chvili mas vykon=0. Bohuzel se tady vydavas do neprobadanych vod, a rozhodne nelze apriori predpokladat, ze pomer cena/vykon je pri poklesu ceny konstantni. Predstava, ze nekde neco ojebes, klesne ti cena a v nejhorsim i stejne vykon je naivni.

S pristupem, kde vidis pomer cena/vykon jako jedinny parametr se mozna da i souhlasit. Ale mel by jsi se vyhnout takovym tem podvudkum, jako ze v honu za nejlepsim pomerem zacnes bagatelizovat spatny vykon (zákazník s určitou chybovostí nebo občasným zdržením dodávky počítá). Na druhou stranu souhlasim s tim, ze je treba se pohybovat v nejake financni realite. Coz znamena, ze bud mas $ a pak i CI. Nebo nemas $ a pak nemas CI.

Inklinujes k typickemu vydavani "bety"? Tedy v jeden okamzik zamrazis vyvoj, vsichni se vrhnou na testovani vsech zmene od posledni verze, a tohle parkart ziterujes? No, myslel jsem, ze tohle je uz prekonane. Prinos CI je snad v tom, ze v momente, kdy tohle udelas uz mas otestovano, tudiz si nekolik tech iteraci usetris. Navic, jak jsem psal nebuldis vsechno, ale jen to co opousti vyvojaruv pisecek. Tedy merge/pull requesty. A ty uz ma vetsinou duvod i nekdo testovat (resp. bug/funkcionalitu kterou fixuji/pridavaji). Nehlede na to, mame i automaticke testy.

P.S. jsem nejak nerozklicoval

[xkucf03]

Prinos CI je snad v tom, ze v momente, kdy tohle udelas uz mas otestovano, tudiz si nekolik tech iteraci usetris.

Ale ty nemáš otestováno. Testovat musíš přesně tu verzi, která jde k zákazníkovi, jinak nemáš zaručeno vůbec nic. Odněkud ti vypadne .deb/.rpm/.jar/.war/.kar/atd. a ten budeš testovat – pokud testy projdou, tak tento artefakt dáš zákazníkovi jako vydanou verzi. I kdybys tam přidal jediný commit/merge navíc, tak je výsledek předešlých testů k ničemu a musíš testovat znova. Tedy pokud chceš dávat zákazníkovi vydanou verzi s čistým svědomím a jistotou, že jsi nic nezanedbal. Naopak v průběhu vývoje (testovací verze, které nejdou do produkce), se ledasco risknout dá.

Možná jsi to myslel tak, že pokud programátor udělal chybu, tak se odhalí co nejdřív je to možné – tzn. úspěšné testy v této fázi nám neříkají, že finální výsledek bude dobrý (úspěšné testy ignorujeme), ale neúspěšné testy nám říkají, že tam máme chybu a že ji máme jít co nejdřív opravovat. S tímhle souhlasím – už metodiky RUP/OpenUP říkají, že čím dřív se na chybu přijde, tím levnější její oprava bude (nejlevnější oprava je ve fázi vývoje či analýzy zatímco nejdražší oprava je v produkci). Nicméně nevyvozoval bych z toho závěry typu „všechno nebo nic“. Vývojář si může pouštět relevantní část testů a to klidně i u sebe, aby získal dostatečnou (ne 100%, ale z hlediska nákladů a rizik dostatečnou) jistotu, že požadavek implementoval správně a že ho může předat testerům na testy (nemá cenu jim předávat něco, co dost možná nefunguje a plýtvat jejich časem).

Samozřejmě pokud sestavení tvého softwaru je rychlé a náklady na ty servery představují zlomek nákladů na vývoj, tak není problém sestavovat a testovat všechno a nějaký (malý) přínos to mít bude. Ale pokud by náklady na CI byly tak vysoké, že by sis optimalizací (nějakou rozumnou redukcí) toho CI mohl dovolit třeba o programátora nebo testera víc, tak bych asi spíš investoval do lidí než do serverů. Resp. zvažoval bych přínosy obou variant – ale rozhodně bych nebral jako dogma to, že CI musí sestavovat všechno. Pokud jsou jeho přínosy nižší než přínosy jiné varianty, tak nemusí a je lepší vybrat tu druhou variantu.

P.S. jsem nejak nerozklicoval

Ten původní komentář obsahuje větu:

Pokud ty vyšší náklady nelze obhájit tou vyšší efektivitou, tak prostě smůla – CI si na sebe nevydělalo a zjevně nemá smysl do něj cpát peníze.

Jestli to někdo pochopil tak, že jsem proti CI, tak to pochopil špatně. Já jen říkám, že se máme zamyslet nad jeho přínosy a náklady a pokud jsou náklady vyšší, tak to nedává smysl. Jestli jsou v případě freedesktop.org vyšší nebo ne, to je otázka, nevím – snad ne a CI si na sebe vydělá. Ale psal jsem, že má smysl argumentovat právě tímto: vývoj je efektivnější, chybovost nižší, vývojáři udělají víc práce (nebo naopak na projektu budou trávit méně času, ale udělají stejně práce). Jenže zprávička:

Vzhledem k rostoucí popularitě služeb jako CI (Continuous Integration) rostou také náklady na hosting

i původní oznámení:

The good news: gitlab.fd.o has become very popular with our communities, and is used extensively. This especially includes all the CI integration. Modern development process and tooling, yay!

vyznívají tak, že se argumentuje jakousi „popularitou“ a „moderností“. Kdybych byl v roli toho, kdo to má platit, tak by mne tohle fakt neoslovilo a chtěl bych slyšet pádnější důvody, proč do něčeho vrazit peníze. Protože to, že je něco populární a moderní, nebo že někde jedou procesory naplno a protáčí se elektroměr, to samo o sobě žádný přínos není, to je jen náklad.

[j]

Ponekud padly na hlavu, navic se to da vyresit levne a efektivne tim, ze build nebude na serverech. Staci poresis nejaky reporting od vyvojaru. Tzn, pokud nekdo posle patch, nekdo dalsi si aktualizuje svoje repo, a spusti nad tim build, pokud to projde, evidentne je to aspon na dany platforme OK. Timhle zpusobem driv nebo pozdejs dojdu velice levne k temuz, co se snazi nekdo centralizovat.

Navic ses timhle nakladnym zpusoben schopen odhalit jen ty primitivne trivialni chyby. Funkcni chyby se takhle prevazne odhalit vubec nedaji, predevsim prave proto, ze i ty testy pisou ti sami co vlastni kod. A pak to dopada tak, ze 0xACB je prece taky cislo.

[Josef Kufner]

Když se commitnou nějaké změny ve zdrojových kódech do repozitáře, tak CI automaticky zkompiluje ten projekt (a nabídne ho ke stažení), spustí to testy (a upozorní, když neprojdou), nasadí na testovací server a podobně. Co přesně se bude dít je napsáno v konfigurácích toho projektu, CI jen řeší technické detaily a automatizaci kolem.