Fedora je velký projekt a je obtížné sledovat, co se v něm všechno děje. Tento seriál vybírá pět zajímavých věcí za poslední týden z pěti různých oblastí. Nejedná se o vyčerpávající zpravodajství, pouze o rychlé souhrny s odkazy. Zde je pět zajímavostí v týdnu před 13. říjnem.

Článek vyšel původně v angličtině na FedoraMagazine.org a autorem je Matthew Miller.

Přibalování – co se změnilo a co je důležité?

Mluvil jsem o přibalování a odbalování v předchozím 5tFTW a taky minulý měsíc. Diskutovali jsme o problémech na Fedora devel listu, v obrovském vláknu se stovkami odpovědí.

„Přibalováním“ rozumíme praxi, kdy softwaroví vývojáři, kteří potřebují části kódu („knihoven“), přibalí kopii do jejich vlastního projektu. Alternativou je použití sdílené verze knihovny z Fedory, ale existuje spousta důvodů (dobrých a špatných, jednoduchých a komplexních) proč tak vývojáři někdy nečiní.

Fedora měla po dlouhou dobu striktní pravidla proti softwaru s přibalenými částmi. Vývojáři, kteří chtěli přidat nějaký program do Fedory, museli zajistit oddělení všech přibalených částí. Buď tak, aby aplikace využívala existující sdílené verze a nebo případně vytvořit balíček zvlášť pro každou knihovnu, která ve Fedoře ještě nebyla. V některých případech udělovalo Fedora Packaging Committee (FPC) výjimky, ale k tomu moc často nedocházelo.

Existují výhody odbalování, jmenujme třeba využité obsazení méně místa na disku a v paměti a potenciálně méně práce, když se objeví bezpečnostní chyba. Ale v praxi si myslím, že to byl příklad kdy dobré řešení zabíjí perfektní, protože lidi se s nimi spokojí, aniž by se snažili o řešení perfektní - držením vysoké laťky jsme ve skutečnosti věci zhoršovali.

Minulý týden schválila FESCo (Engineering Steering Committee) politiku, která pravidla podstatně uvolňuje. Nová politika říká, že software, který může použít systémové knihovny tak musí činit. Odbalování není nicméně už požadováno. Vývojáři starající se o balíčkování musí kontaktovat upstream a zdokumentovat situaci. Všechny přibalené knihovny musejí být navíc přímo v balíčku označeny.

Myslím, že to je pro Fedoru velký krok vpřed, díky kterému bude jednodušší dostat spoustu důležitých programů k uživatelům Fedory. Kromě toho bude taky balíčkování méně odrazující. Pro Fedoru je důležité připustit, že vývojáři nejsou jenom šílení, líní a nebo obojí – i když asi ne všichni budou s tímto závěrem souhlasit. Existují ale rozumné argumenty pro přibalování a je pro nás všechny přínosnější, když budeme vést dialog než považovat jeden způsob za špatný. Chtěl bych ještě zmínit dvě věci.

Za prvé, záměr FESCo byl takový, že to bude základ pro vytvoření nových politik a vše je otevřené úpravám a upřesněním v případě potřeby. Podívejte se (jestli máte zájem) na ticket upřesnění/vylepšení pro novou přibalovací politiku. Doufám, že FESCo a FPC budou spolupracovat na vytvoření nových pokynů, které budou reflektovat otevřenější přístup a pokryjí oblasti, které prozatím nejsou úplně jasné.

Za druhé, to neznamená, že se Fedora vzdala kvalitních balíků a že budeme přibalování podporovat jako nejlepší možný přístup. Na Fedora devel listu existuje návrh na „Odbalovací SIG“ složený z lidí, kteří se o tento problém zajímají a oprávněně budou pracovat odbalování v balíčcích, kde to dává smysl.

Potřebujeme také lepší nástroje. Nyní závisíme na individuálním a manuálním posuzování balíků na odhalení přibalených knihoven. Bylo by mnohem jednodušší, kdybychom kontrolovali všechen náš software, včetně nových verzí. Ve Fedoře je spousta kódu, ale v podstatě mohou počítače tento typ identifikace provádět automaticky a dobře – prozatím však k tomuto nemáme potřebné nástroje. Myslím, že mohu říct, že Fedora s novými pravidly a potřebnými nástroji bude bezpečnější než Fedora se starými pravidly.

