                         Spravochnik kommittera

  The FreeBSD Documentation Project

  Dmitrij Morozovskij

   $FreeBSD:
   release/8.4.0/ru_RU.KOI8-R/articles/committers-guide/article.xml
   39632 2012-10-01 11:56:00Z gabor $

   Copyright (c) 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007
   The FreeBSD Documentation Project

   $FreeBSD:
   release/8.4.0/ru_RU.KOI8-R/articles/committers-guide/article.xml
   39632 2012-10-01 11:56:00Z gabor $

   FreeBSD `eto zaregistrirovannaya torgovaya marka FreeBSD
   Foundation.

   CVSup `eto zaregistrirovannaya torgovaya marka John D. Polstra.

   IBM, AIX, EtherJet, Netfinity, 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, SPARCEngine, 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)''.

   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.

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

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 Razd. 
   repozitoriya         3).                                           
   (CVSROOT)            
   Administratory       Peter Wemm <peter@FreeBSD.org> i Mark Murray  
   Glavnogo CVS         <markm@FreeBSD.org>, a takzhe Josef           
   Repozitoriya         Karthauser <joe@FreeBSD.org> i Joe Marcus     
   <cvsadm@FreeBSD.org> 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 Razd. 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.

     Zamechanie: 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.

     Zamechanie: 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.

     Zamechanie: 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 C. Smo/rgrav <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    
       merge                 konflikty, 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 C. Smo/rgrav <des@FreeBSD.org> napisal skript dlya
       uproscheniya `etogo processa. Dopolnitel'nuyu informaciyu
       mozhno prochest' v fajle README.

         Zamechanie: 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.

   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.

     Zamechanie: 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   . 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
   ''i386(TM)-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

   1. Dobavlenie novogo porta

                12.1.1. Kak dobavit' novyj port?

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

   2. Udalenie porta

                12.2.1. Kak udalit' suschestvuyuschij port?

   3. Repozitornoe kopirovanie

                12.3.1. Kogda trebuetsya repozitornoe kopirovanie?

                12.3.2. Kogda repozitornoe kopirovanie ne trebuetsya?

                12.3.3. CHto nuzhno delat'?

   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?

   5. Sozdanie novoj kategorii

                12.5.1. Kakova procedura sozdaniya novoj kategorii
                portov?

                12.5.2. Kak ustroen process?

   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?

    1. Dobavlenie novogo porta

   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.

    2. Udalenie porta

   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.

    3. Repozitornoe kopirovanie

   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):

         1. Ispol'zujte procedury iz predyduschih dvuh punktov dlya
            aktivacii novogo porta i udaleniya starogo.

    4. Zamorozka portov

   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.

    5. Sozdanie novoj kategorii

   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.

    6. Prochie voprosy

   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':

                  Identifikator soobscheniya ob oshibke,              
   PR:            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.

  Primechaniya

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

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

            `Etot, i drugie dokumenty, mogut byt' skachany s
                ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/.

  Po voprosam, svyazannym s FreeBSD, prochitajte dokumentaciyu prezhde
                 chem pisat' v <questions@FreeBSD.org>.
         Po voprosam, svyazannym s `etoj dokumentaciej, pishite
                           <doc@FreeBSD.org>.
  Po voprosam, svyazannym s russkim perevodom dokumentacii, pishite v
                    rassylku <frdp@FreeBSD.org.ua>.
  Informaciya po podpiske na `etu rassylku nahoditsya na sajte proekta
                               perevoda.
