openSUSE buildservice - 4 (spolupráce s upstreamem)

7. 11. 2008 | Marek Stopka | Návody | 1988×

openSUSE buildservice obsahuje mnoho projektů, které obsahují obrovské množství balíčků. Občas se stane, že objevíte v nějakém balíčku chybu a nemůžete si dovolit čekat, než ji opraví správce projektu. Z toho důvodu se rozhodnete bastlit patch vlastními silami.

Pokud je patch dostatečně kvalitní, tak jistě chcete v duchu svobodného softwaru ušetřit práci balíčkáři, který za balíček zodpovídá. Jistě, můžete tento patch poslat maintainerovi e-mailem, ale proč to dělat, když má buildservice takovou skvělou funkci, které říká Build Service Collaboration?

Princip spolupráce je poměrně prostý, nejdříve si ve svém domácím namespace home:nick (např. home:m4r3k) vytvoříte branch nadřazeného projektu, ve kterém chcete něco změnit. Pak provedete požadované úpravy a pomocí příkazu osc submitreq provedete odeslání požadavku na začlenění vašich změn. Správci patřičného balíčku v nadřazeném projektu přijde e-mail, ve kterém bude o události informován, a jakmile si najde chvilku, tak provede kontrolu (code-review) a v případě, že nenajde problém, tak vaše úpravy začlení. Pokud problém nalezne, není nic snažšího, než vaše úpravy spolu s komentářem, co musíte ještě opravit/pozměnit, zamítnout.

Poněkud komplikovanější to je, pokud chcete přispívat do projektu openSUSE:Factory. Struktura je následující: Balíčky, které spravuje maintainer A ve Factory, má maintainter také ve svém home:A:Factory (jeden příklad za všechny, Anička, která má pod palcem balíčky jako perlovské moduly, eject nebo openssh, má svůj vývojový strom k testování v projektu s názvem home:anicka:Factory). A to je právě ten repositář, který byste měli branchovat, pokud chcete přispět patchem do některého z balíků ve Factory. Proč to tak je, se dá snadno odpovědět: Aby mohl správce balíček dostatečně otestovat a do distribuce se tak nezavleklo více zbytečných problémů. Jakmile správce uzná, že je balíček dostatečně otestován, provede také osc submitreq. Až bude správcem projektu openSUSE:Factory tento požadavek přijat, tak se změna promítne do openSUSE Factory stromu. Více o struktuře vývoje openSUSE Factory prostřednictvím Collaboration je vidět na těchto slidech.

Praktický příklad

Řekněme, že mám projekt home:m4r3k:R-project a vy mi chcete poslat takový malý, hezký patch na balíček R-base (ten projekt opravdu mám a každý patch je opravdu vítán :-)). Nejdříve pomocí příkazu

marek@mantisha:~/Files/prace/buildservice> osc branch home:m4r3k:R-project R-base
A working copy of the branched package can be checked out with:

osc co home:m4r3k:branches:home:m4r3k:R-project/R-base
marek@mantisha:~/Files/prace/buildservice>

provedete vytvoření virtuální kopie projektu home:m4r3k:R-project ve vašem jmeném prostoru home:nick:branches. Vznikne tak projekt home:nick:branches:home:m4r3k:R-project (např. home:m4r3k:branches:home:m4r3k:R-project) , který má jako sestavovací cíl nastaven projekt home:m4r3k:R-project/openSUSE_11.0, což znamená, že se budou primárně používat balíčky z repositáře home:m4r3k:R-project/openSUSE_11.0 a až poté z jiných repositářů (jako třeba openSUSE_11.0). Nyní si checkoutněte projekt home:nick:branches:home:m4r3k:R-project/R-base příkazem

marek@mantisha:~/Files/prace/buildservice> osc co home:m4r3k:branches:home:m4r3k:R-project/R-base
A    home:m4r3k:branches:home:m4r3k:R-project
A    home:m4r3k:branches:home:m4r3k:R-project/R-base
A    home:m4r3k:branches:home:m4r3k:R-project/R-base/R-2.7.1.tar.lzma
A    home:m4r3k:branches:home:m4r3k:R-project/R-base/R-base.spec
marek@mantisha:~/Files/prace/buildservice>

Když se podíváte na to, co osc stahoval, a pak se podíváte třeba pomocí webového rozhraní do skutečného obsahu nově vytvořené kopie, tak zjistíte, že osc stáhl skutečné soubory ze serveru, kdežto ve vytvořené kopii je jen soubor _link, který již jistě důvěrně znáte z druhého dílu seriálu. Pokud jste četli i třetí díl tohoto seriálu, pak jistě vítě, že soubor _link může obsahovat i různé patche, a to je v podstatě způsob, jak funkce Collaboration funguje. Vždycky, když v branchnutém balíčku něco změníte a provedete osc commit, tak se vygeneruje diff, který se na serveru uloží, a poté se balíček zkusí sestavit i s provedenými změnami.

