faq/index.mdwn

   1 [[!meta title="FAQ"]]
   2 [[!meta stylesheet="faq/local" rel="stylesheet"]]
   3
   4 (často kladené otázky a odpovědi)
   5
   6 [[!toc levels=2]]
   7
   8 ## 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í)
   9
  10 Protože pro pochopení a správné využití vrstev vyšších je nutné znát omezení a vlastnosti služeb
  11 nad kterými jsou vyšší vrstvy postavené. To si v dnešní době uvědomují i ve velkých firmách
  12 a hlubší znalost systému Linux je požadovaná. Zároveň s nástupem Androidu a dalších vestavných
  13 systémů s jádrem Linux narůstá výrazně poptávka po vývojářích se znalostí jádra OS a schopností
  14 provést jeho adaptaci nebo doplnění o drivery.
  15
  16 * [Linux hnací silou pracovních příležitostí v IT](http://www.linuxexpres.cz/business/linux-hnaci-silou-pracovnich-prilezitosti-v-it), Linuxexpres / OpenMagazin Červenec-Srpen, 2012, ISSN: ISSN 1804-1426
  17
  18 ## 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?
  19
  20 Založení vlastního forku projektu je volba, která je ve škále
  21 možností spolupráce/práce na cizím projektu většinou až ta poslední volba
  22 a připadá především v úvahu, pokud se s původními správci nelze dohodnout
  23 nebo pokud vám založení vlastní vlastního forku/větve sami doporučí.
  24
  25 Založit vážně míněný fork cizího projektu, který budete publikovat na
  26 serverech typu [SF.net][sf] nebo [Freshmeat.net][fm] by mělo být pouze
  27 vážně míněné rozhodnutí s tím, že se míníte o vývoj dané varianty
  28 nebo celého projektu starat delší dobu a převezmete na sebe odpovědnost
  29 s řešením chyb, tvorbou dokumentace a správou projektu.
  30
  31 ## Nenaštvu vývojáře, když publikuji svůj fork v gitu na githubu nebo repo.or.cz?
  32
  33 Lehký/personální branch na [git.or.cz](http://git.or.cz) nebo jinde
  34 pro osobní účely je naopak věc zcela odlišná, jedná se jen o zveřejnění
  35 vlastního pískoviště (sandboxu) druhým, aby mohli sledovat, co děláte.
  36 V takovém případě není vyjednávání s hlavními autory příliš nutné, ale
  37 je potřeba pří posílání odkazů a informací o svém repozitáři uvádět,
  38 že se jedná je o váš soukromý fork a že míníte práci po schválení
  39 integrovat do hlavní větve.
  40
  41 [sf]:http://sf.net
  42 [fm]:http://freshmeat.net
  43
  44 ## Vývojáři mi nechtějí dát právo zapisovat do jejich repozitáře. Jak s nimi mám spolupracovat?
  45
  46 Pokud je vám povolen přístup pro zápis do repozitáře cizího projektu
  47 (např. na [SF.net][sf]), tak to je projev značné důvěry správců projektu.
  48 V mnoha projektech ale vývoj probíhá následujícím způsobem, kdy je
  49 celkem jedno jestli právo zápisu máte nebo ne.
  50
  51 Vývojář (vy) pošle navržené změny do konference (mailing list)
  52 projektu jako patch proti aktuálnímu stavu v repozitáři. Patch, pokud
  53 není extrémně velký, by měl být zaslán jako čistý text přímo vložený
  54 do těla e-mailu. Žádné HTML formátování zprávy a přílohy. Pozor, množství
  55 MUA/e-mail programů automaticky volí HTML či mění mezery za tabelátory
  56 a naopak. Nepoužívejte takový nebezpečný SW. Takto zaslané patche mají
  57 výhodu, že v odpovědi lze připsat poznámky ke konkrétnímu místu patche.
  58 Po prodiskutování a schválení vašich změn je pak patch "commitnut"
  59 do repozitáře. Pokud máte právo zápisu, uděláte to vy, jinak to udělá
  60 někdo jiný. U moderních distribuovaných verzovacích systémů (Git, Darcs)
  61 bude přitom informace o vašem autorství úprav zachována. U starších
  62 systémů (CVS, Subversion) to zařídit nelze a běžně se vaše jméno objeví
  63 jen v poznámce u "commitu".
  64
  65 ## Projekt používá verzovací systém, se kterým neumím/nechci pracovat. Co s tím?
  66
  67 Při práci s cizím projektem je správné se přizpůsobit typu repositáře,
  68 ve kterém je projekt veden. Některé verzovací systémy (např. git)
  69 umožňují import a export do jiných systémů, takže lokálně můžete
  70 používat váš oblíbený systém a nikdo jiný o tom nemusí vědět.
  71
  72 ## Projekt ještě stále používá CVS. Pomoc!!!
  73
  74 Verzovací systém CVS má mnoho nevýhod. Zaprvé se verzují jednotlivé
  75 soubory a ne projekt jako celek, takže není jasné jestli spolu změny
  76 ve dvou souborech nějak souvisí. Zadruhé není možno přímo držet
  77 lokální stav včetně historie a postupně "pushovat" své změny do
  78 centrálního repositáře, pokud jsou projektem schváleny.
  79
  80 S CVS tedy pracujete buď tak, že si aktuální stav stáhnete
  81
  82     cvs up -d
  83
  84 uděláte úpravy a vygenerujete patch přes všechny vaše změny
  85
  86     cvs diff -u -N -p > moje-zmena.patch
  87
  88 Po schválení celý patch pošlete do repositáře
  89
  90     cvs commit
  91
  92 Pokud je práci výhodné pro účely diskuze a dokumentování rozdělit na
  93 více samostatných změn, tak můžete nasadit
  94 [quilt patch stack nad CVS](http://savannah.nongnu.org/projects/quilt).
  95 Pokud je práce ještě více, tak je pak asi nejvýhodnější použít import
  96 do GITu. Takto jsme třeba importovali do GITu jeden z našich projektů:
  97
  98     export CVS_RSH=ssh
  99     CVSROOT=":ext:ppisa@ulan.cvs.sourceforge.net:/cvsroot/ulan"
 100     CVSMODULE="ulan"
 101
 102     git cvsimport -v -d $CVSROOT -C ulan-devel -i -k -a -r ulan-sf $CVSMODULE
 103
 104 Pak pracovat v GITu a posléze použít `git format-patch` a patche
 105 prodiskutovat a po schválení buď ručně naaplikovat a nacommitovat po jednom
 106 na CVS nebo použít `git cvsexportcommit`.
 107
 108 Rozsah studentské práce asi většinou nebude takto komplexní řešení vyžadovat.
 109 Stačí většinou poslat jeden kompletní patch.
 110
 111 # Mám posílat své commity na Ohloh nebo do repozitáře na SourceForge?
 112
 113 Pracovat a commitovat budete typicky na [SF.net][sf]. [Ohloh][o] je
 114 pouze monitor. Pokud se vám podaří změnu dostat na [SF.net][sf], tak
 115 se commit automaticky objeví na [Ohloh][o] s vaším loginem na SF.net a
 116 vy si ho pak přiřadíte k vašemu účtu.
 117
 118 [o]:http://ohloh.net