poznamky.mdwn

   1 [[!meta title="Poznámky a odkazy"]]
   2
   3 Poznámky k práci s cizím OSS projektem
   4 =====================================
   5
   6 Při práci s cizím projektem je správné se přizpůsobit typu
   7 repositáře, ve kterém je projekt veden. Založení vlastního
   8 forku projektu je možnost, která je ve škále možností celkem
   9 na konci seznamu možností a připadá především v úvahu, pokud se
  10 s původními správci nelze dohodnout nebo pokud vám založení
  11 vlastní větve sami doporučí. Založit vážně míněný fork cizího
  12 projektu, který budete publikovat na SF.net nebo Freshmeat.net
  13 by mělo být pouze závažně míněné rozhodnutí s tím, že se míníte
  14 o vývoj dané varianty nebo celého projektu starat delší dobu
  15 a převezmete na sebe odpovědnost s řešením chyb, tvorbou dokumentace
  16 a správou projektu.
  17
  18 Lehký/personální branch v git.or.cz nebo jinde pro
  19 osobní účely je naopak věc zcela jiná, jedná se jen o zveřejnění
  20 vlastního pískoviště (sandboxu) druhým, aby mohli sledovat,
  21 co děláte. V takovém případě není vyjednávání s hlavními autory
  22 příliš nutné, ale je potřeba pří posílání odkazů uvádět, že se
  23 jedná je o váš soukromý fork s tím, že míníte práci integrovat
  24 do hlavní větve.
  25
  26 Pokud se je vám například povolen i přístup do cizího projektu
  27 na SF.net zařadili, tak to je projev značné důvěry zakladatelů
  28 projektu. Je správné se dohodnout s nimi. Dále budeme uvažovat
  29 repozitory projektu ve verzovacím systému CVS.
  30
  31 Optimální postup je poslat navržené změny na list projektu jako patch
  32 proti aktuálnímu stavu CVS. Patch, pokud není extrémě velký, by měl být
  33 čistý text přímo vložený do těla e-mailu. Žádné HTML formátování
  34 zprávy a přílohy. Pozor, množství MUA/e-mail programů atomaticky
  35 volí HTML a mění mezery za tabelátory a naopak. Nepoužívejte
  36 takový nebezpečný SW. Po prodiskutování a schválení s vývojáři
  37 pak pošlete změny přímo do repository nebo o to požádáte některého
  38 z vývojářů s právem zápisu. Pokud se jedná o CVS, tak ta má dost nevýhodu
  39 v tom, že vám neumožňuje přímo držet lokální stav včetně
  40 historie a postupně nacommitovat své změny je do svého repository,
  41 vygenerovat patche a po sválení změny pushnout do centrálního
  42 repository. S CVS tedy pracujete buď tak, že si aktuální stav stáhnete,
  43 děláte úpravy a případné změny z centrálního repository
  44 do svého pracovního prostoru. Stahujete
  45
  46     cvs -z3 up -d
  47
  48 Patch vygenerujete přes všechny vaše změny
  49
  50     cvs -z3 diff -u -N -p
  51
  52 Po schválení celý patch pošlete do repository
  53
  54     cvs -z3 commit
  55
  56 Pokud je práci výhodné pro účely diskuze a dokumentování
  57 rozdělit na více samostatných změn, tak můžete nasadit
  58 quilt patch stack nad CVS http://savannah.nongnu.org/projects/quilt
  59 Pokud je práce ještě více, tak je pak asi nejvýhodnější použít
  60 import do GITu. Takto jsme třeba importovali do GITu jeden
  61 z našich projektů:
  62
  63     export CVS_RSH=ssh
  64     CVSROOT=":ext:ppisa@ulan.cvs.sourceforge.net:/cvsroot/ulan"
  65     CVSMODULE="ulan"
  66
  67     git cvsimport -v -d $CVSROOT -C ulan-devel -i -k -a -r ulan-sf $CVSMODULE
  68
  69 Pak pracovat v GITu a posléze použít git format-patch a patche
  70 prodiskutovat a po schválení buď ručně naaplikovat a nacommitovat po jednom
  71 na CVS nebo použít git cvsexportcommit
  72
  73 Rozsah studentské práce asi většinou nebude takto komplexní řešení vyžadovat.
  74 Stačí většinou poslat jeden kompletní patch.
  75
  76 Pracovat a commitovat budete typicky na SF.net . Ohloh je pouze monitor.
  77 Pokud se vám podaří změnu dostat na SF.net, tak se commit objeví
  78 na Ohloh s vaším loginem na SF.net a vy si ho pak přiřadíte
  79 k vašemu účtu.