Zde bych si dovolil apelovat na každého uživatele OBS: Vyzkoušejte prosím nejdříve baliček lokálně pomocí

osc build cílová-distribuce cílová-architektura nějaký.spec

a až poté provádějte commit - šetříte tím cenný strojový čas buildovacích serverů.

Pokud máte zdrojové kódy úspěšně stažené, tak se můžete přesunout do adresáře, kam jste si je stáhli, a provést libovolné úpravy. Přidávat a odebírat soubory, upravovat jednotlivé soubory, ... jakmile své úpravy provedete a patřičně otestujete jak lokálně, tak na buildserveru, není nic snazšího, než je poslat správci nadřazeného projektu kontrole. Napište příkaz

osc submitreq create -m "Nějaká zpráva, nejlépe anglicky"

a systém automaticky vygeneruje zprávu pro správce cílového projektu a pošle mu e-mail, aby o vašem požadavku věděl.

Případně můžete vytvořit požadavek i bez toho, abyste měli stažený obsah repositáře. Provedete to pomocí příkazu

osc submitreq create home:nick:branches:home:m4r3k:R-project R-base home:m4r3k:R.project -m "nějaká zpráva, nejlépe anglicky"

Pohled z druhé strany barikády

Nyní už víte, jak takový "submit request" vytvořit - možná by vás však také zajímalo, co všechno musí udělat správce nadřazeného projektu, aby váš požadavek přijal, nebo zamítl. Opět se nejedná o nic složitého. Když se správce podívá na svou stránku My Projects, tak tam mimo jiné najde část Requests concerning me. Obsahuje všechny submit requesty, u nichž má právo rozhodnout o začlenění, nebo odmítnutí. Každý takový požadavek má své vlastní ID. Prostřednictvím tohoto ID může správce s požadavkem dále pracovat. Například příkazem osc submitreq show -d ID si může maintainer zobrazit, co všechno pozměnil ten, kdo zaslal požadavek. O koho se jedná (tedy zdrojový projekt požadavku), cílový projekt požadavku a zprávu, která byla k požadavku přiložena pomocí parametru -m. Dále se správci zobrazí diff mezi původní verzí balíčku a větví, z níž požadavek přichází. Správce tak má k dispozici všechny důležité informace k tomu, aby mohl o požadavku rozhodnout - zda má skončit v jeho opečovávaném projektu, nebo raději v /dev/null.

Svůj názor na balíček může správce vyjádřit pomocí dvou příkazů - buď příkazem

osc submitreq accept ID

pro přijetí, nebo příkazem

osc submitreq decline -m "jistě je slušné říci, proč požadavek zamítáme, nemyslíte?" ID

poslat požadavek do /dev/null.

Na již zmiňované stránce My Projects vidíte také seznam všech submit requestů, které jste sami vytvořili a které dosud nebyly obslouženy správcem. Nacházejí se v části s nadpisem Requests by me.

       

Komentáře

[Zdenek]

A kde je ta spoluprace s upstreamem? Jak vidim porad je to na pisecku openSUSE buildservice. Autori prislusneho software (tj. upstream) z toho nemaji vubec nic.

[belisarivs]

No asi takhle.

Pro maintainera baliku openSUSE je lepsi poslat opravu upstreamu. Ulehci si praci, protoze pak nemusi svuj patch priohybat na novou verzi programu.

Ja jsem v SUSE vyzyvan nadrizenym at patche do upstreamu posilam. A taky to delam. A nemyslim si, ze bych byl vyjimka.

[Zdenek]

Ja to chapu (jsem upstream :), ale clanek ma v nazvu "spolupráce s upstreamem" a pritom v nem nic takoveho neni.

[Rezza]

Mozna je tu myslen upstream jako originalni balicek...

[Marek Stopka]

To jasně, je to takový dvojsmysl. Běžně to tak na IRCčku označujeme a tak mi to nějak nedošlo.

[Zdenek]

A jak oznacujete upstream?

[Ilfirin]

Skvělý článek (a ještě lepší seriál). Díky.

Jen malinký dotaz. Plánuješ ještě nějaké díly?

[Marek Stopka]

Když mi řekneš co by si se v dalším díle chtěl dozvědět, tak jej můžu napsat.

[Marex]

0verkill ... kosti, maso, ... :-E~~~