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