                             Spravochnik kommittera

  The FreeBSD Documentation Project

  Dmitrij Morozovskij

   Perevod na russkij yazyk:  
   Izdanie: e5712d4822

   Avtorskie prava (c) 1999-2007 The FreeBSD Documentation Project

   FreeBSD `eto zaregistrirovannaya torgovaya marka FreeBSD Foundation.

   CVSup `eto zaregistrirovannaya torgovaya marka John D. Polstra.

   IBM, AIX, OS/2, PowerPC, PS/2, S/390 i ThinkPad `eto torgovye marki
   International Business Machines Corporation v Soedinennyh SHtatah, drugih
   stranah, ili po vsemu miru.

   Intel, Celeron, EtherExpress, i386, i486, Itanium, Pentium i Xeon `eto
   torgovye marki ili zaregistrirovannye torgovye marki Intel Corporation ili
   ee dochernih kompanij v Soedinennyh SHtatah i drugih stranah.

   Sparc, Sparc64, i UltraSPARC `eto torgovye marki SPARC International, Inc
   v Soedinennyh SHtatah i drugih stranah. Produkty s torgovoj markoj SPARC
   osnovany na arhitekture, razrabotannoj Sun Microsystems, Inc.

   Mnogie iz oboznachenij, ispol'zuemye proizvoditelyami i prodavcami dlya
   oboznacheniya svoih produktov, zayavlyayutsya v kachestve torgovyh marok.
   Kogda takie oboznacheniya poyavlyayutsya v `etom dokumente, i Proektu
   FreeBSD izvestno o torgovoj marke, k oboznacheniyu dobavlyaetsya znak
   <<TM>> ili <<(R)>>.

   2014-06-13 14:53:24 +0000 Taras Korenko.
   Annotaciya

   Dannyj dokument soderzhit informaciyu dlya soobschestva kommitterov
   FreeBSD. Vse novye kommittery dolzhny izuchit' ego pered nachalom raboty;
   prochim kommitteram takzhe rekomenduetsya vremya ot vremeni prosmatrivat'
   ego.

   [ Po razdelam / Odnim fajlom ]

     ----------------------------------------------------------------------

   Soderzhanie

   1. Administrativnye detali

   2. Tipy kommit bitov

   3. Rabota s CVS

   4. Soglasheniya i tradicii

   5. Predpochtitel'naya licenziya dlya novyh fajlov

   6. Vzaimodejstvie mezhdu razrabotchikami

   7. GNATS

   8. Kto est' kto

   9. SSH: bystryj start

   10. Bol'shoj Spisok Pravil Kommittera FreeBSD

   11. Podderzhka razlichnyh arhitektur

   12. FAQ po rabote s portami

   13. Pryaniki i prochie l'goty

   14. Prochie voprosy

