[[!meta title="Poznámky a odkazy"]]

Poznámky k práci s cizím OSS projektem
=====================================

Při práci s cizím projektem je správné se přizpůsobit typu
repositáře, ve kterém je projekt veden. Založení vlastního
forku projektu je možnost, která je ve škále možností celkem
na konci seznamu možností 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í větve sami doporučí. Založit vážně míněný fork cizího
projektu, který budete publikovat na [SF.net][sf] nebo [Freshmeat.net][fm]
by mělo být pouze závaž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.

[sf]:http://sf.net
[fm]:http://freshmeat.net

Lehký/personální branch v [git.or.cz](http://git.or.cz) nebo jinde pro
osobní účely je naopak věc zcela jiná, 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ů uvádět, že se
jedná je o váš soukromý fork s tím, že míníte práci integrovat
do hlavní větve.

Pokud je vám například povolen i přístup do cizího projektu
na SF.net, tak to je projev značné důvěry zakladatelů
projektu. Je správné se dohodnout s nimi. Dále budeme uvažovat
repozitář projektu ve verzovacím systému CVS.

Když musíte pracovat s CVS
--------------------------

Optimální postup je poslat navržené změny do konference (mailing list) projektu jako patch
proti aktuálnímu stavu CVS. Patch, pokud není extrémně velký, by měl být
č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 a mění mezery za tabelátory a naopak. Nepoužívejte
takový nebezpečný SW. Po prodiskutování a schválení s vývojáři
pak pošlete změny přímo do repositáře nebo o to požádáte některého
z vývojářů s právem zápisu. Pokud se jedná o CVS, tak ta má dost nevýhodu
v tom, že vám neumožňuje přímo držet lokální stav včetně
historie a postupně "nacommitovat" své změny do svého repositáře,
vygenerovat patche a po sválení změny "pushnout" do centrálního
repositáře. S CVS tedy pracujete buď tak, že si aktuální stav stáhnete,
děláte úpravy a případné změny z centrálního repositáře
do svého pracovního prostoru. Stahujete

    cvs -z3 up -d

Patch vygenerujete přes všechny vaše změny

    cvs -z3 diff -u -N -p

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

    cvs -z3 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 http://savannah.nongnu.org/projects/quilt
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.

Vztah SourceForge a Ohlohu
--------------------------

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

[o]:http://ohloh.net