Program konference Flock; Časový harmonogram Fedory 21; Předběžné plánování stylu pro Fedora.next; Plánování testů pro Fedora 21; (Brzy) bude potřeba pomoc s kontrolou balíků Software Collections.

(Pozn. redakce: seriál původně vycházi na Fedora Magazine a autorem je Matthew Miller.)

Program konference Flock

Flock je každoroční konference přispěvatelů do Fedory. Letos se bude konat v Praze od 6. do 9. srpna. Program je nyní vystavený na sched.org. Organizátoři si vyhrazují právo na úpravy podle potřeby, ale moc změn už by nastat nemělo.

Loňská konference byla skvělá a myslím, že letošní bude ještě lepší. Na programu je spousta skvělých přednášek, hackfestů a workshopů, které proběhnou v rámci čtyř nabitých dní. Součástí bude také živé „pásmo na chodbě“ a zábavné společenské akce (ještě budou upřesněny). Prostě toho hodně naplánujeme a uděláme hromadu práce – a to vše bude postavené na „Přátelství“, které má Fedora jako součást svého motta. Pokud přispíváte do Fedory a nejste si jistí, jestli přijet, tak přijeďte. Zaregistrujte se na stránce Flocku.

Díky všem, kteří nabídli přednášky, i všem, kdo o těchto návrzích hlasovali. A díky organizátorům Flocku (Josh Boyer, Tom Callaway a Ruth Suehle), kteří na základě hlasování poskládali program. Další dík patří Miro Hrončokovi a Jirkovi Eischmannovi za vyřízení záležitostí ohledně místa konání.

Časový harmonogram Fedory 21

A když už mluvíme o programech… s koncem května přišla vhodná chvíle na připomenutí harmonogramu Fedory 21. Letošní léto bude hodně rychlé! Takže, takhle to bude vypadat:

• 6. června: Mass Rebuild (velká rekompilace). To znamená, že Release Engineering nechá překompilovat každý balíček v distribuci ze zdrojových kódů novými kompilátory a s novými nástroji. Správci balíčků by měli být připravení opravit problémy, které se vyskytnou. (Balíčky, které se nepodaří sestavit a nedostane se jim opravy, budou nakonec z distribuce vyřazeny.)
• 8. července: Change Freeze (zmrazení změn) a Branch from Rawhide (vytvoření větve z Rawhide). To první znamená, že všechny oficiální návrhy změn pro F21 musí být a) dostatečně hotové a v testovatelném stavu a b) ve výchozím nastavení povolené (pokud to odpovídá plánu pro danou změnu). Máme pro toto vydání naplánovaných hodně změn a mnoho z nich se týká velkých nových nápadů pro Fedora.next. To druhé znamená, že se z kódu pro Fedoru 21 stane samostatný repozitář. Všechny změny, které správci balíčků provedou a které budou určené pro F21, projdou běžným postupem aktualizace balíčků — a testeři se tedy budou moci rozhodnout, jestli chtějí přejít na nadcházející vydání, nebo pokračovat s Rawhide a sledovat nejnovější věci, ze kterých se později stane vydání, které přijde po Next.
• 22. července: Alpha Change Deadline (termín pro změny pro alfaverzi) a Software String Freeze (zmrazení řetězců). Termín pro změny znamená, že vše, co by mělo být v alfaverzi, až na přijaté opravy, už by mělo být nachystané. A zmrazení řetězců znamená, že balíčky, pro které je Fedora upstream, by měly přestat měnit věci, které vidí uživatelé, aby měli překladatelé čas na práci.
• 5. srpna: Alpha Release (vydání alfaverze). Zkouška nanečisto pro Fedoru 21 — získáme reálnou představu o tom, jak bude nadcházející vydání vypadat (a co je potřeba ještě doladit).
• 26. srpna: Beta Change Deadline (termín pro změny v betaverzi), Changes 100% Complete (změny stoprocentně hotové) a Software Translation Deadline (termín pro překlady). Podobně jako termín pro alfaverzi, ale vážnější. Navrhované změny, které budou v tuto chvíli pozadu, bude možná nutné přehodnotit nebo posunout do dalšího vydání.
• 9. září: Beta Release (vydání betaverze). Všechno už by mělo mít tvar a více než vývoj nás bude zajímat ladění detailů. Pokud budete mít v tuto chvíli nápad na velkou změnu – prima, vývojový strom Rawhide je tu pro vás.
• 30. září: Final Change Deadline (termín pro poslední změny). Všechny poslední změny by měly být zařazené.
• 14. října: Fedora 21 Finální vydání! Fedora Cloud, Fedora Server, Fedora Workstation a všechny spiny i všechno ostatní bude uvolněno do světa.

Všechna tato data jsou oficiálně uváděná jako „ne dříve než“. Jako vždy, harmonogram může být... pružný... ale obecně se budeme snažit tyto cíle splnit. To znamená už jen 20 týdnů – udělejte si poznámku do kalendářů.

Předběžné plánování stylu pro Fedora.next

Fedora Design Team připravuje plány na prezentaci tří produktů Fedory, které budeme vydávat tento podzim v rámci iniciativy Fedora.next. Každý z nich bude potřebovat své logo, ale také potřebují jednotný vzhled, který z nich udělá součásti projektu Fedora. Máirín Duffy na tom začala pracovat a připravila několik počátečních návrhů, o kterých si můžete přečíst v zápisku Fedora.NEXT Brand Concept #1.

Co si o tom myslíte? Nějaké nápady?

Plánování testů pro Fedora 21

Tyto tři produkty budou také potřebovat otestovat. To je jedním z důvodů, proč je harmonogram delší než šest měsíců. Adam Williamson z týmu Fedora Quality Assurance sepsal návrh plánu testů pro Fedoru 21, ve kterém definoval jednotlivé oblasti práce a kdo je bude mít na starosti. Pokud byste chtěli pomoct (nebo jste jen zvědaví), přečtěte si Adamovu zprávu o tomto návrhu a zapojte se do debaty v konferenci Fedora Test.

(Brzy) bude potřeba pomoc s kontrolou balíků Software Collections

Software Collections je způsob, jak balit software do RPM balíčků, které se nainstalují do /opt, mimo hlavní část distribuce. Hlavním smyslem Software Collections (nebo SCL) je mít k dispozici sadu softwaru, který je vyvíjený v jiném tempu než vlastní distribuce — v RHEL nebo CentOS to většinou znamená rychleji, ale ve Fedoře to může být způsob, jak poskytnout konzistentní běhové prostředí v různých verzích distribuce.

Konkrétně se chystáme mít ve Fedoře 21 Ruby 1.9.3 s Rails 3.2.8 SCL – jde o první experiment, který vede Marcela Mašláňová. Od F21 bude v distribuci Ruby 2.1.x s Rails 4.1, takže tento SCL balík umožní uživatelům, jejichž kód není připravený na novou verzi, přejít na novou Fedoru. Svůj kód si pak budou moci portovat podle toho, jak jim to bude vyhovovat.

Fedora Packaging Committee pracuje na návrhu pravidel, ale zbývající problém je, že těch přibližně 60 balíčků bude muset projít standardním kontrolním procesem. V plánu je provést to tak, aby to bolelo co nejméně – zorganizuje se online testovací den, během kterého se všechny proberou. Pokud už jste někdy balíčky kontrolovali (a ideálně pokud umíte Ruby) a máte zájem pomoci, sledujte konferenci Environments and Stacks, kde se brzy objeví další informace.