Synchronize with English 1.31

Submitted by:   Vitaly Bogdanov <gad@gad.glazov.net>
Obtained from:  The FreeBSD Russian Documentation Project

ru_RU.KOI8-R/books/developers-handbook/policies/chapter.sgml

@@ -0,0 +1,469 @@
+<!--
+     The FreeBSD Russian Documentation Project
+
+     $FreeBSD$
+     $FreeBSDru: frdp/doc/ru_RU.KOI8-R/books/developers-handbook/policies/chapter.sgml,v 1.6 2005/07/11 12:44:48 gad Exp $
+
+     Original revision: 1.31
+-->
+
+<chapter id="policies">
+  <chapterinfo>
+    <authorgroup>
+      <author>
+       <firstname>Poul-Henning</firstname>
+       <surname>Kamp</surname>
+       <contrib>Материал предоставил: </contrib>
+      </author>
+    </authorgroup>
+    <!-- June 1996 -->
+  </chapterinfo>
+
+  <title>Рекомендации и требования к исходному коду</title>
+
+  <para>В этой главе описываются различные рекомендации и требования, которые
+    должны соблюдаться в дереве исходных текстов FreeBSD.</para>
+
+  <sect1 id="policies-maintainer">
+    <title><makevar>MAINTAINER</makevar> в make-файлах</title>
+    <indexterm><primary>ports maintainer</primary></indexterm>
+
+    <para>Если некоторая часть дистрибутива FreeBSD поддерживается некоторым
+      человеком или группой людей, они могут сообщить об этом миру, добавив
+      строчку
+
+      <programlisting>MAINTAINER= email-addresses</programlisting>
+
+      в файл <filename>Makefile</filename>, соответствующий этой части
+      исходного кода.</para>
+
+    <para>Смысл этого в следующем:</para>
+
+    <para>Сопровождающий владеет кодом и отвечает за него.  Это означает, что
+      он несет ответственность за исправление ошибок и закрывает сообщения о
+      проблемах, имеющих отношение к этой части кода, а в случае программного
+      обеспечения, взятого из третьих источников, соответственно отвечает за
+      отслеживание новых версий.</para>
+
+    <para>Изменения в каталогах, для которых известен сопровождающий, прежде
+      чем они будут внесены, должны быть посланы ему на рассмотрение.  Только
+      если сопровождающий не отвечает в течение достаточно большого периода
+      времени на несколько посланий по электронной почте, разрешается внести
+      изменения без участия сопровождающего.  Однако рекомендуется, чтобы вы
+      попытались передать изменения на рассмотрение кому-либо еще, если это
+      вообще возможно.</para>
+
+    <para>Конечно же, нельзя назначать человека или группу лиц
+      сопровождающими, если они не согласны выполнять эту работу.  С другой
+      стороны, необязательно это должен быть конкретный коммиттер, это может
+      быть и группа людей.</para>
+  </sect1>
+
+  <sect1 id="policies-contributed">
+    <sect1info>
+      <authorgroup>
+       <author>
+         <firstname>Poul-Henning</firstname>
+         <surname>Kamp</surname>
+         <contrib>Материал предоставили: </contrib>
+       </author>
+       <author>
+         <firstname>David</firstname>
+         <surname>O'Brien</surname>
+       </author>
+      </authorgroup>
+      <!-- June 1996 -->
+    </sect1info>
+          
+    <title>Программное обеспечение сторонних производителей</title>
+
+    <indexterm><primary>contributed software</primary></indexterm>
+
+    <para>Некоторые части дистрибутива FreeBSD состоят из программного
+      обеспечения, которое сопровождается вне проекта FreeBSD.	По
+      историческим причинам мы называем такое программное обеспечение
+      <emphasis>контрибуцированным</emphasis> (contributed), или третьих
+      сторон.  Примерами этого могут служить утилиты <application>sendmail</application>, <application>gcc</application> и
+      <application>patch</application>.</para>
+
+    <para>За последние несколько лет для работы с таким программным
+      обеспечением использовались различные методы, и все они имели свои
+      достоинства и недостатки.  Абсолютно подходящего метода так и не
+      нашлось.</para>
+
+    <para>По этой причине после некоторых дебатов был выбран и признан
+      <quote>официальным</quote> один из этих методов, который необходимо
+      применять в будущем при импортировании такого рода программного
+      обеспечения.  Более того, настоятельно рекомендуется с течением времени
+      перевести существующее программное обеспечение третьих сторон на этот
+      метод, так как он имеет значительные преимущества перед старым методом,
+      включая возможность легкого получения diff-файлов относительно
+      <quote>официальных</quote> версий исходных текстов кем угодно (даже
+      не имеющим доступа к cvs).  Это делает данный метод гораздо проще
+      в использовании при необходимости выдачи изменений изначальным
+      разработчикам такого программного обеспечения.</para>
+
+    <para>В конце концов, однако, это касается тех, кто делает реальную
+      работу.  Если использование этой модели в конкретном случае не подходит
+      для пакета, с которым работает человек, могут быть сделаны и
+      исключения только с согласия основной команды разработчиков и при общем
+      одобрении других разработчиков.  Возможность сопровождения пакета в
+      будущем будет являться ключевым моментом при принятии решений.</para>
+
+    <note>
+      <para>Из-за досадных ограничений в дизайне формата файлов RCS и
+	использовании веток поставщика в CVS, мелкие, тривиальные и/или
+	косметические изменения <emphasis>сильно не рекомендуется</emphasis>
+	в файлах, которые все еще отслеживаются в ветке поставщика.  Это
+	касается и <quote>исправления орфографических ошибок</quote> как
+	относящихся к категории <quote>косметических</quote> и избегаемых
+	для файлов с версиями 1.1.x.x.	Рост объема хранилища, вызванный
+	изменением в один символ, может оказаться весьма большим.</para>
+    </note>
+
+    <para>В качестве примера того, как работает эта модель, будем
+      использовать встраиваемый язык программирования
+      <application>TCL</application>:</para>
+
+    <para>Каталог <filename>src/contrib/tcl</filename> содержит исходные
+      тексты пакета в том виде, в котором они распространяются его
+      создателями.  Части, которые полностью не применимы во FreeBSD, могут
+      быть удалены.  В случае Tcl подкаталоги <filename>mac</filename>,
+      <filename>win</filename> и <filename>compat</filename> были удалены
+      перед операцией импортирования</para>
+
+    <para>Каталог <filename>src/lib/libtcl</filename> содержит только файл
+      <filename>Makefile</filename> в стиле <application>bmake</application>, который
+      использует стандартные правила <filename>bsd.lib.mk</filename>
+      make-файла для построения библиотеки и установки документации.</para>
+
+    <para>В каталоге <filename>src/usr.bin/tclsh</filename> размещаются
+      make-файлы в стиле bmake, которые отвечают за построение и установку
+      программы <command>tclsh</command> и связанных с ней справочных
+      страниц при помощи стандартных правил из
+      <filename>bsd.prog.mk</filename>.</para>
+
+    <para>Каталог <filename>src/tools/tools/tcl_bmake</filename> содержит
+      несколько shell-скриптов, которые могут помочь при обновлении
+      программного обеспечения tcl.  Они не являются частью строящегося и
+      инсталлируемого программного обеспечения.</para>
+
+    <para>Здесь важно то, что каталог <filename>src/contrib/tcl</filename>
+      создавался в соответствии с правилами: Предполагается, что он содержит
+      исходные тексты в том виде, в котором они распространяются (в
+      соответствующей ветви поставщика CVS и без расширения ключевых слов
+      RCS) с максимально малым количеством изменений, специфичных для
+      FreeBSD.	Утилита 'easy-import' на машине <hostid>freefall</hostid> поможет в
+      импортировании, но если есть сомнения по поводу выполнения этой
+      операции, то обязательно спросите совета и не действуйте слепо в
+      расчете на то, что <quote>все сработает</quote>.	CVS не прощает ошибок
+      импортирования и для ликвидации последствий больших ошибок требуются
+      значительные усилия.</para>
+
+    <para>Из-за ранее отмеченных ограничений дизайна веток поставщиков в CVS
+      требуется, чтобы <quote>официальные</quote> патчи от разработчика
+      были сначала применены к распространяемым исходным текстам, а затем
+      результат снова импортирован в ветку поставщика.	Официальные патчи
+      никогда не должны применяться к версии, извлеченной из хранилища
+      FreeBSD, а затем <quote>коммититься</quote>, так как это приведет к
+      рассинхронизации дерева производителя и усложнит импортирование
+      будущих версий, так как возникнут конфликты.</para>
+
+    <para>Так как многие пакеты содержат файлы, имеющие значение при
+      обеспечении совместимости с другими, отличными от FreeBSD архитектурами
+      и окружениями, то разрешается удалять части дистрибутивного дерева,
+      не представляющие интереса для FreeBSD в целях уменьшения занимаемого
+      дискового пространства.  Файлы, содержащие замечания о юридических
+      правах и информацию о релизе, касающуюся остальных файлов, удаляться
+      <emphasis>не</emphasis> должны.</para>
+
+    <para>Если это видится легким, то файлы <filename>Makefile</filename> в
+      стиле <command>bmake</command> могут быть сгенерированы из
+      дистрибутивного дерева автоматически некоторой утилитой, чем-то, что
+      позволит еще проще обновляться до новой версии.  Если это будет
+      сделано, то обязательно поместите эту утилиту (если необходимо) в
+      каталог <filename>src/tools</filename> вместе с самим портом, чтобы
+      она была доступна будущим сопровождающим лицам.</para>
+
+    <para>В каталог <filename>src/contrib/tcl</filename> должен быть добавлен
+      файл <filename>FREEBSD-upgrade</filename>, в котором нужно перечислить
+      такие вещи:</para>
+
+    <itemizedlist>
+      <listitem>
+	<para>Какие файлы были оставлены</para>
+      </listitem>
+
+      <listitem>
+	<para>Где был взят оригинальный дистрибутив и/или на каком основном
+	  официальном сайте он находится.</para>
+      </listitem>
+
+      <listitem>
+	<para>Куда посылать патчи для разработчиков пакета</para>
+      </listitem>
+
+      <listitem>
+	<para>Возможно, обзор сделанных изменений, специфичных для
+	  FreeBSD.</para>
+      </listitem>
+    </itemizedlist>
+
+    <para>Однако, пожалуйста, не импортируйте
+      <filename>FREEBSD-upgrade</filename> вместе с исходными текстами
+      этого программного обеспечения.  Вместо этого вы должны выполнить
+      команды <command>cvs add FREEBSD-upgrade ; cvs ci</command> после
+      первоначального импортирования.  Ниже дается пример описания из
+      каталога <filename>src/contrib/cpio</filename>:</para>
+
+    <programlisting>This directory contains virgin sources of the original distribution files
+on a "vendor" branch.  Do not, under any circumstances, attempt to upgrade
+the files in this directory via patches and a cvs commit.  New versions or
+official-patch versions must be imported.  Please remember to import with
+"-ko" to prevent CVS from corrupting any vendor RCS Ids.
+
+For the import of GNU cpio 2.4.2, the following files were removed:
+
+	INSTALL 	cpio.info	mkdir.c
+	Makefile.in	cpio.texi	mkinstalldirs
+
+To upgrade to a newer version of cpio, when it is available:
+	1. Unpack the new version into an empty directory.
+	   [Do not make ANY changes to the files.]
+
+	2. Remove the files listed above and any others that don't apply to
+	   FreeBSD.
+
+	3. Use the command:
+		cvs import -ko -m 'Virgin import of GNU cpio v&lt;version&gt;' \
+			src/contrib/cpio GNU cpio_&lt;version&gt;
+
+	   For example, to do the import of version 2.4.2, I typed:
+		cvs import -ko -m 'Virgin import of GNU v2.4.2' \
+			src/contrib/cpio GNU cpio_2_4_2
+
+	4. Follow the instructions printed out in step 3 to resolve any
+	   conflicts between local FreeBSD changes and the newer version.
+
+Do not, under any circumstances, deviate from this procedure.
+
+To make local changes to cpio, simply patch and commit to the main
+branch (aka HEAD).  Never make local changes on the GNU branch.
+
+All local changes should be submitted to "cpio@gnu.ai.mit.edu" for
+inclusion in the next vendor release.
+
+obrien@FreeBSD.org - 30 March 1997
+    </programlisting>
+  </sect1>
+
+  <sect1 id="policies-encumbered">
+    <title>Нежелательные файлы</title>
+
+    <para>Иногда может быть необходимо включить некоторый нежелательный для
+      нас файл в дерево исходных текстов FreeBSD.  Например, если устройство
+      требует загрузки в него некоторого маленького двоичного кода перед тем,
+      как устройство заработает, и мы не имеем исходных текстов этого кода,
+      то говорится, что двоичный файл является нежелательным.  Для включения
+      нежелательных файлов в дерево исходных текстов FreeBSD имеются
+      следующие соглашения.</para>
+
+    <orderedlist>
+      <listitem>
+	<para>Любой файл, интерпретируемый или выполняемый системным(и) CPU,
+	  не в форме исходного кода, является нежелательным.</para>
+      </listitem>
+
+      <listitem>
+	<para>Любой файл с лицензией, ограничивающей более, чем BSD или GNU,
+	  является нежелательным.</para>
+      </listitem>
+
+      <listitem>
+	<para>Файл, содержащий загружаемые двоичные данные, используемые
+	  аппаратным обеспечением, не являются нежелательными, если только
+	  к нему не применимы условия (1) или (2).  Он должен быть сохранен в
+	  нейтральном к архитектуре формате ASCII (рекомендуется применить
+	  утилиты file2c или uuencode).</para>
+      </listitem>
+
+      <listitem>
+	<para>Любой нежелательный файл требует особого одобрения со стороны
+	  <ulink url="&url.articles.contributors;/staff-core.html">Правления</ulink> до
+	  того, как он будет добавлен в хранилище CVS.</para>
+      </listitem>
+
+      <listitem>
+	<para>Нежелательные файлы помещаются в каталог
+	  <filename>src/contrib</filename> или
+	  <filename>src/sys/contrib</filename>.</para>
+      </listitem>
+
+      <listitem>
+	<para>Части одного модуля должны храниться вместе.  Нет необходимости
+	  разбивать их, если только нет совместного использования с кодом,
+	  не являющимся нежелательным.</para>
+      </listitem>
+
+      <listitem>
+	<para>Объектные файлы именуются
+	  <filename><replaceable>arch</replaceable>/<replaceable>filename</replaceable>.o.uu></filename>.</para>
+      </listitem>
+
+      <listitem>
+	<para>Файлы ядра;</para>
+
+	<orderedlist>
+	  <listitem>
+	    <para>Должны всегда упоминаться в
+	      <filename>conf/files.*</filename> (для упрощения
+	      построения).</para>
+	  </listitem>
+
+	  <listitem>
+	    <para>Должны всегда присутствовать в <filename>LINT</filename>,
+	      но <ulink
+              url="&url.articles.contributors;/staff-core.html">Правление</ulink>
+	      решает в каждом конкретном случае, должны
+	      ли они быть раскомментированы или нет.  Конечно, позже <ulink
+	      url="&url.articles.contributors;/staff-core.html">Правление</ulink>
+	      может изменить свое решение.</para>
+	  </listitem>
+
+	  <listitem>
+	    <para>Вопрос о вхождении в состав релиза решается
+	      <firstterm>Группой Выпусков Релизов</firstterm>.</para>
+	  </listitem>
+	</orderedlist>
+      </listitem>
+
+      <listitem>
+	<para>Файлы уровня пользователя:</para>
+
+	<orderedlist>
+	  <listitem>
+	    <indexterm><primary>core team</primary></indexterm>
+	    <para><ulink
+	      url="&url.articles.contributors;/staff-core.html">Правление</ulink>
+	      решает, должен ли код стать частью
+	      выполнения команды <command>make world</command>.</para>
+	  </listitem>
+
+	  <listitem>
+	    <indexterm><primary>release engineer</primary></indexterm>
+	    <para><ulink url="&url.articles.contributors;/staff-who.html">Релиз
+	      инженер</ulink> решает, войдут ли они в релиз.</para>
+	  </listitem>
+	</orderedlist>
+      </listitem>
+    </orderedlist>
+  </sect1>
+
+  <sect1 id="policies-shlib">
+    <sect1info>
+      <authorgroup>
+       <author>
+         <firstname>Satoshi</firstname>
+         <surname>Asami</surname>
+         <contrib>Материал предоставили: </contrib>
+       </author>
+       <author>
+         <firstname>Peter</firstname>
+         <surname>Wemm</surname>
+       </author>
+       <author>
+         <firstname>David</firstname>
+         <surname>O'Brien</surname>
+       </author>
+      </authorgroup>
+      <!-- 9 Dec 1996 -->
+    </sect1info>
+
+    <title>Динамические библиотеки</title>
+
+    <para>Если вы добавляете поддержку динамических библиотек к порту или
+      другой части программного обеспечения, которая этой возможностью не
+      обладает, то номера версий должны назначаться по нижеследующим
+      правилам.  Как правило, получающиеся номера не имеют ничего общего с
+      номером релиза программного обеспечения.</para>
+
+    <para>При построении динамической библиотеки используются три
+      принципа:</para>
+
+    <itemizedlist>
+      <listitem>
+	<para>Начинаем с <literal>1.0</literal></para>
+      </listitem>
+
+      <listitem>
+	<para>Если есть изменение, которое имеет обратную совместимость,
+	  увеличиваем младший номер версии (заметьте, что системы ELF его
+	  игнорируют)</para>
+      </listitem>
+
+      <listitem>
+	<para>Если есть изменение, не соблюдающее совместимость, увеличиваем
+	  старший номер версии</para>
+      </listitem>
+    </itemizedlist>
+
+    <para>К примеру, добавление функций и исправление ошибок приводит к
+      увеличению младшего номера версии, а удаление функций, изменение
+      синтаксиса вызова функции и тому подобные изменения приводят к
+      изменению старшего номера версии.</para>
+
+    <para>Следуйте схеме нумерации версий в форме старший.младший
+      (<replaceable>x</replaceable>.<replaceable>y</replaceable>).  Наш
+      динамический загрузчик формата a.out не умеет нормально работать с
+      номерами версий в форме
+      <replaceable>x</replaceable>.<replaceable>y</replaceable>.<replaceable>z</replaceable>.
+      Любой номер версии после <replaceable>y</replaceable> (то есть третье
+      число) полностью игнорируется при сравнении номеров версий динамических
+      библиотек для определения того, с какой библиотекой осуществлять
+      компоновку.  Если есть две динамические библиотеки, отличающиеся только
+      <quote>микро</quote>-номером версии, то <command>ld.so</command> будет
+      осуществлять компоновку с наибольшим номером.  Другими словами:  если
+      вы компонуете с <filename>libfoo.so.3.3.3</filename>, то компоновщик
+      запишет в заголовках только <literal>3.3</literal> и будет выполнять
+      компоновку с любой библиотекой, начинающейся с
+      <replaceable>libfoo.so.3</replaceable>.<replaceable>(все, что &gt;=
+      3)</replaceable>.<replaceable>(наибольшее из
+      доступного)</replaceable>.</para>
+
+    <note>
+      <para><command>ld.so</command> всегда будет использовать наибольшую
+	<quote>младшую</quote> версию.	Иными словами: он будет предпочитать
+	использовать <filename>libc.so.2.2</filename>, а не
+	<filename>libc.so.2.0</filename>, даже если программа изначально была
+	скомпонована с <filename>libc.so.2.0</filename>.</para>
+    </note>
+
+    <para>Вдобавок наш динамический компоновщик ELF совсем не работает с
+      младшими версиями.  Однако все же нужно указывать старший и младший
+      номер версии, а наши файлы <filename>Makefile</filename> <quote>сделают
+      все как нужно</quote> в зависимости от типа системы.</para>
+
+    <para>Для библиотек не в составе портов, имеется наше соглашение на
+      изменение номера версии динамической библиотеки только один раз между
+      релизами.  Кроме того, есть договоренность на изменение старшего
+      номера динамической библиотеки только один раз между главными релизами
+      ОС (например c 3.0 к 4.0).  Когда вы делаете изменение в системной
+      библиотеке, которое требует увеличения номера версии, посмотрите
+      журналы коммитов изменений в файле <filename>Makefile</filename>.
+      Коммиттер отвечает за то, что первое такое изменение с момента релиза
+      приведет к обновлению номера версии динамической библиотеки в файле
+      <filename>Makefile</filename>, а при других последующих изменениях
+      этого бы не делалось.</para>
+  </sect1>
+</chapter>
+
+<!--
+     Local Variables:
+     mode: sgml
+     sgml-declaration: "../chapter.decl"
+     sgml-indent-data: t
+     sgml-omittag: nil
+     sgml-always-quote-attributes: t
+     sgml-parent-document: ("../book.sgml" "part" "chapter")
+     End:
+-->