1. Administrativnye detali

   Host osnovnogo          ncvs.FreeBSD.org                                   
   repozitoriya            
   Sposob avtorizacii      ssh(1), tol'ko protokol 2                          
   Osnovnoj koren'         ncvs.FreeBSD.org:/home/ncvs (sm. takzhe Razdel 3,  
   repozitoriya (CVSROOT)  <<Rabota s CVS>>).                                 
   Administratory Glavnogo Peter Wemm <peter@FreeBSD.org> i Mark Murray       
   CVS Repozitoriya        <markm@FreeBSD.org>, a takzhe Josef Karthauser     
   <cvsadm@FreeBSD.org>    <joe@FreeBSD.org> i Joe Marcus Clarke              
                           <marcus@FreeBSD.org> dlya ierarhii ports/          
                           Spisok rassylki razrabotchikov dokumentacii        
                           FreeBSD, Spisok rassylki kommitterov dokumentacii  
                           FreeBSD; Spisok rassylki razrabotchikov portov     
                           FreeBSD, Spisok rassylki kommitterov portov        
                           FreeBSD; Spisok rassylki razrabotchikov FreeBSD,   
                           Spisok rassylki kommitterov ishodnyh tekstov       
   Spiski rassylki         FreeBSD. (Kazhdomu repozitoriyu proekta            
                           sootvetstvuyut otdel'nye spiski rassylki s         
                           suffiksami -developers i -committers. Arhivy `etih 
                           spiskov hranyatsya v fajlah                        
                           /home/mail/repository-name-developers-archive i    
                           /home/mail/repository-name-committers-archive na   
                           mashinah klastera FreeBSD.org).                    
   Otchety Pravleniya      /home/core/public/monthly-report na mashinah       
                           klastera FreeBSD.org.                              
   Naibolee znachimye      RELENG_4 (vetv' 4.X-STABLE), RELENG_5 (vetv'       
   metki CVS               5.X-STABLE), RELENG_6 (vetv' 6.X-STABLE), HEAD     
                           (vetv' -CURRENT)                                   

   Dlya avtorizacii na mashiny proekta vy dolzhny ispol'zovat' protokoly
   ssh(1) ili telnet(1) s vklyuchennym Kerberos 5. V sluchae ssh(1), dopustim
   tol'ko protokol versii 2. `Eti protokoly yavlyayutsya znachitel'no bolee
   zaschischennymi po sravneniyu s telnet(1) ili rlogin(1), poskol'ku
   informaciya ob avtorizacii peredaetsya v zashifrovannom vide. Po
   umolchaniyu, protokol ssh(1) takzhe shifruet ves' trafik. Uchityvaya
   nalichie takih utilit, kak ssh-agent(1) i scp(1), protokol ssh(1)
   znachitel'no udobnee prochih v ispol'zovanii. Esli vy nichego ne znaete ob
   ssh(1), zaglyanite v razdel Razdel 9, <>.

2. Tipy kommit bitov

   CVS Repozitorij FreeBSD sostoit iz neskol'kih razdelov, ohvatyvayuschih
   ishodnye teksty bazovoj operacionnoj sistemy, dokumentaciyu,
   infrastrukturu postroeniya vneshnih prilozhenij (portov), a takzhe
   razlichnye sluzhebnye utility. Pravo zapisi v repozitorij (<<kommit bit>>)
   podrazumevaet ukazanie oblasti dereva, v kotoroe ono mozhet byt'
   primeneno. Kak pravilo, oblasti napryamuyu svyazany s gruppoj,
   podtverdivshej pravo kommittera na bit. V dal'nejshem, oblast' dejstviya
   kommit bita mozhet byt' rasshirena; v `etom sluchae, kommitter dolzhen
   sledovat' standartnym pravilam novogo dlya kommittera v dannoj oblasti, v
   chastnosti, poluchaya podtverzhdeniya na kazhdyj kommit i, vozmozhno, v
   techenie kakogo-to vremeni rabotu s mentorom.

   Tip kommit bita    Otvetstvennye   Oblasti repozitoriya                    
   src                core@           src/ i sootvetstvuyuschie chasti doc/   
   doc                doceng@         doc/, www/, dokumentaciya dereva src/   
   ports              portmgr@        ports/                                  

   Bity, vydelennye do razdeleniya dereva na oblasti mogut ispol'zovat'sya vo
   vseh chastyah dereva. Odnako, s tochki zreniya zdravogo smysla, kommitter,
   ne imeyuschij opyta raboty v kakoj-libo chasti dereva, dolzhen
   predostavlyat' predlagaemye izmeneniya dlya rassmotreniya drugimi
   kommitterami, poluchat' podtverzhdeniya ot otvetstvennyh za razlichnye
   chasti repozitoriya, a takzhe, vozmozhno, rabotat' sovmestno s mentorom.
   Poskol'ku pravila vedeniya razlichnyh oblastej koda razlichayutsya,
   ukazannye normy skoree napravleny na blago kommittera, ne imeyuschego
   dostatochnogo opyta raboty v dannoj oblasti.

   Vne zavisimosti ot oblasti prilozheniya usilij, zaprosy kommitterov na
   rassmotrenie predlagaemyh izmenenij v processe razrabotki mogut tol'ko
   privetstvovat'sya.

  2.1. Pravila dlya kommitterov dokumentacii (doc/) pri rabote s derevom
  ishodnyh tekstov (src/)

     * Kommittery dokumentacii mogut samostoyatel'no izmenyat' dokumentaciyu
       k ishodnym tekstam, naprimer, stranicy spravochnika, fajly README,
       bazy dannyh utility fortune, kalendarej, a takzhe ispravlyat'
       kommentarii v ishodnyh tekstah bez dopolnitel'nogo soglasovaniya s
       kommitterami ishodnyh tekstov, pri uslovii sohraneniya zdravogo smysla
       i manery kommitov.

     * Kommittery dokumentacii mogut vnosit' neznachitel'nye izmeneniya i
       ispravleniya v ishodnye teksty (takie kak ispravleniya k processu
       sborki, dobavlenie malyh dopolnitel'nyh vozmozhnostej i t.p.) pri
       nalichii odobreniya ot kommittera ishodnyh tekstov.

     * Kommitter dokumentacii mozhet rasshirit' oblast' dejstviya svoego bita
       na oblast' ishodnyh tekstov (i stat', takim obrazom, kommitterom
       ishodnyh tekstov), najdya sebe mentora, kotoryj predlozhit `eto
       rasshirenie Pravleniyu (Core). Posle odobreniya, stroka s ego imenem
       pol'zovatelya vnositsya v fajl 'access', i primenyayutsya obychnye
       pravila perioda raboty s mentorom, podrazumevayuschie poluchenie
       odobreniya na kazhdyj kommit.

     * Odobrenie kommita ("Approved by") mozhet proizvodit'sya tol'ko
       "polnovesnym" (ne rabotayuschim s mentorom) kommitterom ishodnyh
       tekstov; poslednie mogut rassmatrivat' predlagaemye izmeneniya i
       ukazyvat'sya v stroke "Reviewed by".

3. Rabota s CVS

   Podrazumevaetsya, chto vy uzhe imeete opyt bazovoj raboty s CVS.

   Administratory Glavnogo CVS Repozitoriya <cvsadm@FreeBSD.org> yavlyayutsya
   <<vladel'cami>> repozitoriya CVS i otvetstvenny za vse pryamye ego
   izmeneniya (v celyah chistki ili ispravleniya kakih-libo vopiyuschih
   oshibok kommitterov pri rabote s CVS). Esli v rezul'tate vashih dejstvij s
   chast'yu repozitoriya proizoshel neschastnyj sluchaj, naprimer, posle
   nevernoj operacii cvs import ili cvs tag, poshlite pis'mo
   sootvetstvuyuschej podgruppe Administratory Glavnogo CVS Repozitoriya
   <cvsadm@FreeBSD.org> (sm. sleduyuschuyu tablicu) i soobschite o probleme.
   V naibolee ser'eznyh sluchayah, kasayuschihsya ne tol'ko kakoj-libo chasti
   repozitoriya, a dereva CVS v celom, vy mozhete napisat' Administratory
   Glavnogo CVS Repozitoriya <cvsadm@FreeBSD.org>. Pozhalujsta, ne nado
   pisat' gruppe Administratory Glavnogo CVS Repozitoriya
   <cvsadm@FreeBSD.org> po povodu repozitornogo kopirovaniya i prochih
   voprosov, kotorye mozhet reshit' sootvetstvuyuschaya podgruppa.

   Napryamuyu izmenyat' soderzhimoe repozitoriya mozhet tol'ko gruppa
   CVS-masterov; dlya obespecheniya `etogo, tol'ko CVS-mastera imeyut
   uchetnye zapisi na mashinah, podderzhivayuschih osnovnoj repozitorij.

  Primechanie:

   Adresa, na kotorye sleduet posylat' zaprosy, zavisyat ot oblasti
   repozitoriya, kotoruyu trebuetsya popravit':

     * ncvs@ - repozitorij /home/ncvs, osnovnye ishodnye teksty

     * pcvs@ - repozitorij /home/pcvs, porty

     * dcvs@ - repozitorij /home/dcvs, dokumentaciya

     * projcvs@ - repozitorij /home/projcvs, prochie proekty

   Derevo CVS v nastoyaschee vremya razdeleno na chetyre nezavisimyh
   repozitoriya: doc, ports, projects i src. Dlya udobstva raboty
   pol'zovatelej pri rasprostranenii cherez CVSup razlichnye derev'ya
   kombiniruyutsya v odno, s odnim sluzhebnym katalogom CVSROOT.

  Primechanie:

   Obratite vnimanie, chto modul' www, soderzhaschij ishodnye teksty
   veb-sajta FreeBSD, raspolozhen v repozitorii doc.

   V nastoyaschee vremya, vse repozitorii CVS raspolagayutsya na odnoj
   mashine, ncvs.FreeBSD.org, odnako, dlya obespecheniya vozmozhnosti v
   buduschem raznesti ih po fizicheski razlichnym mashinam, dlya kazhdoj
   podderzhivaetsya otdel'noe imya hosta. Ih i sleduet ispol'zovat'
   kommitteram. Nakonec, kazhdyj repozitorij raspolozhen v otdel'nom
   kataloge. V itoge, obschaya kartina vyglyadit tak:

   Tablica 1. Repozitorii CVS FreeBSD, hosty i katalogi

   Repozitorij        Host            Katalog    
   doc         dcvs.FreeBSD.org    /home/dcvs    
   ports       pcvs.FreeBSD.org    /home/pcvs    
   projects    projcvs.FreeBSD.org /home/projcvs 
   src         ncvs.FreeBSD.org    /home/ncvs    

   Operacii s CVS proizvodyatsya udalenno, putem ustanovki peremennoj
   okruzheniya CVSROOT (ona dolzhna ukazyvat' na sootvetstvuyuschij host i
   katalog verhnego urovnya, naprimer ncvs.FreeBSD.org:/home/ncvs) i
   posleduyuschego vypolneniya komand vygruzki i kommita. Mnogie kommittery
   opredelyayut komandy-sinonimy, razvorachivayuschiesya v zapusk cvs s
   pravil'nymi parametrami. V chastnosti, pol'zovateli obolochki tcsh(1)
   mogut dobavit' sleduyuschie stroki v svoj skript nachal'noj zagruzki
   .cshrc:

 alias dcvs cvs -d user@dcvs.FreeBSD.org:/home/dcvs
 alias pcvs cvs -d user@pcvs.FreeBSD.org:/home/pcvs
 alias projcvs cvs -d user@projcvs.FreeBSD.org:/home/projcvs
 alias scvs cvs -d user@ncvs.FreeBSD.org:/home/ncvs

   Teper' vse operacii s CVS mogut vypolnyat'sya na lokal'noj mashine, a dlya
   vneseniya izmenenij v oficial'noe derevo CVS sleduet ispol'zovat' komandu
   Xcvs commit. Esli vam nuzhno dobavit' v proekt chto-libo sovershenno novoe
   (naprimer, ishodnye teksty storonnih razrabotchikov), nuzhno ispol'zovat'
   komandu cvs import; obratites' k stranice spravochnika po cvs(1) za
   podrobnostyami.

  Primechanie:

   Pozhalujsta, ne ispol'zujte komandy cvs checkout ili cvs update dlya
   sinhronizacii vashih ishodnyh tekstov. Protokol CVS ne optimizirovan dlya
   udalennoj raboty i trebuet znachitel'nyh nakladnyh rashodov so storony
   servera. Pozhalujsta, ispol'zujte metod sinhronizacii posredstvom cvsup, a
   osnovnoj host ispol'zujte tol'ko dlya sobstvenno kommitov. Nasha
   raspredelennaya set' serverov cvsup dostatochno razvita. Pri neobhodimosti
   sinhronizacii s samymi svezhimi izmeneniyami vy mozhete pol'zovat'sya
   mashinoj cvsup-master, kotoraya obladaet dostatochnymi resursami dlya
   udalennoj raboty s CVS; za nee otvechaet Jun Kuriyama
   <kuriyama@FreeBSD.org>.

   Esli vam nuzhno ispol'zovat' komandy CVS add i delete, tak chtoby v
   real'nosti peremestit' chast' ishodnyh tekstov podobno dejstviyu komandy
   mv(1), nuzhno zaprosit' operaciyu <<repozitornogo kopirovaniya>>
   (repository copy). Pri `etom kto-libo iz CVS-masterov skopiruet
   neobhodimye fajly vnutri repozitoriya na nuzhnoe mesto i dast vam znat' ob
   `etom. Repozitornoe kopirovanie proizvoditsya dlya sohraneniya istorii
   (zhurnalov izmeneniya). Vozmozhnost' otsledit' istoriyu izmenenij ochen'
   cenna dlya vsego proekta FreeBSD.

   Dokumentaciya po CVS, uchebnye materialy i FAQ mozhno najti po adresu:
   http://www.cvshome.org/docs/. Ochen' polezna takzhe kniga Karla Fogelya
   (Karl Fogel) Open Source Development with CVS. Nekotoraya poleznaya
   informaciya o CVS na russkom yazyke mozhet byt' najdena zdes'.

   Dag-Erling Smorgrav <des@FreeBSD.org> napisal takoj <<mini-primer>> raboty
   s CVS:

    1. Izvlechenie nuzhnogo modulya iz repozitoriya: komanda co ili checkout.

 % cvs checkout shazam

       `Eta komanda izvlechet kopiyu modulya shazam. Esli modul' s takim
       imenem ne suschestvuet (ne opisan v fajle modules), budet proizvedena
       popytka izvlech' direktoriyu verhnego urovnya shazam.

       Tablica 2. Poleznye opcii komandy cvs checkout

       -P     Ne sozdavat' (tochnee, udalit' posle zaversheniya vypolneniya)  
              pustye katalogi                                                 
       -l     Izvlekat' odin uroven' katalogov (bez podkatalogov)             
       -rrev  Izvlech' reviziyu, vetv' ili teg rev dlya ukazannogo modulya    
       -Ddate Izvlech' sostoyanie modulya v repozitorii na moment date        

       Primery v primenenii k FreeBSD:

          * Izvlech' modul' miscfs, raspolozhennyj v kataloge repozitoriya
            src/sys/miscfs:

 % cvs co miscfs

            Posle vypolneniya vy poluchite katalog miscfs, soderzhaschij
            podkatalogi CVS, deadfs, devfs i t.d. Odin iz nih (linprocfs)
            budet pustym.

          * Izvlech' te zhe fajly, no s polnym putem:

 % cvs co src/sys/miscfs

            Teper' u vas est' katalog src, soderzhaschij podkatalogi CVS i
            sys. Katalog src/sys soderzhit podkatalogi CVS i miscfs i t.d.

          * Izvlech' te zhe fajly, udaliv pri `etom pustye podkatalogi:

 % cvs co -P miscfs

            Vy poluchite katalog miscfs s podkatalogami CVS, deadfs, devfs...
            odnako bez podkataloga linprocfs, poskol'ku on ne soderzhit
            fajlov.

          * Izvlech' katalog miscfs bez podkatalogov:

 % cvs co -l miscfs

            Teper' v kataloge miscfs budet tol'ko odin podkatalog CVS.

          * Izvlech' modul' miscfs iz vetvi 6.X:

 % cvs co -rRELENG_6 miscfs

            Teper' vy mozhete izmenit' ishodnye teksty i proizvesti kommit v
            `etu vetv'.

          * Izvlech' modul' miscfs po sostoyaniyu na moment vyhoda
            6.0-RELEASE:

 % cvs co -rRELENG_6_0_0_RELEASE miscfs

            V `etom sluchae vy ne smozhete vnesti izmeneniya v repozitorij,
            poskol'ku RELENG_6_0_0_RELEASE opisyvaet moment vremeni, a ne
            vetv' razrabotki.

          * Izvlech' modul' miscfs po sostoyaniyu na 15 yanvarya 2000 g:

 % cvs co -D'01/15/2000' miscfs

            Kak i v predyduschem sluchae, izmeneniya ne mogut byt' zapisany.

          * Izvlech' modul' miscfs, kakim on byl nedelyu nazad:

 % cvs co -D'last week' miscfs

            I vnov', izmeneniya ne mogut byt' zapisany.

       Obratite vnimanie, chto meta-dannye hranyatsya v podkatalogah CVS.

       Argumenty opcij -D and -r sohranyayutsya (yavlyayutsya <<klejkimi>>,
       sticky), naprimer, pri posleduyuschem ispol'zovanii komandy cvs
       update.

    2. Proverka sostoyaniya izvlechennyh fajlov: komanda status.

 % cvs status shazam

       `Eta komanda pokazhet status fajla shazam ili kazhdogo fajla v
       direktorii shazam. Dlya kazhdogo iz fajlov status mozhet byt' odnim
       iz:

       Up-to-date            Fajl sootvetstvuet repozitoriyu i ne             
                             modificirovalsya                                 
       Needs Patch           Fajl ne izmenyalsya, no repozitorij soderzhit    
                             obnovlennuyu versiyu                             
       Locally Modified      Fajl sootvetstvuet repozitoriyu, no byl izmenen  
                             lokal'no                                         
       Needs Merge           Fajl izmenen lokal'no; vmeste s tem, fajl        
                             izmenen i v repozitorii                          
       File had conflicts on Posle poslednego obnovleniya voznikli konflikty, 
       merge                 i oni vse esche ne ustraneny                     

       Krome togo, budut pokazany lokal'naya versiya i data modifikacii,
       versiya i data poslednej iz dostupnyh (esli vy primenyali <<klejkie>>
       datu, teg ili vetv', poslednyaya dostupnaya versiya mozhet
       otlichat'sya ot vashej), a takzhe klejkie tegi, vremennye metki i
       opcii.

    3. Obnovlenie izvlechennogo modulya: komanda update.

 % cvs update shazam

       `Eta komanda obnovit sostoyanie fajla shazam ili fajlov v kataloge
       shazam do naibolee svezhih versij vybrannoj vami pri izvlechenii
       vetvi. Esli vybiralsya <<moment vremeni>>, ne proizojdet nichego, esli
       tol'ko za istekshee vremya v repozitorii ne byl peremeschen teg ili ne
       proizoshlo chego-nibud' esche nepredvidennogo.

       Poleznye opcii v dopolnenie k uzhe opisannym dlya komandy checkout:

       -d    Izvlech' vnov' poyavivshiesya ili propuschennye ranee            
             podkatalogi                                                      
       -A    Obnovit'sya do tekuschego sostoyaniya golovnoj vetvi             
       -jrev magicheskaya opciya (sm. nizhe)                                  

       Esli vy izvlekali modul' s opciyami -r ili -D, vypolnenie komandy cvs
       update s drugimi parametrami -r ili -D ili s opciej -A privedet k
       vyboru novoj vetvi, revizii ili daty. Ispol'zovanie opcii -A udalyaet
       ispol'zovannye ranee klejkie svojstva; opcii -r i -D, naoborot,
       fiksiruyut ih.

       Teoreticheski ispol'zovanie HEAD v kachestve argumenta opcii -r
       dolzhno dat' tot zhe rezul'tat, chto i ukazanie opcii -A, odnako `eto
       verno lish' v teorii.

       Opciya -d polezna, esli:

          * posle izvlecheniya vami modulya kem-libo esche v nego byli
            dobavleny dopolnitel'nye katalogi;

          * vy izvlekali verhnij uroven' modulya pri pomoschi opcii -l, a v
            dal'nejshem reshili izvlech' i podkatalogi;

          * vy udalili kakie-libo podkatalogi i teper' hotite vnov' izvlech'
            ih.

       Obraschajte vnimanie na vyvod komandy cvs update. Dejstvie,
       proizvedennoe s fajlom, oboznachaetsya bukvoj pered ego imenem:

       U Fajl byl uspeshno obnovlen.                                          
       P Fajl byl uspeshno obnovlen (proizveden uspeshnyj patch iz udalennogo 
         repozitoriya).                                                       
       M Fajl byl izmenen, i pri `etom obnovlen uspeshno.                     
       C Fajl byl izmenen, i pri ob"edinenii izmenenij voznikli konflikty.    

       Ob"edinenie (merging) proizvoditsya, esli vy vygruzili rabochuyu
       kopiyu kakogo-to modulya, izmenili ego, zatem kto-libo esche proizvel
       kommit sobstvennyh izmenenij, i, nakonec, vy vypolnyaete komandu cvs
       update. CVS znaet, chto proizvodilis' lokal'nye izmeneniya, i
       pytaetsya ob"edinit' vashi izmeneniya s temi, chto proizoshli v
       repozitorii (ot sostoyanii versii, kotoruyu vy vygruzhali, do versii,
       do kotoroj vy pytaetes' obnovit'sya). Esli izmeneniya proishodili s
       razlichnymi chastyami fajla, ob"edinenie pochti vsegda proizojdet
       uspeshno (hotya rezul'tat pri `etom mozhet ne byt' sintaksicheski ili
       semanticheski korrektnym).

       CVS vyvodit bukvu M pered imenem vseh lokal'no izmenennyh fajlov,
       dazhe esli u nih net novyh versij v repozitorii, tak chto komanda cvs
       update udobna dlya bystrogo polucheniya spiska fajlov, kotorye vy
       izmenyali.

       Esli v rezul'tate vy vidite bukvu C, vashi izmeneniya konfliktuyut s
       izmeneniyami, vnesennymi v repozitorij (izmeneniya byli v odnih i teh
       zhe ili ryadom raspolozhennyh strokah, libo vy izmenili fajl
       nastol'ko, chto pri sravnenii cvs ne smogla uderzhat' kontekst i
       prilozhit' izmeneniya iz repozitoriya). Vam neobhodimo ustranit'
       konflikty, vruchnuyu redaktiruya fajl. Konfliktuyuschie fragmenty
       pomechayutsya strokami iz znakov <, = i >. V nachale kazhdogo iz
       konfliktov prisutstvuet stroka iz semi znakov < i imeni fajla, zatem
       idet fragment, soderzhaschij vnesennye vami izmeneniya, razdelitel' iz
       semi znakov =, sootvetstvuyuschij fragment iz versii fajla,
       soderzhaschejsya v repozitorii, i, nakonec, stroka iz semi znakov >
       sovmestno s nomerom versii, do kotoroj vy obnovlyali fajl.

       Opciya -j soderzhit nekotoroe kolichestvo chernoj magii. Pri ee
       nalichii lokal'nyj fajl obnovlyaetsya do ukazannoj versii tak zhe, kak
       i pri ispol'zovanii opcii -r, no otslezhivaemye nomer versii ili vetv'
       ne izmenyayutsya. `Eta opciya umeet smysl lish' pri parnom
       ispol'zovanii: pri `etom delaetsya popytka primenit' izmeneniya mezhdu
       dvumya ukazannymi versiyami k lokal'noj kopii fajla.

       K primeru, vy vnesli izmeneniya i proizveli kommit v fajl
       shazam/shazam.c v FreeBSD-CURRENT, a pozdnee hotite perenesti
       obnovleniya v FreeBSD-STABLE (Merge-From-Current, MFC). Versiya,
       kotoraya trebuet perenosa - 1.15:

          * Izvlekite tekuschuyu versiyu modulya shazam dlya vetvi
            FreeBSD-STABLE:

 % cvs co -rRELENG_6 shazam

          * Prilozhite izmeneniya mezhdu versiyami 1.14 i 1.15:

 % cvs update -j1.14 -j1.15 shazam/shazam.c

       Pochti navernyaka vy poluchite konflikt v strokah, soderzhaschih
       identifikator fajla ($Id: article.xml,v 1.19 2007-05-09 06:08:50 bvs
       Exp $ ili, v sluchae FreeBSD, $FreeBSD$). Vam potrebuetsya
       otredaktirovat' fajl dlya ustraneniya konflikta (v dannom sluchae
       dostatochno ubrat' stroki-razdeliteli i vtoruyu stroku $Id:
       article.xml,v 1.19 2007-05-09 06:08:50 bvs Exp $, ostaviv lish' stroku
       s $Id: article.xml,v 1.19 2007-05-09 06:08:50 bvs Exp $ dlya
       FreeBSD-STABLE).

    4. Prosmotr izmenenie mezhdu lokal'noj versiej i versiej iz repozitoriya:
       komanda diff.

 % cvs diff shazam

       `Eta komanda pokazhet vse otlichiya lokal'nogo sostoyaniya fajla (ili
       fajlov modulya) shazam ot sostoyaniya, sohranennogo v repozitorii.

       Tablica 3. Poleznye opcii komandy cvs diff

       -u Ispol'zovat' unificirovannyj (unified) format.   
       -c Ispol'zovat' kontekstnyj (context) format.       
       -N Pokazyvat' otsutstvuyuschie ili sozdannye fajly. 

       Vsegda imeet smysl pol'zovat'sya opciej -u, poskol'ku unificirovannyj
       format gorazdo udobnee i luchshe chitaem, chem pochti vse drugie (v
       nekotoryh sluchayah kontekstnyj format, generiruemyj opciej -c mozhet
       byt' neskol'ko luchshe, no on gorazdo bolee gromozdok).
       Unificirovannyj format razlichij sostoit iz serii fragmentov, kazhdyj
       iz kotoryh nachinaetsya so stroki, sostoyaschej iz dvuh simvolov @ i
       nomerov strok, opisyvayuschih polozhenie izmenivshegosya uchastka.
       Zatem sleduet gruppa strok: te, chto nachinayutsya s probela,
       opisyvayut kontekst, nachinayuschiesya s simvola - opredelyayut
       udalennye stroki, nakonec, nachinayuschiesya s simvola + -
       dobavlennye.

       Vy mozhete sravnivat' tekuschee sostoyanie s versiej,
       otlichayuschejsya ot toj, s kotoroj vy izvlekali fajl, ukazav opciyu
       -r ili -D podobno komandam checkout i update, ili dazhe poluchit'
       spisok izmenenij mezhdu lyubymi dvumya versiyami (vne zavisimosti ot
       togo, chto lezhit v vashej lokal'noj kopii), ukazav dve versii pri
       pomoschi opcij -r ili -D.

    5. Prosmotr zhurnala izmenenij: komanda log.

 % cvs log shazam

       Esli shazam yavlyaetsya obychnym fajlom, `eta komanda vydast na `ekran
       zagolovok s informaciej o fajle, v chastnosti, ego mestopolozhenii v
       repozitorii, kakaya versiya sootvetstvuet tekuschemu sostoyaniyu
       (HEAD), v kakih vetvyah razrabotki fajl prisutstvuet, a takzhe
       perechislit tegi, kotorymi on pomechen. Zatem, dlya kazhdoj versii
       fajla vyvoditsya sootvetstvuyuschee ej zhurnal'noe soobschenie,
       vklyuchayuschee datu, vremya i avtora kommita, kolichestvo dobavlennyh
       i udalennyh strok i sobstvenno zhurnal'nogo soobscheniya, napisannogo
       kommitterom.

       Esli shazam yavlyaetsya katalogom, vysheopisannaya procedura
       vypolnyaetsya dlya kazhdogo fajla v kataloge. Esli pri `etom komande
       log ne byl ukazan flag -l, procedura rekursivno povtoryaetsya dlya
       vseh podkatalogov.

       Komanda log ispol'zuetsya dlya prosmotra istorii odnogo ili neskol'kih
       fajlov v tom vide, kak ona sohranena v repozitorii CVS. Ispol'zuya
       opciyu -rrev, vy mozhete posmotret' zhurnal'noe soobschenie k odnoj
       opredelennoj versii:

 % cvs log -r1.2 shazam

       `Eta komanda pokazhet zhurnal'noe soobschenie dlya versii 1.2 fajla
       shazam (ili dlya versij 1.2 kazhdogo iz fajlov v kataloge shazam).

    6. Kto chto delal: komanda annotate. `Eta komanda pokazyvaet pered
       kazhdoj strokoj ukazannogo fajla (fajlov) imya pol'zovatelya,
       vnosivshego poslednie izmeneniya v `etu stroku.

 % cvs annotate shazam

    7. Dobavlenie novyh fajlov: komanda add.

       Sozdajte fajl, vypolnite dlya nego komandu cvs add, zatem proizvedite
       zapis' v repozitorij (kommit): cvs commit.

       Tochno tak zhe, novye katalogi dobavlyayutsya v repozitorij putem
       sozdaniya i posleduyuschego vypolneniya komandy cvs add. Zamet'te,
       chto vypolnyat' kommit posle dobavleniya kataloga ne nado.

    8. Udalenie ustarevshih fajlov: komanda remove.

       Udalite fajl, zatem vypolnite komandu cvs rm s ego imenem v kachestve
       parametra, nakonec, vypolnite dlya nego cvs commit.

    9. Vnesenie izmenenij v repozitorij: komanda commit ili checkin.

       Tablica 4. Useful cvs commit options

       -f    Forsirovat' vnesenie izmenenij dlya ne modificirovannogo fajla.  
       -mmsg Ukazat' soobschenie dlya zhurnala v komandnoj stroke (ne         
             zapuskat' tekstovyj redaktor).                                   

       Opciyu -f sleduet ispol'zovat', esli vy ponyali, chto zabyli ukazat'
       kakuyu-libo vazhnuyu informaciyu v zhurnale izmenenij.

       Horoshie zhurnal'nye soobscheniya ochen' vazhny. Oni dayut
       vozmozhnost' drugim uznat', zachem vy proizvodili izmeneniya, prichem
       ne tol'ko v moment ih proizvedeniya, no i mesyacy ili gody spustya,
       kogda kto-libo zainteresuetsya, pochemu vyglyadyaschij nelogichno ili
       ne`effektivno fragment koda popal v kashi ishodnye teksty. Krome togo,
       `eto ochen' pomogaet v ocenke togo, nuzhno li perenosit'
       sootvetstvuyuschij kod v FreeBSD-STABLE (MFC).

       Soobscheniya dolzhny byt' yasnymi, kratkimi, chetkimi, i predstavlyat'
       iz sebya razumnuyu annotaciyu, kakie izmeneniya byli proizvedeny i
       pochemu.

       Soobscheniya dolzhny dostatochno yasno pokazyvat' storonnim
       razrabotchikam, naskol'ko ih kasayutsya izmeneniya i nuzhno li im
       issledovat' izmeneniya podrobno.

       Izbegajte vneseniya neskol'kih ne svyazannyh drug s drugom izmenenij
       za odin raz. `Eto zatrudnyaet ob"edinenie izmenenij, a takzhe, pri
       obnaruzhenii oshibok, uslozhnyaet poisk otvetstvennogo za oshibki
       uchastka.

       Izbegajte smeshivaniya v odnom kommite izmenenij funkcional'nosti so
       stilisticheskimi pravkami ili ispravleniyami v probelah. `Eto
       uslozhnyaet ob"edinenie, i, krome togo, zatrudnyaet ponimanie togo,
       kakie imenno funkcional'nye izmeneniya byli vneseny. V sluchae kommita
       v fajly dokumentacii, `eto zatrudnit rabotu grupp podderzhki perevoda,
       poskol'ku stanovitsya slozhnee otdelit' izmeneniya, trebuyuschie
       perevoda.

       Izbegajte kommita bol'shoj gruppy fajlov za odin raz s odnim obschim i
       nevnyatnym soobscheniem. Naprotiv, vnosite izmeneniya v otdel'nye
       fajly (ili nebol'shie gruppy svyazannyh fajlov) s adekvatnymi
       soobscheniyami dlya zhurnalirovaniya.

       Pered kommitom, obyazatel'no:

          * prover'te, chto vy budete vypolnyat' kommit v pravil'nuyu vetv',
            posredstvom komandy cvs status.

          * prover'te vashi izmeneniya pri pomoschi komandy cvs diff

       Krome togo, VSEGDA ukazyvajte, v kakie imenno fajly vy vnosite
       izmeneniya, tak chtoby ne vklyuchit' v `etot spisok lishnih fajlov.
       Komanda cvs commit bez argumentov vklyuchit vse izmenennye fajly v
       tekuschem kataloge i vseh podkatalogah.

   Esche neskol'ko poleznyh sovetov:

    1. CHasto ispol'zuemye opcii mozhno zanesti v fajl ~/.cvsrc, naprimer:

 cvs -z3
 diff -Nu
 update -Pd
 checkout -P

       Dlya dannogo sluchaya:

          * vsegda ispol'zovat' kompressiyu urovnya 3 dlya svyazi s udalennym
            serverom CVS. V sluchae medlennogo soedineniya `eto izbavit vas
            ot lishnej golovnoj boli.

          * vsegda ispol'zovat' opcii -N (pokazyvat' dobavlennye ili
            udalennye fajly) i -u (unificirovannyj format) dlya diff(1).

          * vsegda ispol'zovat' opcii -P (udalyat' pustye katalogi) i -d
            (dobavlyat' novye katalogi) pri obnovlenii.

          * vsegda ispol'zovat' opciyu -P (udalyat' pustye katalogi) pri
            izvlechenii fajlov i modulej.

    2. Pol'zujtes' skriptom `Ejvinda `Eklunda (Eivind Eklund) cdiff dlya
       prosmotra izmeneniyu unificirovannogo formata. On yavlyaetsya obertkoj
       dlya less(1), dobavlyayuschej cvetovye kody ANSI dlya vydeleniya
       zagolovkom, dobavlennyh i udalennyh strok; prochie stroki ne
       modificiruyutsya. Pomimo `etogo, skript korrektno razvorachivaet
       tabulyacii (kotorye chasto vyglyadyat nepravil'no v izmeneniyah iz-za
       dopolnitel'nogo simvola v nachale stroki).

       textproc/cdiff

       Prosto ispol'zujte ego vmesto more(1) ili less(1):

 % cvs diff -Nu shazam | cdiff

       Pomimo `etogo, nekotorye tekstovye redaktory, takie kak vim(1)
       (editors/vim) podderzhivayut cvetovuyu sintaksicheskuyu razmetku
       mnogih tipov fajlov, v tom chisle fajlov izmenenij i zhurnalov
       CVS/RCS.

 % echo "syn on" >> ~/.vimrc
 % cvs diff -Nu shazam | vim -
 % cvs log shazam | vim -

    3. CVS - staraya, zagadochnaya i poroj slabo predskazuemaya v svoem
       povedenii programma. Ni odin chelovek ne sposoben uderzhat' v golove
       vse tonkosti ee raboty, tak chto ne bojtes' sprashivat' soveta u
       Iskusstvennogo Intellekta (a imenno Administratory Glavnogo CVS
       Repozitoriya <cvsadm@FreeBSD.org>).

    4. Ne ostavlyajte komp'yuter v processe raboty komandy cvs commit (v
       redaktore pri napisanii zhurnal'nogo soobscheniya) slishkom nadolgo
       (bolee chem na 2-3 minuty). `Eta komanda blokiruet katalog
       repozitoriya, v kotorom ona zapuschena, i ne pozvolyaet drugim
       razrabotchikam izmenyat' ego soderzhimoe. Esli vam nuzhno napisat'
       dlinnoe zhurnal'noe soobschenie, podgotov'te ego zaranee i vstav'te v
       redaktore vo vremya vypolneniya komandy cvs commit, libo zapishite ego
       v fajl i ispol'zujte opciyu CVS -F:

 % vi logmsg
 % cvs ci -F logmsg shazam

       `Eto samyj bystryj sposob peredat' zhurnal'noe soobschenie CVS;
       odnako, vy dolzhny byt' vnimatel'ny pri redaktirovanii fajla logmsg,
       poskol'ku pri vypolnenii kommita u vas ne budet shansov ego popravit'.

    5. Vy mozhete suschestvenno uskorit' skorost' raboty CVS s central'nym
       repozitoriem, ispol'zuya postoyannoe soedinenie s repozitoriem. Dlya
       `etogo dobav'te v fajl ~/.ssh/config stroki

 Host ncvs.FreeBSD.org
       ControlPath /home/user/.ssh/cvs.cpath
 Host dcvs.FreeBSD.org
       ControlPath /home/user/.ssh/cvs.cpath
 Host projcvs.FreeBSD.org
       ControlPath /home/user/.ssh/cvs.cpath
 Host pcvs.FreeBSD.org
       ControlPath /home/user/.ssh/cvs.cpath

       Zatem otkrojte postoyannoe soedinenie s mashinoj repoman:

 % ssh -fNM ncvs.FreeBSD.org

       Teper' komandy CVS dolzhny vypolnyat'sya bystree, poskol'ku
       ispol'zuyut suschestvuyuschee soedinenie s repozitoriem. Uchtite, chto
       registr v imenah hostov imeet znachenie.

4. Soglasheniya i tradicii

   Stav kommitterom, vy dolzhny prezhde vsego proizvesti nekotorye
   standartnye dejstviya.

     * Dobav'te sebya v spisok <<SGML suschnostej>> avtorov v fajl
       doc/en_US.ISO8859-1/share/xml/authors.ent; `eto izmenenie dolzhno byt'
       sdelano prezhde prochih, poskol'ku v protivnom sluchae sleduyuschij
       vash kommit neizbezhno razrushit process postroeniya dereva doc/.

       `Eto dovol'no prostaya zadacha, no pri `etom ona yavlyaetsya neplohim
       pervym testom vashih navykov raboty s CVS.

     * Takzhe dobav'te svoyu <<SGML suschnost'>> v www/en/developers.xml.

     * Dobav'te sebya v razdel <<Razrabotchiki>> stat'i Uchastniki proekta
       FreeBSD
       (doc/en_US.ISO8859-1/articles/contributors/contrib.committers.xml) i
       udalite svoyu zapis' iz razdela <<Prochie uchastniki>>
       (doc/en_US.ISO8859-1/articles/contributors/contrib.additional.xml).

     * Dobav'te novost' o novom kommittere v fajl www/share/xml/news.xml.
       Ispol'zujte suschestvuyuschie zapisi vida <<Novyj kommitter>> kak
       shablon.

     * Vam nuzhno dobavit' vash PGP ili GnuPG klyuch v katalog
       doc/share/pgpkeys (a esli u vas net klyucha, vam nuzhno ego sozdat').
       Ne zabud'te izmenit' i proizvesti kommit v fajl
       doc/share/pgpkeys/pgpkeys.ent.

       Dag-Erling Smorgrav <des@FreeBSD.org> napisal skript dlya uproscheniya
       `etogo processa. Dopolnitel'nuyu informaciyu mozhno prochest' v fajle
       README.

  Primechanie:

       Ochen' vazhno, chtoby v Rukovodstve pol'zovatelya byl zapisan
       aktual'nyj PGP/GnuPG klyuch, poskol'ku on mozhet potrebovat'sya dlya
       identifikacii kommittera (naprimer, ego budet proveryat' gruppa
       Administratory FreeBSD.org <admins@FreeBSD.org> dlya avarijnogo
       vosstanovleniya uchetnoj zapisi). Polnyj nabor aktual'nyh klyuchej
       pol'zovatelej domena FreeBSD.org mozhno najti po adresu
       http://www.FreeBSD.org/doc/pgpkeyring.txt.

     * Dobav'te sebya v fajl src/share/misc/committers-repozitorij.dot, gde
       repozitoriem budet yavlyat'sya libo doc, libo ports, libo src v
       zavisimosti ot poluchennyh vami kommitterskih privilegij.

     * Nekotorye kommittery dobavlyayut informaciyu o svoem mestopolozhenii v
       fajl ports/astro/xearth/files/freebsd.committers.markers.

     * Nekotorye dobavlyayut dannye o dne svoego rozhdeniya v fajl
       src/usr.bin/calendar/calendars/calendar.freebsd.

     * Predstav'tes' drugim kommitteram, inache nikto ne budet znat', kto vy
       i chem zanimaetes'. Ot vas ne trebuetsya pisat' podrobnoe rezyume ili
       biografiyu: budut dostatochny odin-dva abzaca o sebe i oblastyah
       FreeBSD, v kotoryh vy planiruete rabotat'. Poshlite `eto pis'mo v
       Spisok rassylki razrabotchikov FreeBSD - i vse!

     * Zajdite na mashinu hub.FreeBSD.org i sozdajte fajl /var/forward/user
       (zamenite user na vashe imya pol'zovatelya). `Etot fajl dolzhen
       soderzhat' adres `elektronnoj pochty, na kotoryj budet
       perepravlyat'sya vsya pochta na adres yourusername@FreeBSD.org, v tom
       chisle soobscheniya o kommitah i drugaya pochta na adresa Spisok
       rassylki kommitterov FreeBSD i Spisok rassylki razrabotchikov FreeBSD.
       Slishkom bol'shie pochtovye yaschiki na mashine hub mogut byt'
       <<nechayanno>> udaleny ili obrezany bez preduprezhdeniya, tak chto,
       chtoby ne poteryat' pochtu, regulyarno chitajte ee libo perenaprav'te
       kuda-nibud' esche.

       Iz-za oschutimoj zagruzki, voznikayuschej na serverah,
       obrabatyvayuschih spiski rassylki, iz-za bol'shogo kolichestva
       nezaproshennoj pochty (spama), server, prinimayuschij pochtu dlya
       domena FreeBSD.org, proizvodit nekotorye osnovnye proverki i na
       osnovanii ih otvergaet nekotorye pis'ma. Na nastoyaschij moment
       edinstvennym proveryaemym parametrom yavlyaetsya korrektnost'
       informacii DNS dlya hosta, dostavlyayuschego pochtu, no v buduschem
       spisok mozhet vyrasti. `Eti proverki vremenami obvinyayut v tom, chto
       oni otvergayut pravil'nuyu pochtu. Esli vy hotite otklyuchit' proverki
       dlya svoego adresa, sozdajte fajl ~/.spam_lover v svoej domashnej
       direktorii na mashine freefall.FreeBSD.org.

     * Esli vy byli podpisany na Spisok rassylki soobschenij ob izmeneniyah v
       glavnom dereve ishodnyh tekstov FreeBSD, vam, skoree vsego, sleduet
       otpisat'sya ot nego, chtoby ne poluchat' dublikatov kazhdogo
       soobscheniya o kommitah.

   Vse novye kommittery pervonachal'no rabotayut pod rukovodstvom mentora.
   Vash mentor otvechaet za obuchenie vas pravilam i soglasheniyam, prinyatym
   v proekte, i pomogaet vam sdelat' pervye shagi v srede kommitterov. On(a)
   takzhe personal'no otvechaet za vashi dejstviya v `etot nachal'nyj period.
   Do teh por, poka vash mentor ne reshit (i ne anonsiruet `eto posredstvom
   forsirovannogo kommita fajla access), chto vy dostatochno osvoilis' i
   gotovy rabotat' samostoyatel'no, pered lyubym kommitom vy dolzhny
   poluchit' odobrenie (approval) mentora i ukazat' `eto v zhurnal'nom
   soobschenii kommita strokoj Approved by:.

   Vse kommity v derevo src snachala dolzhny proizvodit'sya v vetv'
   FreeBSD-CURRENT i lish' zatem integrirovat'sya v FreeBSD-STABLE. Nikakie
   ser'eznye izmeneniya, novye vozmozhnosti ili riskovannye modifikacii ne
   dolzhny proizvodit'sya napryamuyu v vetvi FreeBSD-STABLE.

5. Predpochtitel'naya licenziya dlya novyh fajlov

   V nastoyaschee vremya Proekt FreeBSD schitaet predpochtitel'noj formoj
   licenzii na ishodnye teksty sleduyuschij tekst:

 /*-
 * Copyright (c) [year] [your name]
 * All rights reserved.
 *
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions
 * are met:
 * 1. Redistributions of source code must retain the above copyright
 *    notice, this list of conditions and the following disclaimer.
 * 2. Redistributions in binary form must reproduce the above copyright
 *    notice, this list of conditions and the following disclaimer in the
 *    documentation and/or other materials provided with the distribution.
 *
 * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
 * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
 * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
 * ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
 * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
 * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
 * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
 * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
 * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
 * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
 * SUCH DAMAGE.
 *
 * [id for your version control system, if any]
 */

   Proekt FreeBSD krajne ne rekomenduet tak nazyvaemyj <<tretij punkt>>, ili
   <<punkt o reklame>> v licenzii na novyj ishodnyj kod. V svyazi s bol'shim
   kolichestvom uchastnikov proekta FreeBSD, vypolnenie `etogo punkta
   bol'shinstvom kommercheskih proizvoditelej vse bolee zatrudnitel'no. Esli
   vash kod v dereve ishodnikov soderzhit <<punkt o reklame>>, rassmotrite
   vozmozhnost' ego udaleniya. Na samom dele, rassmotrite vozmozhnost'
   perehoda na privedennuyu licenziyu.

   Proekt FreeBSD ne rekomenduet ispol'zovanie polnost'yu novyh licenzij ili
   variacij standartnyh licenzij. Novye licenzii pered ispol'zovaniem v
   repozitorii proekta trebuyut utverzhdeniya gruppoj <core@FreeBSD.org>.
   Bol'shoe chislo razlichnyh licenzij zatrudnyaet ispol'zovanie koda, v
   osnovnom iz-za nenamerennyh nevernyh vyvodov iz ploho sformulirovannyh
   formulirovok licenzii.

   Politika proekta trebuet, chtoby kod pod NE-BSD licenziyami raspolagalsya
   tol'ko v opredelionnyh mestah repozitoriya, a v nekotoryh sluchayah
   kompilyaciya dolzhna byt' uslovnoj po umolchaniyu ili voobsche
   otklyuchena. K primeru, yadro GENERIC dolzhno sostoyat' tol'ko iz licenzij
   identichnyh ili v znachitel'noj stepeni shozhih s BSD licenziej.
   Programmnoe obespechenie pod licenziyami GPL, APSL, CDDL i dr. ne dolzhno
   vklyuchat'sya v sostav GENERIC.

   Razrabotchikam napominaetsya, chto v open source pravil'noe ponimanie
   "open" takzhe vazhno, kak pravil'noe ponimanie "source", ibo nekorrektnoe
   ispol'zovanie intellektual'noj sobstvennosti imeet ser'eznye posledstviya.
   Kakie-libo voprosy ili bespokojstva na `etot schiot dolzhny byt'
   nemedlenno vyneseny na obsuzhdenie glavnoj komande razrabotchikov (core
   team).

6. Vzaimodejstvie mezhdu razrabotchikami

   Esli vy rabotaete nad sobstvennym ishodnym kodom, libo v oblasti, v
   kotoroj vy uzhe opredeleny kak otvetstvennaya persona, vam, skoree vsego,
   ne potrebuetsya soglasovyvat' kommit s kem-libo esche iz razrabotchikov.
   Te zhe pravila dejstvuyut, esli vy nashli oshibku v toj chasti sistemy,
   kotoroj yavno davno nikto ne zanimaetsya (k nashemu stydu, suschestvuet
   neskol'ko takih oblastej). Esli zhe vy sobiraetes' modificirovat'
   chto-libo aktivno podderzhivaemoe (po-horoshemu, uznat' `eto mozhno tol'ko
   issleduya arhivy spiska rassylki cvs-committers), stoit poslat'
   predpolagaemyj patch otvetstvennomu za `etot uchastok koda, kak vy by
   postupali, poka ne byli kommitterom. V sluchae portov nuzhno obraschat'sya
   po adresu, ukazannomu v stroke MAINTAINER v fajle Makefile. Dlya drugih
   chastej repozitoriya, v sluchae esli vam ne ochevidno, kto vedet dannyj
   uchastok koda, mozhet pomoch' issledovanie vyvoda komandy cvs log. Bill
   Fenner <fenner@FreeBSD.org> napisal otlichnyj skript dlya opredeleniya
   razrabotchikov, naibolee aktivno proizvodivshih kommity, vyvodyaschij dlya
   kazhdogo iz ukazannyh fajlov imya pol'zovatelya vmeste s kolichestvom
   proizvedennyh im kommitov v dannyj fajl. Skript mozhno najti na mashine
   freefall v fajle ~fenner/bin/whodid. Esli najdennaya vami persona ne
   otvechaet na vashi voprosy ili inym obrazom demonstriruet otsutstvie
   interesa k probleme, smelo proizvodite kommit samostoyatel'no.

   Esli vy po kakim-libo prichinam ne uvereny v svoih izmeneniyah,
   predlozhite ih dlya ocenki v spiske rassylki -hackers pered kommitom.
   Budet luchshe, esli vas obrugayut tam i togda, chem kogda predlagaemoe
   izmenenie uzhe budet chast'yu repozitoriya. Esli sluchilos' tak, chto vash
   kommit vstretil soprotivlenie, vozmozhno, stoit ego otkatit' (back out) do
   teh por, poka ne budet dostignut konsensus. Pomnite - s pomosch'yu CVS
   vsegda mozhno vernut'sya k predyduschemu sostoyaniyu.

   Ne prinimajte v shtyki mneniya drugih razrabotchikov, s kotorymi vy ne
   soglasny. Esli oni predlagayut inoe reshenie problemy chem vy, ili dazhe
   inache vosprinimayut problemu, `eto ne znachit, chto oni glupy, imeyut
   somnitel'noe proishozhdenie, hotyat razrushit' vashu rabotu, ochernit'
   vashe dobroe imya, ili razvalit' proekt FreeBSD. Prosto oni smotryat na
   mir pod inym uglom. Razlichnye vzglyady - blago.

   Bud'te chestny v sporah. Ocenivajte svoyu poziciyu po zaslugam, chestno
   otnosites' k ee slabym storonam i bud'te gotovy prinyat' drugie tochki
   zreniya i puti resheniya. Bud'te otkryty.

   Bud'te terpimy, esli vas popravlyayut. Vse my sovershaem oshibki. Esli vy
   oshiblis', izvinites'. Ne obvinyajte ni sebya, ni, tem bolee, drugih v
   oshibke. Ne teryajte vremeni na smuschenie ili upreki, prosto isprav'te
   oshibku i dvigajtes' dal'she.

   Sprashivajte i prosite o pomoschi. Predlagajte vashi izmeneniya dlya
   rassmotreniya kollegam i rassmatrivajte ih izmeneniya. Odnim iz
   preimuschestv programmnogo obespecheniya s otkrytymi ishodnymi tekstami
   yavlyaetsya otkrytost' razrabotki. Esli nikto ne budet issledovat' chuzhoj
   kod, `eto preimuschestvo ischeznet.

7. GNATS

   Dlya otslezhivaniya oshibok i zaprosov na izmeneniya proekt FreeBSD
   ispol'zuet GNATS. Esli vy ispravili oshibku ili vnesli izmeneniya,
   opisannye v odnom iz soobschenij ob oshibkah (PR), ne zabud'te zakryt'
   `eto soobschenie, ispol'zuya komandu edit-pr pr-number na mashine
   freefall. Horosho budet, esli vy potratite nemnogo vremeni na poisk i
   zakrytie drugih PR po `etoj teme. Vy i sami mozhete pol'zovat'sya
   send-pr(1) dlya predlozheniya izmenenij, kotorye, po vashemu mneniyu,
   mogut potrebovat' bolee podrobnogo obsuzhdeniya s kollegami.

   Bolee podrobno o GNATS mozhno prochitat' po adresam:

     * http://www.cs.utah.edu/csinfo/texinfo/gnats/gnats.html

     * http://www.FreeBSD.org/support.html

     * send-pr(1)

   Vy mozhete pol'zovat'sya lokal'noj kopiej GNATS, podderzhivaya ee
   sinhronnost' pri pomoschi CVSup. Pri `etom vy mozhete ispol'zovat' komandy
   GNATS lokal'no, a takzhe pol'zovat'sya drugimi interfejsami, takimi kak
   tkgnats, chto pozvolit vam rabotat' s bazoj soobschenij ob oshibkah bez
   soedineniya s Internet.

   Procedura 1. Ispol'zovanie lokal'noj kopii GNATS
    1. Esli vy esche ne podderzhivaete zerkalo dereva GNATS, dobav'te v vash
       supfile stroku

 gnats release=current prefix=/usr

       Uchtite, chto `eta stroka dolzhna predshestvovat' lyubym strokam,
       soderzhaschim parametr <<tag=>>, poskol'ku derevo GNATS ne nahoditsya
       pod upravleniem CVS i ne imeet simvol'nyh metok.

       Posle zapuska cvsup v kataloge /usr/gnats budet sozdana kopiya dereva
       GNATS FreeBSD. Vy mozhete ispol'zovat' fajl refuse dlya kopirovaniya
       otdel'nyh kategorij. Naprimer, esli vas interesuyut tol'ko
       soobscheniya kategorii docs, dobav'te v fajl
       /usr/local/etc/cvsup/sup/refuse[1] stroku

 gnats/[a-ce-z]*

       Prochie primery v `etom razdele podrazumevayut, chto vy
       sinhroniziruete tol'ko kategoriyu docs.

    2. Ustanovite port GNATS iz ports/databases/gnats. Posle ustanovki vy
       obnaruzhite razlichnye sluzhebnye katalogi v dereve
       $PREFIX/share/gnats.

    3. Sozdajte simvol'nye ssylki na sinhronizirovannye katalogi GNATS v
       sluzhebnyj katalog GNATS:

 # cd /usr/local/share/gnats/gnats-db
 # ln -s /usr/gnats/docs

       Prodelajte `etu operaciyu dlya vseh sinhroniziruemyh kategorij.

    4. Obnovite sluzhebnyj fajl GNATS categories, raspolozhennyj v kataloge
       $PREFIX/share/gnats/gnats-db/gnats-adm:

 # This category is mandatory
 pending:Category for faulty PRs:gnats-admin:
 #
 # FreeBSD categories
 #
 docs:Documentation Bug:freebsd-doc:

    5. Zapustite $PREFIX/libexec/gnats/gen-index dlya sozdaniya indeksa.
       Vyvod `etoj komandy dolzhen byt' perenapravlen v fajl
       $PREFIX/share/gnats/gnats-db/gnats-adm/index. `Etu operaciyu mozhno
       vypolnyat' periodicheski pri pomoschi cron(8) ili zapuskat' cvsup(1)
       iz skripta, kotoryj zatem sgeneriruet novyj indeks:

 # /usr/local/libexec/gnats/gen-index \
         > /usr/local/share/gnats/gnats-db/gnats-adm/index

    6. Protestirujte sozdannuyu konfiguraciyu zaprosom k baze dannyh GNATS.
       Sleduyuschaya komanda vyvedet spisok otkrytyh soobschenij ob oshibkah
       v kategorii docs:

 # query-pr -c docs -s open

       Drugie interfejsy, naprimer, port databases/tkgnats takzhe dolzhny
       rabotat'.

    7. Vyberite PR i zakrojte ego.

  Primechanie:

   Opisannaya procedura pozvolyaet vam vybirat' i prosmatrivat' soobscheniya
   ob oshibkah lokal'no. Dlya redaktirovaniya ili zakrytiya vam potrebuetsya
   zajti na mashinu freefall.

8. Kto est' kto

   Pomimo masterov repozitoriya, suschestvuet esche neskol'ko uchastnikov i
   grupp proekta FreeBSD, s kotorymi vam kak kommitteru mozhet potrebovat'sya
   obschat'sya. Kratkij i ni v koem sluchae ne polnyj spisok privoditsya
   nizhe.

   John Baldwin <jhb@FreeBSD.org>

           Dzhon vozglavlyaet proekt SMPng i otvechaet za arhitekturu, dizajn
           i realizaciyu perehoda na mnogonitevoe yadro. Dzhon takzhe
           yavlyaetsya redaktorom stat'i "Arhitektura SMPng". Esli vy
           rabotaete s tonkimi blokirovkami mnogoprocessornogo yadra,
           koordinirujte svoyu rabotu s Dzhonom.

   Gruppa Menedzherov Dereva Dokumentacii FreeBSD <doceng@FreeBSD.org>

           doceng - gruppa, otvechayuschaya za infrastrukturu postroeniya
           dokumentacii, priem novyh kommitterov dokumentacii i aktual'nost'
           informacii otnositel'no CVS na veb-sajte i FTP-sajte FreeBSD. `Eta
           gruppa ne razbiraet konflikty. Bol'shaya chast' obsuzhdenij,
           svyazannyh s dokumentaciej, proishodit v Spisok rassylki Proekta
           Dokumentacii FreeBSD. Dopolnitel'nuyu informaciyu o deyatel'nosti
           gruppy mozhno najti v ee sobstvennom dokumente. Kommittery,
           zainteresovannye v obnovlenii dokumentacii, dolzhny oznakomit'sya
           s Uchebnikom po Proektu Dokumentirovaniya FreeBSD dlya novyh
           uchastnikov.

   Ruslan Ermilov <ru@FreeBSD.org>

           Ruslan velikolepno znaet tonkosti mdoc(7). Esli vy pishete
           spravochnuyu stranicu i nuzhdaetes' v sovete po ee strukture ili
           razmetke, obratites' k Ruslanu.

   Bruce Evans <bde@FreeBSD.org>

           Bryus zanimaetsya obschim stilem koda proekta. Esli vash kommit
           mog by byt' luchshe oformlen, Bryus ukazhet vam na `eto.
           Radujtes', chto takoj chelovek voobsche est'. Bryus takzhe
           yavlyaetsya znatokom razlichnyh standartov, primenimyh k FreeBSD.

   Murray Stokely <murray@FreeBSD.org>, Doug White <dwhite@FreeBSD.org>,
   Robert Watson <rwatson@FreeBSD.org>, Ken Smith <kensmith@FreeBSD.org>,
   Hiroki Sato <hrs@FreeBSD.org>, Maxime Henrion <mux@FreeBSD.org>, Bruce A.
   Mah <bmah@FreeBSD.org>

           Takov sostav gruppy Gruppa Vypuska Relizov FreeBSD
           <re@FreeBSD.org>. `Eta gruppa otvechaet za sroki i process vypuska
           relizov. V period zamorozki koda, vypuskayuschie inzhenery
           prinimayut okonchatel'nye resheniya po povodu vseh izmenenij
           sistemy v vetvi, gotovyaschejsya k ocherednomu relizu. Esli vy
           hotite integrirovat' kakie-libo izmeneniya iz FreeBSD-CURRENT v
           FreeBSD-STABLE (kakimi by oni ni byli v dannyj konkretnyj moment),
           vam predstoit obschat'sya s `etoj gruppoj.

           Hiroki, krome togo, vedet razdel dokumentacii k relizam
           (src/release/doc/*). Esli vashi izmeneniya stoyat togo, chtoby
           byt' upomyanutymi v informacii o relize, soobschite ob `etom
           Hiroki. Esche luchshe, esli vy poshlete patch s predlagaemymi
           izmeneniyami k dokumentu.

   Colin Percival <cperciva@FreeBSD.org>

           Kolin - FreeBSD Security Officer i otvechaet za deyatel'nost'
           gruppy Gruppa Oficerov Bezopasnosti
           <security-officer@FreeBSD.org>.

   Garrett Wollman <wollman@FreeBSD.org>

           Esli vam nuzhen sovet po povodu temnyh mest setevoj chasti yadra,
           ili vy ne uvereny v planiruemom izmenenii setevoj podsistemy,
           mudrym resheniem budet obratit'sya k Garrettu. Pomimo togo, on
           horosho razbiraetsya v razlichnyh standartah, primenimyh k
           FreeBSD.

   Spisok rassylki kommitterov FreeBSD

           cvs-committers - adres, ispol'zuemyj CVS dlya posylki soobschenij
           o kommitah. Vy nikogda ne dolzhny posylat' pis'ma napryamuyu na
           `etot adres; sleduet lish' otvechat' na nego, kogda vam nuzhno
           poslat' korotkie kommentarii, neposredstvenno otnosyaschiesya k
           kommitu.

   Spisok rassylki razrabotchikov FreeBSD

           Vse kommittery podpisany na spisok rassylki -developers. `Etot
           spisok sozdan dlya obsuzhdeniya voprosov, kasayuschihsya
           <<soobschestva>> kommitterov FreeBSD, takih kak vybory Pravleniya,
           anonsy i t.p.

           Spisok rassylki razrabotchikov FreeBSD sluzhit dlya tol'ko dlya
           ispol'zovaniya FreeBSD kommitterami. Kommittery dolzhny imet'
           vozmozhnost' publichno obsuzhdat' veschi, kotorye dolzhny byt'
           razresheny, pered tem, kak oni budut publichno ob"yavleny. Dannye
           diskussii ne prednaznacheny dlya shirokoj publiki i mogut nanesti
           vred FreeBSD.

           Vse FreeBSD kommittery dolzhny soblyudat' avtorskie prava
           original'nogo avtora ili avtorov pisem iz `etogo spiska rassylki.
           Ne publikujte i ne peresylajte soobscheniya iz Spisok rassylki
           razrabotchikov FreeBSD vne podpischikov dannogo spiska rassylki
           bez soglasiya vseh avtorov.

           Narushiteli avtorskih prav budut udaleny iz spiska podpischikov
           Spisok rassylki razrabotchikov FreeBSD, i budut priostanovleny ih
           kommitterskie privilegii. Povtoryayuschiesya ili vopiyuschie
           narusheniya privedut k polnomu lisheniyu kommitterskih prav.

           `Etot spisok ne prednaznachen dlya obsuzhdeniya koda, i ne
           yavlyaetsya zamenoj spiskov Spisok rassylki, posvyaschionnyj
           arhitekture i vnutrennemu ustrojstvu FreeBSD ili Spisok rassylki,
           posvyaschionnyj auditu koda FreeBSD. Na samom dele, takoe ego
           ispol'zovanie vredit proektu, poskol'ku otkrytye obsuzhdeniya
           voprosov, kasayuschihsya vsego soobschestva pol'zovatelej FreeBSD
           v zakrytom spiske nedopustimy. I, nakonec: nikogda, dejstvitel'no
           nikogda ne pishite v Spisok rassylki razrabotchikov FreeBSD s
           kopiej v drugoj spisok rassylki FreeBSD. Nikogda ne pishite v
           kakoj-libo drugoj spisok rassylki s kopiej v Spisok rassylki
           razrabotchikov FreeBSD. Podobnye dejstviya ser'ezno podryvayut
           smysl suschestvovaniya dannogo spiska rassylki.

9. SSH: bystryj start

    1. Esli vy ispol'zuete FreeBSD versii 4.0 ili bolee pozdnyuyu, OpenSSH
       vklyuchen v bazovuyu postavku sistemy. Dlya bolee rannih versij
       obnovite i ustanovite OpenSSH iz porta security/openssh.

    2. Dlya teh, kto ne hochet nabirat' svoj parol' kazhdyj raz pri
       ispol'zovanii ssh(1) i ispol'zuet dlya avtorizacii klyuchi RSA ili
       DSA, udobnoj budet utilita ssh-agent(1). Esli vy sobiraetes'
       ispol'zovat' ee, ubedites', chto ona zapuschena ran'she prochih
       prilozhenij. Pol'zovateli X Window, naprimer, obychno zapuskayut ee iz
       fajlov .xsession ili .xinitrc. Podrobnee smotrite v spravochnoj
       stranice ssh-agent(1).

    3. Sozdajte paru klyuchej pri pomoschi ssh-keygen(1). Klyuchi poyavyatsya
       v kataloge $HOME/.ssh/.

    4. Poshlite vash publichnyj klyuch (soderzhimoe fajla
       $HOME/.ssh/id_dsa.pub ili $HOME/.ssh/id_rsa.pub) vashemu buduschemu
       mentoru, chtoby on mog byt' pomeschen v fajl yourlogin v kataloge
       /c/ssh-keys/ na mashine freefall.

   Teper' vy mozhete pol'zovat'sya utilitoj ssh-add(1) dlya avtorizacii odin
   raz za sessiyu. Utilita zaprosit kodovuyu frazu dlya vashego sekretnogo
   klyucha i zatem sohranit ee v agente avtorizacii (ssh-agent(1)). Esli vy
   hotite udalit' sohranennyj sekretnyj klyuch iz agenta, ispol'zujte komandu
   ssh-add -d.

   Dlya testa ispol'zujte komandu tipa ssh freefall.FreeBSD.org ls /usr.

   Za dopolnitel'noj informaciej obraschajtes' k security/openssh, ssh(1),
   ssh-add(1), ssh-agent(1), ssh-keygen(1) i scp(1).

10. Bol'shoj Spisok Pravil Kommittera FreeBSD

    1. Uvazhajte drugih kommitterov.

    2. Uvazhajte drugih uchastnikov proekta.

    3. Obsudite lyubye znachimye izmeneniya do kommita.

    4. Uvazhajte suschestvuyuschih mejntejnerov (ukazannyh v pole MAINTAINER
       fajlov Makefile ili v fajle MAINTAINER v kornevom kataloge
       repozitoriya).

    5. Lyuboe spornoe izmenenie neobhodimo otkatit' (back out) v ozhidanii
       resheniya, esli togo trebuet mejntejner. Voprosy bezopasnosti mogut
       perekryvat' mnenie mejntejnera, esli tak reshit Security Officer.

    6. Izmeneniya vnosyatsya v vetv' FreeBSD-CURRENT do FreeBSD-STABLE, za
       isklyucheniem sluchaev, pryamo razreshennyh vypuskayuschimi
       inzhenerami ili neprimenimosti izmeneniya k FreeBSD-CURRENT. Lyuboe
       netrivial'noe i ne srochnoe izmenenie dolzhno byt' vyderzhano v
       FreeBSD-CURRENT v techenie po krajnej mere 3 dnej pered perenosom,
       chtoby ego mogli adekvatno protestirovat'. Vypuskayuschie inzhenery
       obladayut toj zhe vlast'yu v vetvi FreeBSD-STABLE, chto i mejntejnery
       (sm. pravilo 5).

    7. Ne prerekajtes' s drugimi kommitterami publichno: `eto durno
       vyglyadit. Esli vam neobhodimo s chem-libo <<kategoricheski ne
       soglasit'sya>>, delajte `eto lichnoj pochtoj.

    8. Soblyudajte vse periody zamorozki koda (core freeze), a takzhe
       svoevremenno chitajte spiski rassylki committers i developers, chtoby
       byt' v kurse raspisaniya takih periodov.

    9. Esli vy somnevaetes' v kakoj-libo procedure, snachala sprosite!

   10. Testirujte svoi izmeneniya pered kommitom.

   11. Ne proizvodite kommit v derev'ya src/contrib, src/crypto i
       src/sys/contrib bez pryamogo razresheniya (approval)
       sootvetstvuyuschego mejntejnera(ov).

   Nevypolnenie `etih pravil mozhet sluzhit' osnovaniem dlya priostanovki
   ili, v sluchae recidivov, polnogo lisheniya kommitterskih prav. CHleny
   Pravleniya (Core) imeyut pravo vremenno priostanovit' prava kommittera do
   momenta, kogda Pravlenie v celom smozhet reshit' vopros. V <<avarijnom>>
   sluchae (kommitter razrushaet repozitorij) takie prava imeyut takzhe
   otvetstvennye za repozitorij. Dlya priostanovki prav kommittera bolee chem
   na nedelyu ili dlya polnogo lisheniya takovyh prav trebuetsya
   kvalificirovannoe bol'shinstvo (2/3) golosov Pravleniya. `Eto pravilo
   suschestvuet ne potomu, chto Pravlenie sostoit iz zlobnyh diktatorov,
   razbrasyvayuschihsya kommitterami slovno bankami iz-pod koly, no radi
   predostavleniya proektu avarijnogo vyklyuchatelya. Esli kto-to vyhodit
   iz-pod kontrolya, vazhno imet' vozmozhnost' spravit'sya s situaciej
   nemedlenno, a ne byt' vtyanutymi v debaty. V lyubom sluchae, kommitter,
   ch'i prava priostanovleny, imeet pravo na <<slushaniya Pravleniya>>, na
   kotoryh opredelyaetsya srok priostanovki ili lisheniya kommitterskih prav.
   Kommitter, prava kotorogo priostanovleny mozhet zaprosit' peresmotr svoego
   voprosa cherez 30 dnej i kazhdye posleduyuschie 30 dnej (esli obschij
   period priostanovki prevyshaet 30 dnej). Kommitter, polnost'yu lishennyj
   prav, mozhet zaprosit' peresmotr po istechenii 6 mesyacev. Pravila
   peresmotra yavlyayutsya polnost'yu neformal'nymi i vo vseh sluchayah
   Pravlenie imeet pravo otvergnut' zapros na peresmotr, esli schitaet svoe
   pervonachal'noe reshenie vernym.

   Vo vseh prochih aspektah deyatel'nosti proekta, Pravlenie yavlyaetsya
   podmnozhestvom kommitterov i ogranicheno temi zhe pravilami. Samo po sebe
   chlenstvo v Pravlenii ne daet prava prestupat' opisannye pravila.
   Pravlenie obladaet <<osoboj siloj>> tol'ko v sluchae deyatel'nost' kak
   celoe, a ne na individual'noj osnove. CHleny Pravleniya - v pervuyu
   ochered' kommittery.

  10.1. Podrobnosti

    1. Uvazhajte drugih kommitterov.

       Vy dolzhny otnosit'sya k drugim kommitteram kak k kollegam po
       razrabotke (kem oni i yavlyayutsya). Nesmotrya na voznikayuschie
       vremenami popytki utverzhdat' obratnoe, nikto ne stal kommitterom po
       svoej ili ch'ej-libo esche gluposti, i malo chto obizhaet sil'nee,
       chem podobnye obvineniya ot kolleg. Vne zavisimosti ot togo, vsegda li
       my chuvstvuem uvazhenie drug k drugu ili net (u kazhdogo byvayut ne
       luchshie dni), my vsegda dolzhny vykazyvat' uvazhenie k drugim
       kommitteram, kak v publichnyh forumah, tak i v lichnoj pochte.

       Sposobnost' sovmestnoj raboty v techenie dlitel'nogo vremeni - odno iz
       glavnyh dostizhenij proekta, mnogo bolee vazhnoe, chem lyuboj nabor
       izmenenij v kode, i nikakie argumenty otnositel'no koda ne stoyat
       poter' v vozmozhnosti garmonichno rabotat' vmeste.

       CHtoby ne protivorechit' `etomu pravilu, nikogda ne posylajte pisem,
       kogda vy zly ili kakim-libo inym obrazom mozhete sprovocirovat' drugih
       na konfrontaciyu. Snachala uspokojtes', zatem podumajte o tom, kak
       naibolee `effektivno ubedit' opponenta(ov) v pravil'nosti vashih
       argumentov; ne podlivajte masla v ogon' radi kratkogo miga zloradstva,
       esli cenoj budet dolgaya rugan'. `Eto ne prosto krajne
       <<`energeticheski ne`effektivno>>: povtoryayuschiesya precedenty
       publichnoj agressii, vliyayuschie na nashu sposobnost' rabotat'
       vmeste, budut vser'ez rassmotreny liderami proekta, i mogut privesti k
       priostanovke ili potere prav kommittera. Vo vnimanie budut
       prinimat'sya kak publichnye vyskazyvaniya, tak i lichnaya perepiska;
       `eto ne oznachaet, chto Pravlenie budet trebovat' raskrytiya tajny
       perepiski, odnako, vse predostavlennye zatronutymi kommitterami
       materialy budut rassmotreny.

       Opisannye procedury nikogo ne mogut poradovat' dazhe v malom, odnako
       <<celostnost' proekta prevyshe vsego>>. Nikakoj ob"em koda ne stoit
       poteri celostnosti.

    2. Uvazhajte drugih uchastnikov proekta.

       Vy ne vsegda byli kommitterom. V svoe vremya vy byli prostym storonnim
       uchastnikom (contributor). Pomnite ob `etom vse vremya. Pomnite, skol'
       vazhno bylo dobit'sya vnimaniya i pomoschi. Ne zabyvajte, naskol'ko
       vashe uchastie bylo vazhnym dlya vas. Pomnite svoi oschuscheniya. Ne
       prepyatstvujte drugim uchastnikam i ne unizhajte ih. Otnosites' k nim
       s uvazheniem. Vozmozhno, oni nashi buduschie kommittery, i oni
       nastol'ko zhe vazhny dlya proekta, kak i kommittery. Ih vklad v proekt
       nastol'ko zhe cenen i vazhen, kak i vash. V konce koncov, vam
       prishlos' prilozhit' nemalo usilij dlya proekta, chtoby stat'
       kommitterom. Vsegda pomnite ob `etom.

       Obdumajte pervoe pravilo 1 i primenyajte ego i k drugim uchastnikam
       proekta.

    3. Obsudite lyubye znachimye izmeneniya do kommita.

       Repozitorij CVS - ne mesto dlya anonsa izmenenij ili obsuzhdeniya ih.
       Vse izmeneniya dolzhny obsuzhdat'sya v spiskah rassylki, i lish' posle
       dostizheniya konsensusa vnositsya v repozitorij. `Eto ne oznachaet,
       chto vy dolzhny sprashivat' razresheniya na ispravlenie ochevidnoj
       sintaksicheskoj oshibki v kode ili opechatki v stranice spravochnika.
       Vy dolzhny oschutit', kogda predpolagaemoe izmenenie trebuet
       predvaritel'nogo obsuzhdeniya i obratnoj svyazi. Kak pravilo, nikto ne
       stanet vozrazhat' protiv obshirnyh izmenenij, esli rezul'tat ochevidno
       luchshe predyduschego sostoyaniya, odnako nikto ne lyubit, kogda `eti
       izmeneniya neozhidanny. Luchshij sposob ubedit'sya, chto vy na
       pravil'nom puti - dat' vash kod prosmotret' komu-libo esche iz
       kommitterov.

       Esli vy somnevaetes', prosite otzyva!

    4. Uvazhajte suschestvuyuschih mejntejnerov.

       Mnogie chasti koda FreeBSD ne yavlyayutsya ch'ej-libo
       <<sobstvennost'yu>>: situaciya, kogda nekto podprygnet i zavopit, esli
       vy vnesete izmeneniya v <<ego>> kod, redka; odnako, vsegda stoit
       predvaritel'no proverit'. Odnim iz ispol'zuemyh soglashenij bylo
       dobavlenie stroki MAINTAINER v fajl Makefile paketa ili chasti dereva,
       kotoraya aktivno podderzhivaetsya odnim ili neskol'kimi kommitterami;
       sm. takzhe sootvetstvuyuschij razdel
       http://www.FreeBSD.org/doc/ru_RU.KOI8-R/books/developers-handbook/policies.html.
       V sluchae, esli kakoj-to uchastok sistemy imeet neskol'ko
       mejntejnerov, izmenenie ego odnim iz nih dolzhno byt' odobreno po
       krajnej mere odnim iz drugih. V sluchayah, kogda <<prinadlezhnost'>>
       koda neyasna, vy mozhete vzglyanut' na istoriyu kommitov, chtoby
       ponyat', kto naibolee aktivno libo v poslednee vremya rabotal v `etoj
       oblasti.

       Otdel'nye oblasti FreeBSD popadayut pod kontrol' kommitterov,
       zanimayuschihsya podderzhkoj celyh kategorij na puti `evolyucii
       FreeBSD, takih kak lokalizaciya ili setevaya podsistema. Dlya
       dopolnitel'noj informacii smotrite
       http://www.FreeBSD.org/doc/en_US.ISO8859-1/articles/contributors/staff-who.html

    5. Lyuboe spornoe izmenenie neobhodimo otkatit' v ozhidanii resheniya,
       esli togo trebuet mejntejner. Voprosy bezopasnosti mogut perekryvat'
       mnenie mejntejnera, esli tak reshit Security Officer.

       `Eto mozhet byt' nelegko, osobenno v period konflikta (kogda kazhdyj
       uchastnik uveren, chto prav imenno on). K schast'yu, CVS daet
       vozmozhnost', vmesto togo chtoby vesti bushuyuschuyu perebranku,
       prosto otkatit' vnesennye izmeneniya, uspokoit'sya vsem uchastnikam
       konflikta, a zatem poprobovat' najti vzaimopriemlemyj put'. Esli v
       konce koncov okazhetsya, chto izmenenie stoit togo, ono mozhet byt'
       legko primeneno vnov'. V protivnom sluchae, pol'zovatelyam ne
       pridetsya zhit' s nepravil'nym sostoyaniem dereva ishodnyh tekstov,
       poka storony zanyaty vyyasneniem otnoshenij. Zaprosy na otkaty
       voznikayut krajne redko, poskol'ku obsuzhdenie obychno vyyavlyaet
       nevernye ili spornye momenty do kommita; odnako, esli takoj zapros vse
       zhe voznik, on dolzhen byt' bezuslovno udovletvoren, chtoby my mogli
       spokojno vyyasnit', bylo izmenenie nevernym ili net.

    6. Izmeneniya vnosyatsya v vetv' FreeBSD-CURRENT do FreeBSD-STABLE, za
       isklyucheniem sluchaev, pryamo razreshennyh vypuskayuschimi
       inzhenerami ili neprimenimosti izmeneniya k FreeBSD-CURRENT. Lyuboe
       netrivial'noe i ne srochnoe izmenenie dolzhno byt' vyderzhano v
       FreeBSD-CURRENT v techenie po krajnej mere 3 dnej pered perenosom,
       chtoby ego mogli adekvatno protestirovat'. Vypuskayuschie inzhenery
       obladayut toj zhe vlast'yu v vetvi FreeBSD-STABLE, chto i mejntejnery
       (sm. pravilo 5).

       `Eto esche odno <<ne obsuzhdaemoe>> pravilo: vypuskayuschij inzhener
       bezuslovno otvechaet za posledstviya, esli vyyasnyaetsya chto
       vnesennye izmeneniya neverny. Uvazhajte `eti prava, i pomogajte gruppe
       vypuska relizov v rabote s vetv'yu FreeBSD-STABLE. Na pervyj vzglyad
       mozhet pokazat'sya, chto vetv' FreeBSD-STABLE razvivaetsya chereschur
       konservativno. Ne zabyvajte, odnako, chto razumnyj konservatizm -
       otlichitel'noe svojstvo FreeBSD-STABLE, i chto `eta vetv' razvivaetsya
       po zakonam, otlichnym ot zakonov FreeBSD-CURRENT. Krome togo, net
       smysla testirovat' izmeneniya v FreeBSD-CURRENT, esli oni nemedlenno
       perenosyatsya v FreeBSD-STABLE. Razrabotchiki FreeBSD-CURRENT dolzhny
       imet' vozmozhnost' protestirovat' vnesennye izmeneniya, tak chto
       ostav'te vremya dlya takogo testirovaniya, esli tol'ko rech' ne idet o
       kriticheskom ispravlenii ili o chem-libo ochevidno ne trebuyuschem
       testirovaniya (naprimer, ispravleniya opechatok v stranicah
       spravochnika, ochevidnyh oshibok ili opechatok v ishodnyh tekstah i
       t.p.) Inymi slovami, ishodite iz soobrazhenij zdravogo smysla.

       Izmeneniya v vetvi podderzhki bezopasnosti (security branches,
       naprimer, RELENG_6_0) dolzhny byt' odobreny chlenom gruppy Gruppa
       Oficerov Bezopasnosti <security-officer@FreeBSD.org> ili, v nekotoryh
       sluchayah, odnim iz vypuskayuschih inzhenerov (Gruppa Vypuska Relizov
       FreeBSD <re@FreeBSD.org>).

    7. Ne prerekajtes' s drugimi kommitterami publichno: `eto durno
       vyglyadit. Esli vam neobhodimo s chem-libo <<kategoricheski ne
       soglasit'sya>>, delajte `eto lichnoj pochtoj.

       Dlya vseh uchastnikov proekta ochen' vazhno podderzhanie ego
       publichnogo obraza; osobenno `eto vazhno, esli my hotim prodolzhat'
       privlekat' novyh uchastnikov. Sluchaetsya, chto, nesmotrya na vse
       usiliya po sohraneniyu vlasti nad soboj, lyudi sryvayutsya i grubyat
       drug drugu. Luchshee, chto zdes' mozhno sdelat' - minimizirovat'
       `effekt, poka vse uchastniki ne uspokoyatsya. Sledovatel'no, vy ne
       dolzhny ozvuchivat' svoyu yarost' publichno, a ravno i peresylat'
       chastnuyu perepisku v obschedostupnye spiski rassylki. Vyrazheniya,
       upotreblyayuschiesya v perepiske odin na odin zachastuyu gorazdo menee
       sderzhanny, chem te, kotorye kazhdyj uchastnik upotrebil by publichno,
       tak chto podobnoj perepiske net mesta v publichnyh rassylkah: `eto
       lish' usugubit i bez togo nepriyatnuyu situaciyu. Esli kto-libo,
       govoryaschij vam nelicepriyatnye slova, delaet `eto v chastnoj
       perepiske, soblyudajte prilichiya i vy: otvechajte privatno. Esli, po
       vashemu mneniyu, kto-libo iz razrabotchikov postupaet s vami
       nechestno, i `eto nastol'ko muchit vas, obratites' k Pravleniyu, a ne
       vynosite konflikt naruzhu. Pravlenie prilozhit vse sily k razresheniyu
       situacii, vystupaya v roli tretejskogo sud'i. V sluchayah, kogda spor
       zatragivaet kakie-libo chasti koda, i uchastniki ne mogut prijti k
       vzaimno priemlemomu soglasheniyu, Pravlenie mozhet privlech'
       nezavisimogo uchastnika dlya razresheniya voprosa. V `etom sluchae vse
       uchastniki konflikta dolzhny soglasit'sya prinyat' reshenie,
       vynesennoe tret'ej storonoj.

    8. Soblyudajte vse periody zamorozki koda (core freeze), a takzhe
       svoevremenno chitajte spiski rassylki committers i developers, chtoby
       byt' v kurse raspisaniya takih periodov.

       Vnesenie ne odobrennyh izmenenij v period zamorozki koda yavlyaetsya
       dovol'no bol'shoj oshibkoj. Kommittery dolzhny byt' v kurse sobytij,
       prezhde chem vnesti 10 megabajt izmenenij posle dolgogo otsutstviya.
       Narushayuschie `eto pravilo budut podvergat'sya zamorozke
       kommitterskogo bita do prohozhdeniya kursa v Schastlivom Lagere
       Povysheniya Kvalifikacii FreeBSD, kotoryj organizovan v Grenlandii.

    9. Esli vy somnevaetes' v kakoj-libo procedure, snachala sprosite!

       Mnozhestvo oshibok sovershaetsya, kogda kto-libo sovershaet pospeshnye
       dejstviya, dumaya, chto postupaet pravil'no. Delaya chto-libo vpervye,
       vy, skoree vsego, ne znaete prinyatyh melochej i tonkostej, i luchshe
       vsego budet snachala sprosit', ne to vy imeete shansy vystavit' sebya
       ne v luchshem svete. Ne stoit stydit'sya sprosit' <<Kak, chert voz'mi,
       `eto nado delat'?>> My i tak znaem, chto vy umny: inache vy ne stali
       by kommitterom.

   10. Testirujte svoi izmeneniya pered kommitom.

       `Eto pravilo mozhet pokazat'sya ochevidnym. Vprochem, esli by ono
       dejstvitel'no bylo ochevidno dlya vseh, my ne tak chasto stalkivalis'
       so sluchayami yavnogo ego narusheniya. Esli vashi izmeneniya
       zatragivayut yadro, ubedites', chto posle nego normal'no sobirayutsya
       yadra GENERIC i LINT. Esli vy izmenyaete druguyu chast' ishodnogo
       koda, ubedites', chto kod sobiraetsya (uspeshno zavershaetsya make
       buildworld). Esli vy izmenyaete kod v kakoj-libo vetvi, ubedites',
       chto vy testiruete ego na mashine, kotoraya rabotaet imenno na `etoj
       vetvi koda. Esli vashi izmeneniya mogut zatronut' drugie arhitektury,
       prover'te ego na vseh podderzhivaemyh arhitekturah. Spisok dostupnyh
       resursov mozhno najti na stranice ../../../../internal/. Po mere
       rasshireniya spiska podderzhivaemyh platform v klaster budut
       dobavlyat'sya sootvetstvuyuschie mashiny dlya testirovaniya.

   11. Ne proizvodite kommit v derev'ya src/contrib, src/crypto i
       src/sys/contrib bez pryamogo razresheniya (approval)
       sootvetstvuyuschego mejntejnera(ov).

       Opisannye derev'ya soderzhat ishodnyj kod storonnih proizvoditelej,
       kotoryj, kak pravilo, importiruetsya v sootvetstvuyuschie vetvi.
       Lyuboj kommit, dazhe ne vyvodyaschij fajl iz vetvi proizvoditelya,
       mozhet stat' golovnoj bol'yu dlya otvetstvennyh za `etu chast' proekta
       razrabotchikov. Tak chto, esli u vas net pryamogo razresheniya ot
       mejntejnera, nichego ne delajte s `etoj chast'yu repozitoriya (esli,
       konechno, vy ne podderzhivaete `etot kod sami).

       Otmetim, chto tol'ko chto skazannoe vovse ne oznachaet, chto vy ne
       dolzhny pytat'sya uluchshit' upomyanutyj kod, naoborot, `etomu budut
       tol'ko rady. Luchshe vsego, esli vy peredadite vashi ispravleniya
       vendoru. Esli izmeneniya specifichny dlya FreeBSD, obsudite vopros s
       mejntejnerom, vozmozhno, on poschitaet razumnym primenit' ih lokal'no.
       Tem ne menee, chto by vy ni delali, ne proizvodite kommit sami!

       Esli vy hotite stat' otvetstvennym za <<nichej>> uchastok dereva
       ishodnikov, svyazhites' s FreeBSD Core.

  10.2. Pravila raboty s razlichnymi arhitekturami

   Nachinaya s versii 5.0 proekt FreeBSD nachal podderzhivat' neskol'ko novyh
   vychislitel'nyh arhitektur, i bolee ne yavlyaetsya <<i386TM-centrichnym>>.
   Dlya uproscheniya podderzhki FreeBSD na baze vseh `etih platform
   Pravleniem bylo sformulirovano sleduyuschee zayavlenie:

     Osnovnoj 32-bitnoj platformoj razrabotki yavlyaetsya i386; osnovnaya
     64-bitnaya platforma - Sparc64. Krupnye izmeneniya v dizajne (v tom
     chisle osnovnye izmeneniya v API i ABI) do popadaniya v repozitorij
     dolzhny byt' otlazheny po krajnej mere na odnoj 32 i odnoj 64-bitnoj
     platforme, zhelatel'no na osnovnyh podderzhivaemyh platformah.

   Platformy i386 i Sparc64 byli vybrany po prichine shirokoj
   rasprostranennosti dostupnosti dlya razrabotchikov; krome togo, oni
   predstavlyayut principial'no raznye podhody k dizajnu processora i sistemy
   v celom: poryadok bajt v slove, organizaciya registrov, realizaciya DMA,
   k`esha, stranichnoj adresacii i t.d.

   Processor Alpha, konechno, yavlyaetsya 64-bitnym, odnako on predstavlyaet
   bolee tradicionnyj dizajn i potomu ne mozhet sluzhit' dostatochno horoshej
   testovoj platformoj dlya otrabotki tonkostej, s kotorymi razrabotchik
   mozhet stolknut'sya na drugih 64-bitnyh platformah. Platforma ia64 vo
   mnogom slozhna tak zhe, kak i Sparc64, odnako ee dostupnost' dlya
   razrabotchikov poka ostavlyaet zhelat' luchshego.

   My budem pereformulirovat' `eti pravila po mere togo, kak budut menyat'sya
   ceny i dostupnost' 64-bitnyh platform.

   Krome togo, razrabotchiki dolzhny byt' v kurse nashih pravil klassov
   podderzhki (Tier Policy) razlichnyh apparatnyh arhitektur. `Eti pravila
   prednaznacheny dlya obschego opisanie processa razrabotki, i potomu
   otlichayutsya ot vysheopisannyh trebovanij k vozmozhnostyam i
   arhitekturam. Pravila klassov podderzhki na period vypuska relizov mnogo
   zhestche, chem ogranicheniya na izmeneniya v processe razrabotki.

  10.3. Drugie rekomendacii

   Pered kommitom v oblasti dokumentacii ispol'zujte kakie-libo sredstva
   proverki orfografii. Dlya dokumentov SGML, krome togo, pri pomoschi
   komandy make lint sleduet proverit' korrektnost' formatirovaniya.

   Dlya stranic spravochnika, pri pomoschi utility iz kollekcii portov manck
   proveryajte korrektnost' perekrestnyh ssylok i ssylok na fajly, a takzhe
   nalichie vseh neobhodimyh ssylok na sinonimy (peremennaya MLINK).

   Ne smeshivajte funkcional'nye izmeneniya so stilisticheskimi (ne
   izmenyayuschimi funkcional'nyh svojstv koda). Takoe smeshivanie
   zatrudnyaet vychlenenie izmenenij pri ispol'zovanii komandy cvs diff i,
   takim obrazom, mozhet skryt' poyavivshiesya oshibki. Ne smeshivajte v
   kommite v derev'ya doc/ i www/ izmeneniya teksta i pereformatirovanie:
   `eto zatrudnyaet rabotu perevodchikov. Proizvodite vse stilisticheskie
   izmeneniya ili pereformatirovaniya otdel'nymi kommitami, i chetko
   oboznachajte ih kak takovye v zhurnal'nyh soobscheniyah k kommitu.

  10.4. Udalenie vozmozhnostej

   Pri neobhodimosti udaleniya kakoj-libo funkcional'noj vozmozhnosti iz
   utilit bazovoj sistemy sleduet ispol'zovat' sleduyuschuyu shemu dejstvij:

    1. V stranice spravochnika i, vozmozhno, v kommentariyah k relizu opciya,
       utilita ili interfejs ob"yavlyayutsya ustarevayuschimi i ne
       rekomendovannymi k ispol'zovaniyu (deprecated); ih ispol'zovanie
       vyvodit preduprezhdenie.

    2. Opciya, utilita ili interfejs sohranyayutsya do ocherednogo osnovnogo
       reliza (reliz X.0).

    3. Opciya, utilita ili interfejs udalyayutsya, v tom chisle iz
       dokumentacii: teper' oni yavlyayutsya ustarevshimi. Kak pravilo, ob
       `etom stoit upomyanut' v kommentariyah k relizu.

11. Podderzhka razlichnyh arhitektur

   FreeBSD yavlyaetsya horosho portiruemoj operacionnoj sistemoj i
   prednaznachena dlya raboty na samyh raznoobraznyh apparatnyh arhitekturah.
   Vazhnoj chast'yu processa obespecheniya gibkosti v podderzhke sovremennyh
   tendencij razvitiya oborudovaniya yavlyaetsya delenie koda na
   mashinno-zavisimyj (Machine Dependent, MD) i mashinno-nezavisimyj (Machine
   Independent, MI), a takzhe, po vozmozhnosti, minimizaciya
   mashinno-zavisimoj chasti koda. Kazhdaya novaya apparatnaya arhitektura,
   kotoruyu nachinaet podderzhivat' FreeBSD, oschutimo uvelichivaet rabotu po
   podderzhke koda, instrumentariya i processa vypuska relizov. Krome togo,
   stanovitsya znachitel'no slozhnee `effektivno testirovat' izmeneniya v
   kode yadra. Vse `eto delaet neobhodimym vvedenie razlichnyh klassov
   podderzhki dlya razlichnyh arhitektur, pri sohranenii maksimal'noj
   stabil'nosti malogo chisla "osnovnyh platform".

  11.1. Osnovnye namereniya

   Proekt FreeBSD prednaznachen dlya raboty na rabochih stanciyah, serverah i
   vysokoproizvoditel'nyh vstroennyh sistemah. Sohranyaya orientir na maloe
   kolichestvo arhitektur v interesah takih sistem, proekt FreeBSD ostaetsya
   sposoben podderzhivat' vysokij uroven' nadezhnosti, stabil'nosti i
   proizvoditel'nosti, a takzhe umen'shit' nagruzku na razlichnye gruppy
   podderzhki proekta, takie kak gruppy podderzhki portov, dokumentacii,
   bezopasnosti i vypuska relizov. Raznoobrazie podderzhivaemyh apparatnyh
   platform rasshiryaet oblast' primenimosti FreeBSD za schet podderzhki
   novyh vozmozhnostej (naprimer, podderzhka 64-bitnyh processorov,
   ispol'zovanie vo vstroennyh sistemah i t.p.); tem ne menee, rasshirenie
   `etogo spiska vsegda dolzhno byt' tschatel'no oceneno s pozicij
   uvelicheniya zatrat na podderzhku dopolnitel'noj apparatnoj platformy.

   Proekt FreeBSD delit razlichnye apparatnye platformy na 4 klassa. Dlya
   kazhdogo klassa opisyvaetsya nabor trebovanij, neobhodimyh dlya
   prisvoeniya platforme dannogo klassa, i obyazatel'stva razrabotchikov po
   otnosheniyu k platforme. Krome togo, opredelyaetsya poryadok smeny klassa
   dlya arhitektury.

  11.2. Klass 1: Polnost'yu podderzhivaemye arhitektury

   Platformy 1 klassa polnost'yu podderzhivayutsya gruppoj bezopasnosti,
   gruppoj vypuska relizov i mejntejnerami instrumentariya. Novye
   vozmozhnosti, dobavlyaemye v kod sistemy, dolzhny byt' polnost'yu
   funkcional'ny dlya vseh arhitektur pervogo klassa dlya kazhdogo iz relizov
   (isklyucheniem mogut byt' arhitekturno-zavisimye vozmozhnosti, takie kak
   drajvera apparatury). Kak pravilo, vse platformy 1 klassa dolzhny
   podderzhivat'sya sistemami sborki libo raspolozhennymi neposredstvenno v
   klastere FreeBSD.org, libo legko dostupnymi dlya vseh razrabotchikov.

   Arhitektury pervogo klassa dolzhny byt' gotovymi k `ekspluatacii pod
   upravleniem FreeBSD vo vseh aspektah, vklyuchaya process ustanovki i sredu
   razrabotki.

   V nastoyaschee vremya platformami 1 klassa yavlyayutsya i386, Sparc64,
   AMD64, and PC98.

  11.3. Klass 2: Arhitektury dlya razrabotchikov

   Platformy 2 klassa ne podderzhivayutsya gruppami bezopasnosti i vypuska
   relizov. Podderzhka instrumentariya ostavlyaetsya na usmotrenie ego
   mejntejnerov. Novye vozmozhnosti, realizuemye v FreeBSD, dolzhny byt'
   realizuemy na `etih platformah, odnako neposredstvennaya realizaciya na
   moment dobavleniya koda v derevo ishodnyh tekstov ne trebuetsya.
   Realizaciya porta na arhitekturu 2 klassa mozhet byt' dobavlena v
   repozitorij, esli ona ne vhodit v protivorechie s tekuschim sostoyaniem
   sistem pervogo klassa i ne vliyaet v suschestvennoj stepeni na prochie
   platformy 2 klassa. Dlya dobavleniya arhitektury 2 klassa v derevo
   ishodnyh tekstov FreeBSD sistema dolzhna byt' sposobna zagruzit'sya hotya
   by v odnopol'zovatel'skij rezhim na real'noj apparature. Nekotorye
   isklyucheniya iz poslednego pravila mogut byt' sdelany dlya novoj
   apparatury, nahodyaschejsya v sostoyanii razrabotki i vremenno ne
   dostupnoj dlya proekta.

   Obychno arhitekturami 2 klassa yavlyayutsya te, kotorye planiruyutsya k
   perehodu v 1 klass, no poka nahodyatsya v sostoyanii razrabotki. Takzhe vo
   vtorom klasse mogut nahoditsya platformy, pereshedshie iz 1 klassa po
   prichine poteri aktual'nosti, po mere togo kak umen'shaetsya kolichestvo
   resursov, dostupnyh dlya podderzhki sistemy v sostoyanii gotovnosti k
   promyshlennoj `ekspluatacii.

   V nastoyaschee vremya platformami 2 klassa yavlyayutsya PowerPC i ia64.

  11.4. Klass 3: `Eksperimental'nye arhitektury

   Platformy 3 klassa ne podderzhivayutsya gruppami bezopasnosti i vypuska
   relizov. Podderzhka instrumentariya ostavlyaetsya na usmotrenie ego
   mejntejnerov. Arhitekturami tret'ego klassa mogut byt': te, dlya kotoryh
   net i v blizhajshee vremya ne predviditsya dostupnogo proektu
   oborudovaniya; imeyuschie menee treh aktivnyh razrabotchikov; ne sposobnye
   zagruzit'sya v odnopol'zovatel'skij rezhim na real'noj apparature (ili pod
   upravleniem `emulyatora, esli real'naya apparatura nedostupna); nakonec,
   sistemy, kotorye ocenivayutsya kak ischezayuschie, ch'ya dal'nejshaya
   rasprostranennost' somnitel'na. Podderzhka sistem 3 klassa ne vnositsya v
   osnovnoe derevo ishodnyh tekstov FreeBSD, odnako rabota nad takimi
   arhitekturami mozhet proizvodit'sya v repozitorii Perforce FreeBSD, dlya
   oblegcheniya kontrolya versij i dal'nejshej integracii s osnovnoj massoj
   koda.

   V nastoyaschee vremya edinstvennoj platformoj 3 klassa yavlyaetsya
   S/390(R).

  11.5. Klass 4: ne podderzhivaemye arhitektury

   Sistemy 4 klassa nikak ne podderzhivayutsya proektom.

   K 4 klassu otnosyatsya vse arhitektury, ne perechislennye vyshe.

  11.6. Pravila smeny klassa dlya arhitektury

   Dlya perenosa platformy iz klassa v klass trebuetsya reshenie,
   utverzhdennoe Pravleniem, kotoroe, v svoyu ochered', soglasuet ego s
   gruppami bezopasnosti, vypuska relizov i podderzhki instrumentariya.

12. FAQ po rabote s portami

   12.1. Dobavlenie novogo porta

                12.1.1. Kak dobavit' novyj port?

                12.1.2. CHto esche sleduet sdelat', dobavlyaya novyj port?

   12.2. Udalenie porta

                12.2.1. Kak udalit' suschestvuyuschij port?

   12.3. Repozitornoe kopirovanie

                12.3.1. Kogda trebuetsya repozitornoe kopirovanie?

                12.3.2. Kogda repozitornoe kopirovanie ne trebuetsya?

                12.3.3. CHto nuzhno delat'?

   12.4. Zamorozka portov

                12.4.1. CHto takoe <<zamorozka portov>>?

                12.4.2. Skol'ko dlitsya zamorozka?

                12.4.3. CHto `eto znachit dlya menya?

                12.4.4. Otkuda ya uznayu o nachale perioda zamorozki?

                12.4.5. Kak uznat', kogda period zamorozki portov
                zakonchilsya?

   12.5. Sozdanie novoj kategorii

                12.5.1. Kakova procedura sozdaniya novoj kategorii portov?

                12.5.2. Kak ustroen process?

   12.6. Prochie voprosy

                12.6.1. Kak mne proverit', chto moj port korrektno
                sobiraetsya?

                12.6.2. YA dobavil novyj port. Nuzhno li dobavlyat' ego v
                fajl INDEX?

                12.6.3. Kakie esche fajly ya ne dolzhen trogat'?

                12.6.4. Kakov korrektnyj poryadok obnovleniya porta, kogda
                ego ishodnyj arhiv pomenyalsya, no ne smenil imya?

    12.1. Dobavlenie novogo porta
12.1.1. Kak dobavit' novyj port?
        
12.1.2. CHto esche sleduet sdelat', dobavlyaya novyj port?
12.1.1. Kak dobavit' novyj port?                                                                          
        Dlya nachala prochitajte razdel, posvyaschennyj repozitornomu kopirovaniyu.                       
                                                                                                          
        Samym prostym budet ispol'zovat' skript addport na mashine freefall. On dobavit port iz           
        ukazannogo vami kataloge, opredeliv nuzhnuyu kategoriyu iz fajla Makefile, dobavit stroku v fajl  
        CVSROOT/modules i v fajl Makefile dlya nuzhnoj kategorii. Skript byl napisan Michael Haro         
        <mharo@FreeBSD.org> i Will Andrews <will@FreeBSD.org>; voprosy i ispravleniya po povodu addport   
        sleduet otpravlyat' Uillu, kak tekuschemu mejntejneru.                                            
12.1.2. CHto esche sleduet sdelat', dobavlyaya novyj port?                                                
        Prover'te ego. ZHelatel'no ubedit'sya v tom, chto port i sootvetstvuyuschij paket korrektno       
        sobirayutsya. Rekomenduemaya posledovatel'nost' dejstvij takova:                                  
                                                                                                          
        # make install                                                                                    
        # make package                                                                                    
        # make deinstall                                                                                  
        # pkg_add imya sobrannogo paketa                                                                  
        # make deinstall                                                                                  
        # make reinstall                                                                                  
        # make package                                                                                    
                                                                                                          
                                                                                                          
        Bolee podrobnye instrukcii mozhno najti v Rukovodstve FreeBSD po sozdaniyu portov.                
                                                                                                          
        Pol'zujtes' portlint(1) dlya proverki korrektnosti porta. Ne obyazatel'no dobivat'sya polnogo     
        otsutstviya preduprezhdenij, no po krajnej mere isprav'te prostejshie iz nih.                     
                                                                                                          
        Esli novyj port prislal chelovek, esche ne upomyanutyj v Spiske prochih uchastnikov, dobav'te ego 
        imya tuda.                                                                                        
                                                                                                          
        Zakrojte PR, esli novyj port prishel v vide PR. Dlya `etogo vospol'zujtes' komandoj edit-pr PR#   
        na mashine freefall i izmenite znachenie v stroke state s open na closed. Zatem opishite prichinu 
        smeny statusa, i na `etom rabota zakonchena.                                                      
    12.2. Udalenie porta
12.2.1. Kak udalit' suschestvuyuschij port?
12.2.1. Kak udalit' suschestvuyuschij port?                                                               
        Dlya nachala prochtite razdel o repozitornom kopirovanii. Prezhde chem udalit' port, vy dolzhny   
        proverit', chto udalenie ne zatronet drugie porty kollekcii.                                      
                                                                                                          
          * Ubedites', chto drugie porty ne zavisyat ot udalyaemogo:                                      
                                                                                                          
               * Imya paketa (PKGNAME) dolzhno vstrechat'sya v svezhem fajle INDEX rovno odin raz.        
                                                                                                          
               * V fajlah Makefile* drugih portov ne dolzhno vstrechat'sya ni odnoj ssylki na katalog     
                 udalyaemogo porta ili imya ego paketa (PKGNAME).                                         
                                                                                                          
          * Udalite port:                                                                                 
                                                                                                          
              1. Udalite fajly porta komandoj cvs remove.                                                 
                                                                                                          
              2. Udalite stroku SUBDIR dlya udalyaemogo porta iz fajla Makefile kategorii.                
                                                                                                          
              3. Udalite zapis' dlya porta iz fajla modulej CVSROOT/modules.                              
                                                                                                          
              4. Dobav'te sootvetstvuyuschuyu stroku v fajl ports/MOVED.                                  
                                                                                                          
              5. Esli port upominaetsya v fajle ports/LEGAL, udalite ego ottuda.                          
                                                                                                          
        Vy mozhete vospol'zovat'sya skriptom rmport iz kataloga ports/Tools/scripts. `Etot skript napisal 
        Vasil Dimov <vd@FreeBSD.org>, i on zhe ego podderzhivaet, tak chto voprosy, ispravleniya i        
        zamechaniya po povodu rmport sleduet posylat' neposredstvenno emu.                                
    12.3. Repozitornoe kopirovanie
12.3.1. Kogda trebuetsya repozitornoe kopirovanie?
        
12.3.2. Kogda repozitornoe kopirovanie ne trebuetsya?
        
12.3.3. CHto nuzhno delat'?
12.3.1. Kogda trebuetsya repozitornoe kopirovanie?                                                        
        Pri neobhodimosti dobavleniya porta, imeyuschego otnoshenie k drugomu, uzhe nahodyaschemusya v    
        repozitorii v drugom kataloge, neobhodimo proizvesti repozitornoe kopirovanie. V dannom sluchae   
        imeyuschij otnoshenie oznachaet druguyu versiyu ili nebol'shuyu modifikaciyu. Primerami mogut     
        sluzhit' razlichnye versii print/ghostscript* i anglijskaya i lokalizovannye versii               
        x11-wm/windowmaker*.                                                                              
                                                                                                          
        Drugim primerom yavlyaetsya neobhodimost' perenesti port iz odnogo podkataloga v drugoj, ili      
        pereimenovat' katalog, kogda avtor menyaet imya svoej programmy.                                  
12.3.2. Kogda repozitornoe kopirovanie ne trebuetsya?                                                     
        Esli net istorii, kotoruyu stoilo by sohranyat'. Dlya porta, dobavlennogo v nepravil'nuyu         
        kategoriyu i srazu zhe peremeschennogo, budet vpolne dostatochno vypolnit' komandy cvs remove     
        dlya starogo varianta i addport dlya novogo.                                                      
12.3.3. CHto nuzhno delat'?                                                                               
        Sozdajte v GNATS PR, opisav prichiny repozitornogo kopirovaniya. Pomenyajte otvetstvennogo na     
        portmgr i ustanovite status (state) v sostoyanie repocopy. Esli vash zapros budet odobren gruppoj 
        Gruppa Menedzherov Dereva Portov FreeBSD <portmgr@FreeBSD.org>, on budet pereadresovan na pcvs.   
        Gruppa Menedzherov Dereva Portov FreeBSD <portmgr@FreeBSD.org> mozhet proizvesti kopirovanie      
        katalogov samostoyatel'no; v protivnom sluchae gruppa Administratory Repozitoriya                 
        Portov<pcvs@FreeBSD.org> proizvedet sobstvenno kopirovanie i vernet vam vash PR. Posle `etogo,    
        vam neobhodimo prodelat' sleduyuschee:                                                            
                                                                                                          
          * Posle repozitornogo kopirovaniya porta:                                                       
                                                                                                          
              1. Obnovite novyj variant porta do novoj versii. Ne zabud'te izmenit' stroku LATEST_LINK,   
                 chtoby ne poluchit' dvuh portov s odnim imenem. V nekotoryh isklyuchitel'nyh sluchayah   
                 mozhet byt' neobhodimo izmenit' peremennuyu PORTNAME vmesto LATEST_LINK, no `eto dolzhno 
                 byt' sdelano tol'ko togda kogda `eto dejstvitel'no nuzhno. Naprimer, pri ispol'zovanii   
                 suschestvuyuschego porta v kachestve osnovy dlya ves'ma pohozhej programmy s drugim      
                 imenem ili pri obnovlenii porta do novoj osnovnoj versii programmy, pri kotorom          
                 izmenyaetsya imya samogo distributiva, kak v sluchae perehoda s textproc/libxml na       
                 textproc/libxml2. V bol'shinstve sluchaev izmenenie LATEST_LINK dolzhno byt'             
                 dostatochno.                                                                             
                                                                                                          
              2. Dobav'te novyj katalog v spisok SUBDIR v roditel'skom fajle Makefile. Dlya proverki vy   
                 mozhete vospol'zovat'sya komandoj make checksubdirs.                                     
                                                                                                          
              3. Esli port menyal kategoriyu, izmenite stroku CATEGORIES v fajle Makefile.                
                                                                                                          
              4. Dobav'te stroku dlya novogo modulya v CVSROOT/modules.                                   
                                                                                                          
              5. Dobav'te stroku v fajl ports/MOVED, v sluchae esli vy udalili pervonachal'nyj port.      
                                                                                                          
          * Pri udalenii porta:                                                                           
                                                                                                          
              1. Tschatel'no prover'te kollekciyu na predmet portov, zavisyaschih ot udalyaemogo i        
                 obnovite ih pri neobhodimosti. Vypolnenie komandy grep po soderzhimomu fajla INDEX       
                 nedostatochno, poskol'ku nekotorye porty mogut byt' skonfigurirovany na `etape sborki.   
                 Rekomenduetsya ispol'zovat' polnyj poisk pri pomoschi komandy grep -r.                   
                                                                                                          
              2. Udalite staryj port, zapis' SUBDIR i stroku, opisyvayuschuyu modul'.                     
                                                                                                          
              3. Dobav'te stroku v fajl ports/MOVED.                                                      
                                                                                                          
          * Posle repozitornogo peremescheniya (operacii <<pereimenovaniya>>, kogda posle kopirovaniya    
            staryj variant udalyaetsya):                                                                  
                                                                                                          
               * Ispol'zujte procedury iz predyduschih dvuh punktov dlya aktivacii novogo porta i         
                 udaleniya starogo.                                                                       
    12.4. Zamorozka portov
12.4.1. CHto takoe <<zamorozka portov>>?
        
12.4.2. Skol'ko dlitsya zamorozka?
        
12.4.3. CHto `eto znachit dlya menya?
        
12.4.4. Otkuda ya uznayu o nachale perioda zamorozki?
        
12.4.5. Kak uznat', kogda period zamorozki portov zakonchilsya?
12.4.1. CHto takoe <<zamorozka portov>>?                                                                  
        Pered vypuskom reliza dlya sohraneniya celostnosti razlichnyh chastej sistemy trebuetsya na       
        nekotoroe vremya ogranichit' kommity v derevo portov. `Etot process i nazyvaetsya <<zamorozkoj    
        portov>>.                                                                                         
                                                                                                          
        Za dopolnitel'noj informaciej po povodu pravil povedeniya vo vremya zamorozki obraschajtes' k     
        dokumentu Zadachi kontrolya kachestva dlya Gruppy upravleniya portami.                            
12.4.2. Skol'ko dlitsya zamorozka?                                                                        
        Obychno nedelyu ili dve.                                                                          
12.4.3. CHto `eto znachit dlya menya?                                                                     
        Vo vremya zamorozki vy ne mozhete proizvodit' kakie-libo kommity v derevo portov bez pryamogo     
        razresheniya gruppy port-menedzherov. <<Pryamoe razreshenie>> zdes' oznachaet, chto vy poslali    
        svoj patch gruppe port-menedzherov i poluchili otvet <<Vpered, proizvodite kommit>>.              
                                                                                                          
        V period zamorozki ne vse izmeneniya mogut byt' vneseny v derevo. Za podrobnostyami obraschajtes' 
        k dokumentu Zadachi kontrolya kachestva dlya Gruppy upravleniya portami.                          
                                                                                                          
        Otmetim, chto u vas net podrazumevaemogo razresheniya ispravlyat' nerabotayuschij port v period   
        zamorozki tol'ko potomu, chto port ne rabotaet.                                                   
12.4.4. Otkuda ya uznayu o nachale perioda zamorozki?                                                     
        Obychno za 2-3 nedeli do nachala perioda zamorozki kto-libo iz gruppy port-menedzherov posylaet   
        pis'mo s preduprezhdeniem ob `etom v Spisok rassylki, posvyaschionnyj Portam FreeBSD i Spisok     
        rassylki kommitterov FreeBSD. Tochnoe vremya nachala perioda zamorozki opredelyaetsya za          
        neskol'ko dnej do sobstvenno reliza, poskol'ku fiksiruemoe derevo portov dolzhno byt'             
        sinhronizirovano s relizom, a tochnaya data vypuska opredelyaetsya po hodu dela.                  
                                                                                                          
        Razumeetsya, posle nachala perioda zamorozki v Spisok rassylki kommitterov FreeBSD budet          
        otpravleno esche odno preduprezhdenie.                                                            
12.4.5. Kak uznat', kogda period zamorozki portov zakonchilsya?                                           
        Zavershenie perioda zamorozki anonsiruetsya gruppoj port-menedzherov posylkoj pis'ma v Spisok     
        rassylki, posvyaschionnyj Portam FreeBSD i Spisok rassylki kommitterov FreeBSD cherez neskol'ko   
        chasov posle reliza. Otmetim, chto fakt vypuska reliza ne oznachaet avtomaticheskogo zaversheniya 
        zamorozki. Nam potrebuetsya ubedit'sya, chto v poslednie minuty ne proizoshlo nichego             
        nepredvidennogo, chto zastavilo by perevypuskat' reliz.                                           
    12.5. Sozdanie novoj kategorii
12.5.1. Kakova procedura sozdaniya novoj kategorii portov?
        
12.5.2. Kak ustroen process?
12.5.1. Kakova procedura sozdaniya novoj kategorii portov?                                                
        Razrabotchik, predlagayuschij novuyu kategoriyu, dolzhen podgotovit' detal'noe obosnovanie ee     
        sozdaniya, v tom chisle opisanie prichin, po kotorym tekuschij spisok kategorij nedostatochen, a  
        takzhe spisok portov, perenosimyh v novuyu kategoriyu.                                            
                                                                                                          
        Prezhde chem otpravlyat' zapros, pomnite, chto process potrebuet prilozheniya nemalyh sil ot      
        mnogih uchastnikov, zatronet vsyakogo, kto podderzhivaet aktual'noe sostoyanie dereva portov      
        celikom, i, nakonec, chto podobnye predlozheniya neizbezhno vyzovut spory i rashozhdeniya vo      
        mneniyah.                                                                                         
                                                                                                          
        Obratites' k razdelu Proposing a New Category Rukovodstva po sozdaniyu portov. Posle peredachi PR 
        gruppe Gruppa Menedzherov Dereva Portov FreeBSD <portmgr@FreeBSD.org> reshenie o sozdanii         
        kategorii ostaetsya za nej. V sluchae utverzhdeniya novoj kategorii kto-libo iz Gruppa            
        Menedzherov Dereva Portov FreeBSD <portmgr@FreeBSD.org> delaet sleduyuschee:                      
                                                                                                          
         1. Proizvodit nuzhnye repozitornye kopirovaniya.                                                 
                                                                                                          
         2. Obnovlyaet opredeleniya VALID_CATEGORIES v fajle ports/Mk/bsd.port.mk.                        
                                                                                                          
         3. Vozvraschaet PR vam.                                                                          
12.5.2. Kak ustroen process?                                                                              
        Procedura yavlyaetsya nadstrojkoj nad uzhe opisannoj proceduroj repozitornogo kopirovaniya        
        otdel'nogo porta.                                                                                 
                                                                                                          
         1. Obnovite fajly Makefile dlya vseh perenesennyh portov. Poka ne dobavlyajte novuyu kategoriyu  
            v process postroeniya indeksa.                                                                
                                                                                                          
            Dlya `etogo vam neobhodimo:                                                                   
                                                                                                          
              1. Smenit' dlya vseh portov znachenie peremennoj CATEGORIES (`eto i bylo nashej cel'yu, ne  
                 pravda li?) Novaya kategoriya dolzhna byt' ukazano v spiske pervoj, `eto pomozhet        
                 proverit', pravil'no li ustanovlena peremennaya PKGORIGIN.                               
                                                                                                          
              2. Vypolnite komandu make describe. Poskol'ku procedura postroeniya glavnogo indeksa make   
                 index, kotoruyu vam predstoit vypolnit' neskol'ko pozzhe, ispol'zuet imenno make         
                 describe, obnaruzhenie oshibok sejchas s`ekonomit vam nemalo vremeni v buduschem.        
                                                                                                          
              3. Esli vy hotite byt' sovsem chestnym, samoe vremya zapustit' portlint(1).                 
                                                                                                          
         2. Prover'te korrektnost' peremennyh PKGORIGIN. Sistema raboty s portami ispol'zuet znachenie    
            peremennoj CATEGORIES dlya ustanovki peremennoj PKGORIGIN, kotoraya zatem ispol'zuetsya dlya  
            svyazi ustanovlennyh paketov s katalogami dereva portov. Esli `eta svyaz' ustanovlena         
            nepravil'no, perestanut pravil'no funkcionirovat' utility raboty s portami, takie kak         
            pkg_version(1) i portupgrade(1).                                                              
                                                                                                          
            Dlya proverki sleduet ispol'zovat' skript chkorigin.sh: env PORTSDIR=/path/to/ports sh -e     
            /path/to/ports/Tools/scripts/chkorigin.sh . `Eta komanda proverit kazhdyj port v dereve, v    
            tom chisle i te, chto ne vklyucheny v process sborki, tak chto ee mozhno ispol'zovat' srazu   
            posle repozitornogo kopirovaniya. Sovet: ne zabud'te proverit' PKGORIGIN dlya zavisimyh ot    
            izmenyaemyh vami portov!                                                                      
                                                                                                          
         3. Protestirujte izmeneniya lokal'no, na vashej mashine: zakommentirujte stroki SUBDIR dlya      
            staryh portov, zatem razreshite obrabotku novoj kategorii v fajle ports/Makefile. Zapustite   
            make checksubdirs v zatragivaemyh kategoriyah. Nakonec, vypolnite v kataloge ports/ komandu   
            make index. Ee vypolnenie mozhet zanyat' do 40 minut dazhe na sovremennoj mashine, odnako,    
            `eto neobhodimye zatraty dlya togo, chtoby ne sozdat' problem dlya drugih.                    
                                                                                                          
         4. Posle zaversheniya `etoj operacii vy mozhete vnosit' v repozitorij izmeneniya ports/Makefile  
            dlya vklyucheniya novoj kategorii v process sborki, a takzhe proizvodit' kommit izmenenij     
            Makefile dlya staryh kategorij.                                                               
                                                                                                          
         5. Dobav'te v fajl CVSROOT-ports/modules stroku                                                  
                                                                                                          
         ports_categoryname   categoryname                                                                
                                                                                                          
            Polya dolzhny byt' razdeleny tabulyaciej.                                                     
                                                                                                          
            Esli categoryname soderzhit defisy, zamenite ih na podcherkivaniya.                           
                                                                                                          
         6. Pomenyajte stroki dlya zatronutyh modulej v fajle CVSROOT-ports/modules.                      
                                                                                                          
         7. Dobav'te nuzhnye stroki v fajl ports/MOVED.                                                   
                                                                                                          
         8. Obnovite instrukcii dlya cvsup(1):                                                            
                                                                                                          
               * Dobav'te kategoriyu v fajl distrib/cvsup/sup/README                                      
                                                                                                          
               * Dobav'te v katalog distrib/cvsup/sup/ports-categoryname dva fajla: list.cvs i releases.  
                                                                                                          
               * Dobav'te kategoriyu v fajl src/share/examples/cvsup/ports-supfile                        
                                                                                                          
            (Obratite vnimanie: `eti fajly raspolozheny v repozitorii src, a ne ports). Esli vy ne        
            yavlyaetes' kommitterom src, vam potrebuetsya sozdat' PR.                                     
                                                                                                          
         9. Obnovite spisok kategorij, ispol'zuemyj v sysinstall(8) v src/usr.sbin/sysinstall.            
                                                                                                          
        10. Obnovite dokumentaciyu:                                                                       
                                                                                                          
               * Rukovodstvo FreeBSD po sozdaniyu portov                                                  
                                                                                                          
               * Fajl www/en/ports/categories. Obratite vnimanie, chto stroki v nih sgruppirovany po      
                 kategoriyam, opisannym v fajle www/en/ports/categories.descriptions.                     
                                                                                                          
               * Razdel Rukovodstva, perechislyayuschij cvsup kollekcii.                                  
                                                                                                          
            (Vnimanie: vse `eti fajly nahodyatsya v repozitorii dokumentacii. Esli vy ne yavlyaetes'      
            kommitterom v `etoj oblasti, sozdajte PR v kategorii dokumentacii (doc).                      
                                                                                                          
        11. Starye varianty portov mogut byt' udaleny iz repozitoriya tol'ko posle togo, kak vse          
            opisannye procedury budut zaversheny, i nikto ne zhaluetsya na novuyu strukturu.              
                                                                                                          
        Special'no obnovlyat' veb-stranicu portov pri dobavlenii novoj kategorii ne nuzhno: izmenenie     
        fajla www/en/ports/categories budet uchteno pri ezhednevnoj perestrojke spiska portov (INDEX)     
        avtomaticheski.                                                                                   
    12.6. Prochie voprosy
12.6.1. Kak mne proverit', chto moj port korrektno sobiraetsya?
        
12.6.2. YA dobavil novyj port. Nuzhno li dobavlyat' ego v fajl INDEX?
        
12.6.3. Kakie esche fajly ya ne dolzhen trogat'?
        
12.6.4. Kakov korrektnyj poryadok obnovleniya porta, kogda ego ishodnyj arhiv pomenyalsya, no ne smenil
imya?   
12.6.1. Kak mne proverit', chto moj port korrektno sobiraetsya?                                           
        V pervuyu ochered' prover'te svoj port po adresu http://pointyhat.FreeBSD.org/errorlogs/. Tam vy  
        najdete zhurnaly sborki paketov na vseh podderzhivaemyh arhitekturah dlya bol'shinstva poslednih  
        vetvej razrabotki.                                                                                
                                                                                                          
        Vprochem, otsutstvie vashego porta sredi zhurnalov s oshibkami esche ne znachit, chto on uspeshno 
        sobiraetsya (naprimer, mozhet ne sobirat'sya odin iz zavisimyh portov). Neobhodimuyu informaciyu  
        vy mozhete najti na mashine pointyhat v katalogah /a/portbuild/<arch>/<major_version>. Kazhdaya   
        para arhitektury i bazovoj versii soderzhit sleduyuschie podkatalogi:                             
                                                                                                          
        errors        zhurnaly oshibok poslednej sborki versii <major_version> na platforme <arch>        
        logs          vse zhurnaly poslednej sborki versii <major_version> na platforme <arch>            
        packages      svezhesobrannye pakety dlya versii <major_version> na platforme <arch>              
        bak/errors    zhurnaly oshibok poslednej polnoj sborki versii <major_version> na platforme <arch> 
        bak/logs      vse zhurnaly poslednej polnoj sborki versii <major_version> na platforme <arch>     
        bak/packages  pakety poslednej polnoj sborki versii <major_version> na platforme <arch>           
                                                                                                          
        Obschee pravilo: paket, prisutstvuyuschij v kataloge packages ili kataloge logs, i pri `etom      
        otsutstvuyuschij v errors, sobralsya uspeshno. (Imenno katalogi errors vy vidite na veb-servere   
        pointyhat).                                                                                       
12.6.2. YA dobavil novyj port. Nuzhno li dobavlyat' ego v fajl INDEX?                                     
        Net. INDEX bol'she ne hranitsya v CVS repozitorii. Dannyj fajl mozhet byt' sgenerirovan s         
        pomosch'yu komandy make index ili uzhe sgenerirovannaya versiya mozhet byt' zagruzhena s          
        pomosch'yu make fetchindex.                                                                       
12.6.3. Kakie esche fajly ya ne dolzhen trogat'?                                                          
        Lyuboj fajl v na verhnem urovne ports/, a takzhe vse fajly v katalogah, imena kotoryh             
        nachinayutsya s propisnoj bukvy (naprimer, Mk/, Tools/ i t.p.). V chastnosti, upasi vas Bog       
        trogat' fajly ports/Mk/bsd.port*.mk, esli vy ne hotite privesti port-menedzherov v yarost'!       
12.6.4. Kakov korrektnyj poryadok obnovleniya porta, kogda ego ishodnyj arhiv pomenyalsya, no ne smenil   
        imya?                                                                                             
        Pri vozniknovenii situacii, kogda avtor obnovlyaet distributivnyj arhiv bez izmeneniya            
        identifikatora versii, soobschenie o kommite dolzhno soderzhat' annotaciyu razlichij mezhdu       
        predyduschim i obnovlennym sostoyaniem arhiva, chtoby mozhno bylo ubedit'sya, chto arhiv ne       
        isporchen i ne podmenen zloumyshlennikom. Esli tekuschaya versiya porta suschestvovala            
        dostatochnoe vremya, kopii arhiva budut dostupny na ftp-serverah proekta; v protivnom sluchae     
        sleduet svyazat'sya s avtorom ili mejntejnerom porta dlya vyyasneniya prichin zameny arhiva.      

13. Pryaniki i prochie l'goty

   Uvy, l'got, voznikayuschih ot togo, chto vy yavlyaetes' kommitterom, ne
   tak uzh mnogo. Pozhaluj, edinstvennym nesomnennym dolgovremennym
   preimuschestvom budet priznanie vas kak kompetentnogo specialista. Tem ne
   menee, koe-kakie l'goty vse zhe suschestvuyut:

   Pryamoj dostup k mashine cvsup-master

           Buduchi kommitterom, vy mozhete obratit'sya k Jun Kuriyama
           <kuriyama@FreeBSD.org>, chtoby poluchit' dostup k mashine
           cvsup-master.FreeBSD.org, prilozhiv vyvod komandy cvpasswd
           yourusername@FreeBSD.org freefall.FreeBSD.org. Obratite vnimanie:
           v komandnoj stroke vy dolzhny ukazat' freefall.FreeBSD.org, hotya
           real'nym serverom budet cvsup-master. Dostupom k cvsup-master ne
           sleduet zloupotreblyat': `eto ves'ma zagruzhennaya mashina.

   Besplatnaya podpiska na komplekt iz 4 CD ili DVD

           Kompaniya FreeBSD Mall, Inc. predostavlyaet dlya vseh kommitterov
           FreeBSD vozmozhnost' besplatnoj podpiski na vypuski FreeBSD.
           Poryadok podpiski poyavlyaetsya v spiske rassylki
           <developers@FreeBSD.org> posle kazhdogo reliza.

14. Prochie voprosy

   14.1. Pochemu ne sleduet vnosit' maloznachimye izmeneniya v vetvi
   razrabotchika (vendor branches)?

   14.2. Kak mne dobavit' fajl v vetv' CVS?

   14.3. Kakuyu <<meta-informaciyu>> ya dolzhen vklyuchat' v soobscheniya
   dlya kommita?

   14.4. Kak mne poluchit' dostup k people.FreeBSD.org dlya togo chtoby
   razmestit' tam personal'nuyu informaciyu ili informaciyu o moih proektah?

   14.5. Gde raspolozheny arhivy spiskov rassylki?

   14.6. Mne by hotelos' stat' mentorom dlya novogo kommittera. Kakogo
   tehnologicheskogo processa ya dolzhen priderzhivat'sya?

   14.1. Pochemu ne sleduet vnosit' maloznachimye izmeneniya v vetvi          
         razrabotchika (vendor branches)?                                     
           * Posle `etogo dejstviya kazhdyj novyj reliz ot razrabotchika      
             trebuet ruchnogo prilozheniya i ob"edineniya patchej.            
                                                                              
           * CHto huzhe, kazhdyj novyj reliz ot razrabotchika trebuet ruchnoj 
             proverki prilozhennyh patchej.                                   
                                                                              
           * Opciya CVS -j ne vsegda horosho rabotaet. Mozhete sprosit' David 
             O'Brien <obrien@FreeBSD.org>, on rasskazhet vam zhutkih istorij. 
   14.2. Kak mne dobavit' fajl v vetv' CVS?                                   
         Dlya dobavleniya fajla v vetvi prosto obnovite ishodnye fajly do     
         nuzhnoj vetvi, a zatem ispol'zujte komandu cvs add. Naprimer, esli   
         my hotite perenesti fajl src/sys/alpha/include/smp.h iz vetvi HEAD v 
         vetv' RELENG_6, v kotoroj on poka ne suschestvuet, mozhno            
         ispol'zovat' sleduyuschuyu posledovatel'nost' dejstvij:              
                                                                              
         Primer 1. MFC dlya novogo fajla                                      
                                                                              
         % cd sys/alpha/include                                               
         % cvs update -rRELENG_6                                              
         cvs update: Updating .                                               
         U clockvar.h                                                         
         U console.h                                                          
         ...                                                                  
         % cvs update -kk -Ap smp.h > smp.h                                   
         ===================================================================  
         Checking out smp.h                                                   
         RCS:  /usr/cvs/src/sys/alpha/include/smp.h,v                         
         VERS: 1.1                                                            
         ***************                                                      
         % cvs add smp.h                                                      
         cvs add: scheduling file `smp.h' for addition on branch `RELENG_6'   
         cvs add: use 'cvs commit' to add this file permanently               
         % cvs commit                                                         
                                                                              
   14.3. Kakuyu <<meta-informaciyu>> ya dolzhen vklyuchat' v soobscheniya     
         dlya kommita?                                                        
         Pomimo informativnogo opisaniya soderzhaniya kommita vam mozhet      
         potrebovat'sya vklyuchit' v soobschenie dopolnitel'nuyu informaciyu. 
                                                                              
         Ona sostoit iz odnoj ili neskol'kih strok vida: klyuchevoe slovo ili 
         slovosochetanie, dvoetochie, tabulyacii dlya formatirovaniya,        
         sobstvenno dopolnitel'naya informaciya.                              
                                                                              
         Klyuchevymi slovami mogut byt':                                      
                                                                              
         PR:            Identifikator soobscheniya ob oshibke, zatragivaemogo 
                        (kak pravilo, zakryvaemogo) dannym kommitom.          
                        Imya i e-mail adres prislavshego ispravlenie; dlya    
         Submitted by:  kommitterov - prosto imya pol'zovatelya v klastere    
                        FreeBSD.                                              
                        Imya i e-mail adres togo ili teh, kto recenziroval    
                        izmeneniya; dlya kommitterov - imya pol'zovatelya v   
         Reviewed by:   klastere FreeBSD. Esli izmeneniya byli poslany v      
                        spisok rassylki na recenziyu i poluchili odobrenie,   
                        imya spiska rassylki.                                 
                        Imya i e-mail adres togo ili teh, kto odobril         
                        izmenenie; kak i prezhde, dlya kommitterov prosto     
                        imya pol'zovatelya v klastere. Obychnoj praktikoj     
                        yavlyaetsya poluchenie odobreniya dlya kommitov v     
         Approved by:   novye dlya vas oblasti dereva. Krome togo, v period   
                        pered kazhdym relizom vse kommity dolzhny byt'        
                        odobreny gruppoj vypuskayuschih inzhenerov. V sluchae 
                        vashih pervyh kommitov vy dolzhny poluchit' odobrenie 
                        na nih u vashego mentora, i upomyanut' ego v vide     
                        <<username-of-mentor (mentor)>>.                      
         Obtained from: Imya proekta, iz ishodnogo koda kotorogo bylo vzyato  
                        izmenenie.                                            
                        Esli vy hotite poluchat' po pochte napominaniya ob    
         MFC after:     MFC, ukazhite chislo dnej, nedel' ili mesyacev s      
                        momenta iznachal'nogo kommita, cherez kotoroe vy      
                        planiruete proizvesti MFC.                            
                        Esli vashi izmeneniya zatragivayut voprosy            
         Security:      bezopasnosti ili ispravlyayut kakie-libo uyazvimosti, 
                        ukazhite ssylki na opublikovannye otchety ili         
                        opisanie problemy.                                    
                                                                              
         Primer 2. Soobschenie dlya kommita, osnovannogo na PR                
                                                                              
         Vy sobiraetes' vnesti kommit, osnovannyj na PR, prislannom John      
         Smith i soderzhaschim patch dlya ispravleniya problemy. Vashe        
         soobschenie dolzhno zakanchivat'sya primerno takimi strokami:        
                                                                              
         ...                                                                  
                                                                              
         PR:                foo/12345                                         
         Submitted by:      John Smith <John.Smith@example.com>               
                                                                              
         Primer 3. Soobschenie dlya kommita, trebuyuschego recenzii           
                                                                              
         Vy sobiraetes' izmenit' podsistemu raboty s virtual'noj pamyat'yu.   
         Vy opublikovali predpolagaemye izmeneniya v sootvetstvuyuschem       
         spiske rassylki (v dannom sluchae freebsd-arch), i izmeneniya byli   
         odobreny.                                                            
                                                                              
         ...                                                                  
                                                                              
         Reviewed by:       -arch                                             
                                                                              
         Primer 4. Soobschenie dlya kommita, trebuyuschego odobreniya         
                                                                              
         Vy namereny proizvesti kommit v oblast' dereva, dlya kotoroj         
         opredelen veduschij (MAINTAINER). Vy skoordinirovali usiliya s       
         mejntejnerom, i on otreagiroval <<Otlichno. Proizvodi kommit.>>      
                                                                              
         ...                                                                  
                                                                              
         Approved by:        abc                                              
                                                                              
         Gde abc imya pol'zovatelya, odobrivshego vash kommit.                
                                                                              
         Primer 5. Soobschenie dlya kommita, ispol'zuyuschego kod OpenBSD     
                                                                              
         Vy sobiraetes' vnesti izmenenie, osnovannoe na kode, ispol'zovannom  
         proektom OpenBSD.                                                    
                                                                              
         ...                                                                  
                                                                              
         Obtained from:      OpenBSD                                          
                                                                              
         Primer 6. Soobschenie dlya kommita, planiruyuschego integraciyu iz   
         FreeBSD-CURRENT v FreeBSD-STABLE cherez nekotoroe vremya             
                                                                              
         Vy hotite vnesti izmeneniya, kotorye dolzhny byt' integrirovany iz   
         FreeBSD-CURRENT v vetv' FreeBSD-STABLE cherez dve nedeli.            
                                                                              
         ...                                                                  
                                                                              
         MFC after:      2 weeks                                              
                                                                              
         Gde 2 yavlyaetsya kolichestvom dnej, nedel' ili mesyacev, cherez     
         kotoroe vy planiruete integrirovat' (MFC) v FreeBSD-STABLE. V        
         kachestve weeks mozhet byt' ispol'zovano week, weeks, month, months, 
         libo `etot parametr mozhet byt' opuschen (pri `etom podrazumevaetsya 
         X dnej).                                                             
                                                                              
         V otdel'nyh sluchayah vam potrebuetsya kombinirovat' privedennye     
         primery.                                                             
                                                                              
         Rassmotrim situaciyu, kogda nekto prislal soobschenie ob oshibke,    
         soderzhaschee kod iz proekta NetBSD. Vy zainteresovalis' `etim       
         sluchaem, no on raspolozhen v toj chasti dereva, v kotoroj vy        
         obychno ne rabotaete, tak chto vy reshaete vydat' izmeneniya na      
         rassmotrenie spiska rassylki arch. Poskol'ku izmeneniya byli         
         dostatochno slozhny, vy reshaete integrirovat' ih (MFC) cherez       
         mesyac, chtoby obespechit' adekvatnoe vremya dlya testirovaniya.     
                                                                              
         V opisannom sluchae soobscheniya dlya kommita mozhet vyglyadet'      
         primerno tak:                                                        
                                                                              
         PR:                 foo/54321                                        
         Submitted by:       John Smith <John.Smith@example.com>              
         Reviewed by:        -arch                                            
         Obtained from:      NetBSD                                           
         MFC after:          1 month                                          
   14.4. Kak mne poluchit' dostup k people.FreeBSD.org dlya togo chtoby       
         razmestit' tam personal'nuyu informaciyu ili informaciyu o moih      
         proektah?                                                            
         people.FreeBSD.org - sinonim dlya freefall.FreeBSD.org. Prosto       
         sozdajte katalog public_html. Vse, chto vy razmestite v nem, budet   
         avtomaticheski dostupno po adresu http://people.FreeBSD.org/.        
   14.5. Gde raspolozheny arhivy spiskov rassylki?                            
         Spiski rassylki arhiviruyutsya v ierarhiyu katalogov /g/mail,        
         vidimuyu na vseh mashinah klastera kak /hub/g/mail (sm. pwd(1)).     
   14.6. Mne by hotelos' stat' mentorom dlya novogo kommittera. Kakogo        
         tehnologicheskogo processa ya dolzhen priderzhivat'sya?              
         Obratites' k dokumentu Procedura sozdaniya novogo akkaunta.          

     ----------------------------------------------------------------------

   [1] Tochnyj put' k fajlu zavisit ot ustanovok *default base v vashem fajle
   supfile.