Takže krátce, odbalování je mrtvé, ať žije odbalování. Když bude dostatek lidí, kteří budou mít zájem na tom pracovat.

Otevření pro stážisty Outreachy

Outreachy je program stáží, který pomáhá zapojit se v málo zastoupeným lidem ve svobodném a otevřeném softwaru. Tento rok sponzorujeme dvě pozice na práci na Fedoře, jednu financovanou z Red Hat platform engineering a druhou z Fedora community budget. Jestli máte zájem a nebo znáte někoho, kdo by se na to hodil, tak se prosím podívejte na wiki stránku Outreachy 2015.

Jedna z těchto stáží je zaměřená na programování pro Fedora Hubs – znalosti HTML, JavaScript a CSS jsou vyžadovány a znalost Pythonu se taky hodí. Další pozice je na práci v našem novém týmu CommOps (komunitní operace), který pomáhá s marketingem, ambasadory, Fedora Magazine a spoustou dalších věcí.

Diskuze o rozpočtu pro Fedora Council

Fedora Council většinou vede otevřené diskuze, ale občas se konají soukromé rozhovory, když jde o citlivé téma. Někdy to vypadá, že ve světě není nic citlivějšího než peníze. V pondělí jsme měli soukromý rozhovor s Ruth Suehle. Ruth pracuje pro skupinu Open Source and Standards v Red Hatu a zodpovídá za rozpočet pro komunitu Fedory, která financuje třeba konference Flock a FUDCon, Fedora Activity Days a všechny činnosti Fedora Ambassadorů. (Ruth je taky přispěvatelkou do Fedory, předtím pracovala ve Fedora Marketing a měla obrovský podíl na úspěchu konference Flock.)

Poznámky z toho rozhovoru jsem umístil do diskuze Fedora Councilu. Jestli jste součástí Fedora Ambassadorů a nebo by jste chtěli, tak vám doporučuji zapojit se do diskuze. Existuje hodně oblastí, kde můžeme fungovat lépe, na druhou stranu je spousta míst, kde můžeme pomoct utrácením více peněz. Musíme ale společně tvrději pracovat na měření dopadu toho, co děláme, abychom mohli efektivně vyžadovat prostředky a zvládat toho ještě víc.

Stav Fedory 23

Aby se po tom všem výše nezapomnělo, vydání Fedory 23 je za rohem. Včera jsme se dostali do „final freeze“, což znamená, že nemohou být prováděny bez udělení speciální výjimky. Lidi z Release engineering změní vytváření test kandidátů na kandidáty na vydání, což jsou sestavení všech variant Fedory (instalační média pro Fedora Server, live CD pro Fedora Workstation, qcow2 a obrazy AMI pro Fedora Cloud, všechny spiny ARM obrazů a vše ostatní). Jakmile projde kandidát na vydání ověřením vydání QA týmem, označíme jej „zlatý“ a pošleme Vám. Cílové datum je 27. října, což je za méně než 2 týdny v období Halloweenu.

DNF v buildroot

A nakonec technická poznámka pro „balíčkáře“ (a pro ty, které to zajímá):

Pravděpodobně víte, že správce balíků DNF nahradil ve Fedoře Yum – aspoň tedy na nainstalované Fedoře. Sestavovací prostředí, kde se vytvářejí RPM balíky stále používalo Yum, do tohoto týdne. DNF je téměř bezzásahová náhrada Yumu, ale používá úplně jiný přístup k řešení závislostí – to je zjišťování, které balíky daný balík potřebuje, aby mohl být sestaven a nebo spuštěn. Tato změna byla velká věc, protože mohla odhalit problémy balíků, které mohly být skryté tím jak věci řešil Yum. A nebo taky chybami DNF.

Počínaje tímto týdnem, Release Engineering změnil Rawhide (stále se pohybující vývojová větev Fedory) aby se používalo DNF. Vyskytlo se několik problémů, protože ne všechny systémy obsahovaly poslední verzi DNF, ale nyní už by vše mělo být vyřešeno. Pokud si všimnete nějakých problémů, tak o tom napište na development list. (sestavování pro Fedoru 23, Fedoru 22 a EPEL budou i nadále užívat Yum.)