Proč je v předmětu zahrnuto/požadováno pochopení nižších úrovní OS/jádra Linux (Proč není náplní jen tvorba aplikací)

Protože pro pochopení a správné využití vrstev vyšších je nutné znát omezení a vlastnosti služeb nad kterými jsou vyšší vrstvy postavené. To si v dnešní době uvědomují i ve velkých firmách a hlubší znalost systému Linux je požadovaná. Zároveň s nástupem Androidu a dalších vestavných systémů s jádrem Linux narůstá výrazně poptávka po vývojářích se znalostí jádra OS a schopností provést jeho adaptaci nebo doplnění o drivery.

Linux hnací silou pracovních příležitostí v IT, Linuxexpres / OpenMagazin Červenec-Srpen, 2012, ISSN: ISSN 1804-1426

Vývojáři se mnou nekomunikují nebo nechtějí mé změny přijmout i když by to projektu prospělo. Mám založit fork?

Založení vlastního forku projektu je volba, která je ve škále možností spolupráce/práce na cizím projektu většinou až ta poslední volba a připadá především v úvahu, pokud se s původními správci nelze dohodnout nebo pokud vám založení vlastní vlastního forku/větve sami doporučí.

Založit vážně míněný fork cizího projektu, který budete publikovat na serverech typu SF.net nebo Freshmeat.net by mělo být pouze vážně míněné rozhodnutí s tím, že se míníte o vývoj dané varianty nebo celého projektu starat delší dobu a převezmete na sebe odpovědnost s řešením chyb, tvorbou dokumentace a správou projektu.

Nenaštvu vývojáře, když publikuji svůj fork v gitu na githubu nebo repo.or.cz?

Lehký/personální branch na git.or.cz nebo jinde pro osobní účely je naopak věc zcela odlišná, jedná se jen o zveřejnění vlastního pískoviště (sandboxu) druhým, aby mohli sledovat, co děláte. V takovém případě není vyjednávání s hlavními autory příliš nutné, ale je potřeba pří posílání odkazů a informací o svém repozitáři uvádět, že se jedná je o váš soukromý fork a že míníte práci po schválení integrovat do hlavní větve.

Vývojáři mi nechtějí dát právo zapisovat do jejich repozitáře. Jak s nimi mám spolupracovat?

Pokud je vám povolen přístup pro zápis do repozitáře cizího projektu (např. na SF.net), tak to je projev značné důvěry správců projektu. V mnoha projektech ale vývoj probíhá následujícím způsobem, kdy je celkem jedno jestli právo zápisu máte nebo ne.

Vývojář (vy) pošle navržené změny do konference (mailing list) projektu jako patch proti aktuálnímu stavu v repozitáři. Patch, pokud není extrémně velký, by měl být zaslán jako čistý text přímo vložený do těla e-mailu. Žádné HTML formátování zprávy a přílohy. Pozor, množství MUA/e-mail programů automaticky volí HTML či mění mezery za tabelátory a naopak. Nepoužívejte takový nebezpečný SW. Takto zaslané patche mají výhodu, že v odpovědi lze připsat poznámky ke konkrétnímu místu patche. Po prodiskutování a schválení vašich změn je pak patch “commitnut” do repozitáře. Pokud máte právo zápisu, uděláte to vy, jinak to udělá někdo jiný. U moderních distribuovaných verzovacích systémů (Git, Darcs) bude přitom informace o vašem autorství úprav zachována. U starších systémů (CVS, Subversion) to zařídit nelze a běžně se vaše jméno objeví jen v poznámce u “commitu”.

Projekt používá verzovací systém, se kterým neumím/nechci pracovat. Co s tím?

Při práci s cizím projektem je správné se přizpůsobit typu repositáře, ve kterém je projekt veden. Některé verzovací systémy (např. git) umožňují import a export do jiných systémů, takže lokálně můžete používat váš oblíbený systém a nikdo jiný o tom nemusí vědět.

Projekt ještě stále používá CVS. Pomoc!!!

Verzovací systém CVS má mnoho nevýhod. Zaprvé se verzují jednotlivé soubory a ne projekt jako celek, takže není jasné jestli spolu změny ve dvou souborech nějak souvisí. Zadruhé není možno přímo držet lokální stav včetně historie a postupně “pushovat” své změny do centrálního repositáře, pokud jsou projektem schváleny.

S CVS tedy pracujete buď tak, že si aktuální stav stáhnete

cvs up -d

uděláte úpravy a vygenerujete patch přes všechny vaše změny

cvs diff -u -N -p > moje-zmena.patch

Po schválení celý patch pošlete do repositáře

cvs commit

Pokud je práci výhodné pro účely diskuze a dokumentování rozdělit na více samostatných změn, tak můžete nasadit quilt patch stack nad CVS. Pokud je práce ještě více, tak je pak asi nejvýhodnější použít import do GITu. Takto jsme třeba importovali do GITu jeden z našich projektů:

export CVS_RSH=ssh
CVSROOT=":ext:ppisa@ulan.cvs.sourceforge.net:/cvsroot/ulan"
CVSMODULE="ulan"

git cvsimport -v -d $CVSROOT -C ulan-devel -i -k -a -r ulan-sf $CVSMODULE

Pak pracovat v GITu a posléze použít git format-patch a patche prodiskutovat a po schválení buď ručně naaplikovat a nacommitovat po jednom na CVS nebo použít git cvsexportcommit.

Rozsah studentské práce asi většinou nebude takto komplexní řešení vyžadovat. Stačí většinou poslat jeden kompletní patch.

Mám posílat své commity na Open HUB nebo do repozitáře na SourceForge?

Pracovat a commitovat budete typicky na SF.net. Open HUB je pouze monitor. Pokud se vám podaří změnu dostat na SF.net, tak se commit automaticky objeví na Ohloh s vaším loginem na SF.net a vy si ho pak přiřadíte k vašemu účtu.