diff options
Diffstat (limited to 'ru_RU.KOI8-R/articles/committers-guide/article.xml')
| -rw-r--r-- | ru_RU.KOI8-R/articles/committers-guide/article.xml | 3352 |
1 files changed, 0 insertions, 3352 deletions
diff --git a/ru_RU.KOI8-R/articles/committers-guide/article.xml b/ru_RU.KOI8-R/articles/committers-guide/article.xml deleted file mode 100644 index cf8dfd4e81..0000000000 --- a/ru_RU.KOI8-R/articles/committers-guide/article.xml +++ /dev/null @@ -1,3352 +0,0 @@ -<?xml version="1.0" encoding="koi8-r"?> -<!DOCTYPE article PUBLIC "-//FreeBSD//DTD DocBook XML V5.0-Based Extension//EN" - "http://www.FreeBSD.org/XML/share/xml/freebsd50.dtd"> -<!-- - The FreeBSD Russian Documentation Project - - $FreeBSDru: frdp/doc/ru_RU.KOI8-R/articles/committers-guide/article.xml,v 1.30 2007/05/09 06:08:23 gad Exp $ - - Original revision: r30088 ---> -<article xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0" xml:lang="ru"> - <info><title>Справочник коммиттера</title> - - - <authorgroup> - <author><personname><surname>The FreeBSD Documentation Project</surname></personname></author> - <author><personname><firstname>Дмитрий</firstname><surname>Морозовский</surname></personname><contrib>Перевод на русский язык: </contrib></author> - </authorgroup> - - <copyright> - <year>1999</year> - <year>2000</year> - <year>2001</year> - <year>2002</year> - <year>2003</year> - <year>2004</year> - <year>2005</year> - <year>2006</year> - <year>2007</year> - <holder>The FreeBSD Documentation Project</holder> - </copyright> - - <legalnotice xml:id="trademarks" role="trademarks"> - &tm-attrib.freebsd; - &tm-attrib.cvsup; - &tm-attrib.ibm; - &tm-attrib.intel; - &tm-attrib.sparc; - &tm-attrib.general; - </legalnotice> - - <pubdate>$FreeBSD$</pubdate> - - <releaseinfo>$FreeBSD$</releaseinfo> - - <abstract> - <para>Данный документ содержит информацию для сообщества коммиттеров - FreeBSD. Все новые коммиттеры должны изучить его перед началом работы; - прочим коммиттерам также рекомендуется время от времени просматривать - его.</para> - </abstract> - </info> - - <sect1 xml:id="admin"> - <title>Административные детали</title> - - <informaltable frame="none" orient="port" pgwide="1"> - <tgroup cols="2"> - <tbody> - <row> - <entry><emphasis>Хост основного репозитория</emphasis></entry> - <entry><systemitem class="fqdomainname">ncvs.FreeBSD.org</systemitem></entry> - </row> - - <row> - <entry><emphasis>Способ авторизации</emphasis></entry> - <entry>&man.ssh.1;, только протокол 2</entry> - </row> - - <row> - <entry><emphasis>Основной корень репозитория (CVSROOT)</emphasis></entry> - <entry> - <systemitem class="fqdomainname">ncvs.FreeBSD.org</systemitem><literal>:</literal><filename>/home/ncvs</filename> (см. также <xref linkend="cvs.operations"/>). - </entry> - </row> - - <row> - <entry><emphasis>&a.cvsadm;</emphasis></entry> - <entry>&a.peter.email; и &a.markm.email;, а также &a.joe.email; и &a.marcus.email; для - иерархии <filename>ports/</filename></entry> - </row> - - <row> - <entry><emphasis>Списки рассылки</emphasis></entry> - <entry>&a.doc-developers;, &a.doc-committers;; - &a.ports-developers;, &a.ports-committers;; - &a.src-developers;, &a.src-committers;. (Каждому репозиторию - проекта соответствуют отдельные списки рассылки с суффиксами - -developers и -committers. Архивы этих списков хранятся в файлах - <filename>/home/mail/<replaceable>repository-name</replaceable>-developers-archive</filename> - и - <filename>/home/mail/<replaceable>repository-name</replaceable>-committers-archive</filename> - на машинах кластера <systemitem class="fqdomainname">FreeBSD.org</systemitem>). - </entry> - </row> - - - <row> - <entry><emphasis>Отчеты Правления</emphasis></entry> - <entry><filename>/home/core/public/monthly-report</filename> - на машинах кластера <systemitem class="fqdomainname">FreeBSD.org</systemitem>. - </entry> - </row> - - <row> - <entry><emphasis>Наиболее значимые метки CVS</emphasis></entry> - <entry><literal>RELENG_4</literal> (ветвь 4.X-STABLE), - <literal>RELENG_5</literal> (ветвь 5.X-STABLE), - <literal>RELENG_6</literal> (ветвь 6.X-STABLE), - <literal>HEAD</literal> (ветвь -CURRENT)</entry> - </row> - </tbody> - </tgroup> - </informaltable> - - <para>Для авторизации на машины проекта вы должны использовать протоколы - &man.ssh.1; или &man.telnet.1; с включенным Kerberos 5. В случае - &man.ssh.1;, допустим только протокол версии 2. - Эти протоколы являются значительно более защищенными по сравнению с - &man.telnet.1; или &man.rlogin.1;, поскольку информация об авторизации - передается в зашифрованном виде. По умолчанию, протокол &man.ssh.1; - также шифрует весь трафик. Учитывая наличие таких утилит, как - &man.ssh-agent.1; и &man.scp.1;, протокол &man.ssh.1; значительно - удобнее прочих в использовании. Если вы ничего не знаете об &man.ssh.1;, - загляните в раздел <xref linkend="ssh.guide"/>.</para> - </sect1> - - <sect1 xml:id="committer.types"> - <title>Типы коммит битов</title> - - <para>CVS Репозиторий FreeBSD состоит из нескольких разделов, охватывающих - исходные тексты базовой операционной системы, документацию, инфраструктуру - построения внешних приложений (портов), а также различные служебные - утилиты. Право записи в репозиторий (<quote>коммит бит</quote>) - подразумевает указание области дерева, в которое оно может быть применено. - Как правило, области напрямую связаны с группой, подтвердившей право - коммиттера на бит. В дальнейшем, область действия коммит бита - может быть расширена; в этом случае, коммиттер должен следовать - стандартным правилам нового для коммиттера в данной области, в частности, - получая подтверждения на каждый коммит и, возможно, в течение какого-то - времени работу с ментором.</para> - - <informaltable frame="none" pgwide="1"> - <tgroup cols="3"> - <tbody> - <row> - <entry><emphasis>Тип коммит бита</emphasis></entry> - <entry><emphasis>Ответственные</emphasis></entry> - <entry><emphasis>Области репозитория</emphasis></entry> - </row> - - <row> - <entry>src</entry> - <entry>core@</entry> - <entry>src/ и соответствующие части doc/</entry> - </row> - - <row> - <entry>doc</entry> - <entry>doceng@</entry> - <entry>doc/, www/, документация дерева src/</entry> - </row> - - <row> - <entry>ports</entry> - <entry>portmgr@</entry> - <entry>ports/</entry> - </row> - </tbody> - </tgroup> - </informaltable> - - <para>Биты, выделенные до разделения дерева на области могут использоваться - во всех частях дерева. Однако, с точки зрения здравого смысла, коммиттер, - не имеющий опыта работы в какой-либо части дерева, должен предоставлять - предлагаемые изменения для рассмотрения другими коммиттерами, получать - подтверждения от ответственных за различные части репозитория, а также, - возможно, работать совместно с ментором. Поскольку правила ведения - различных областей кода различаются, указанные нормы скорее направлены - на благо коммиттера, не имеющего достаточного опыта работы в данной - области.</para> - - <para>Вне зависимости от области приложения усилий, запросы коммиттеров - на рассмотрение предлагаемых изменений в процессе разработки могут - только приветствоваться.</para> - - <sect2> - <title>Правила для коммиттеров документации (<filename>doc/</filename>) - при работе с деревом исходных текстов - (<filename>src/</filename>)</title> - - <itemizedlist> - <listitem><para>Коммиттеры документации могут самостоятельно изменять - документацию к исходным текстам, например, страницы справочника, файлы - README, базы данных утилиты fortune, календарей, а также исправлять - комментарии в исходных текстах без дополнительного согласования с - коммиттерами исходных текстов, при условии сохранения здравого смысла - и манеры коммитов.</para></listitem> - - <listitem><para>Коммиттеры документации могут вносить незначительные - изменения и исправления в исходные тексты (такие как исправления к - процессу сборки, добавление малых дополнительных возможностей и т.п.) - при наличии одобрения от коммиттера исходных - текстов.</para></listitem> - - <listitem><para>Коммиттер документации может расширить область действия - своего бита на область исходных текстов (и стать, таким образом, - коммиттером исходных текстов), найдя себе ментора, который предложит - это расширение Правлению (Core). После одобрения, строка с его именем - пользователя вносится в файл 'access', и применяются обычные правила - периода работы с ментором, подразумевающие получение одобрения на - каждый коммит.</para></listitem> - - <listitem><para>Одобрение коммита ("Approved by") может производиться - только "полновесным" (не работающим с ментором) коммиттером исходных - текстов; последние могут рассматривать предлагаемые изменения и - указываться в строке "Reviewed by".</para></listitem> - </itemizedlist> - </sect2> - - </sect1> - - <sect1 xml:id="cvs.operations"> - <title>Работа с CVS</title> - - <para>Подразумевается, что вы уже имеете опыт базовой работы с CVS.</para> - - <para>&a.cvsadm; являются <quote>владельцами</quote> репозитория CVS и - ответственны за все прямые его изменения (в целях чистки или исправления - каких-либо вопиющих ошибок коммиттеров при работе с CVS). Если в - результате ваших действий с частью репозитория произошел несчастный - случай, например, после неверной операции <command>cvs import</command> - или <command>cvs tag</command>, пошлите письмо соответствующей подгруппе - &a.cvsadm; (см. следующую таблицу) и сообщите о проблеме. В наиболее - серьезных случаях, касающихся не только какой-либо части репозитория, а - дерева CVS в целом, вы можете написать &a.cvsadm;. Пожалуйста, - <emphasis>не надо</emphasis> писать группе &a.cvsadm; по поводу - репозиторного копирования и прочих вопросов, которые может решить - соответствующая подгруппа.</para> - - <para><anchor xml:id="repomeisters"/>Напрямую изменять содержимое репозитория может только группа - CVS-мастеров; для обеспечения этого, только CVS-мастера имеют учетные - записи на машинах, поддерживающих основной репозиторий.</para> - - <note><para>Адреса, на которые следует посылать запросы, зависят от области - репозитория, которую требуется поправить:</para> - - <itemizedlist> - <listitem><para>ncvs@ - репозиторий <filename> - /home/ncvs</filename>, основные исходные тексты - </para></listitem> - - <listitem><para>pcvs@ - репозиторий <filename> - /home/pcvs</filename>, порты</para></listitem> - - <listitem><para>dcvs@ - репозиторий <filename> - /home/dcvs</filename>, документация</para></listitem> - - <listitem><para>projcvs@ - репозиторий <filename> - /home/projcvs</filename>, прочие проекты</para></listitem> - </itemizedlist> - </note> - - <para>Дерево CVS в настоящее время разделено на четыре независимых - репозитория: <literal>doc</literal>, <literal>ports</literal>, - <literal>projects</literal> и <literal>src</literal>. Для удобства - работы пользователей при распространении через - <application>CVSup</application> различные деревья комбинируются в - одно, с одним служебным каталогом <literal>CVSROOT</literal>.</para> - - <note><para>Обратите внимание, что модуль <literal>www</literal>, содержащий - исходные тексты - <link xlink:href="http://www.FreeBSD.org">веб-сайта FreeBSD</link>, расположен - в репозитории <literal>doc</literal>.</para></note> - - <para>В настоящее время, все репозитории CVS располагаются на одной машине, - <systemitem class="fqdomainname">ncvs.FreeBSD.org</systemitem>, однако, для обеспечения - возможности в будущем разнести их по физически различным машинам, для - каждой поддерживается отдельное имя хоста. Их и следует использовать - коммиттерам. Наконец, каждый репозиторий расположен в отдельном каталоге. - В итоге, общая картина выглядит так:</para> - - <table frame="none" xml:id="cvs-repositories-and-hosts"> - <title>Репозитории CVS &os;, хосты и каталоги</title> - - <tgroup cols="3"> - <thead> - <row> - <entry>Репозиторий</entry> - <entry>Хост</entry> - <entry>Каталог</entry> - </row> - </thead> - - <tbody> - <row> - <entry>doc</entry> - <entry>dcvs.FreeBSD.org</entry> - <entry>/home/dcvs</entry> - </row> - - <row> - <entry>ports</entry> - <entry>pcvs.FreeBSD.org</entry> - <entry>/home/pcvs</entry> - </row> - - <row> - <entry>projects</entry> - <entry>projcvs.FreeBSD.org</entry> - <entry>/home/projcvs</entry> - </row> - - <row> - <entry>src</entry> - <entry>ncvs.FreeBSD.org</entry> - <entry>/home/ncvs</entry> - </row> - </tbody> - </tgroup> - </table> - - <para>Операции с CVS производятся удаленно, путем установки переменной - окружения <envar>CVSROOT</envar> (она должна указывать на соответствующий - хост и каталог верхнего уровня, например - <systemitem class="fqdomainname">ncvs.FreeBSD.org</systemitem><literal>:</literal><filename>/home/ncvs</filename>) - и последующего выполнения команд выгрузки и коммита. Многие коммиттеры - определяют команды-синонимы, разворачивающиеся в запуск - <application>cvs</application> с правильными параметрами. В частности, - пользователи оболочки &man.tcsh.1; могут добавить следующие строки в - свой скрипт начальной загрузки <filename>.cshrc</filename>:</para> - - <programlisting>alias dcvs cvs -d <replaceable>user</replaceable>@dcvs.FreeBSD.org:/home/dcvs -alias pcvs cvs -d <replaceable>user</replaceable>@pcvs.FreeBSD.org:/home/pcvs -alias projcvs cvs -d <replaceable>user</replaceable>@projcvs.FreeBSD.org:/home/projcvs -alias scvs cvs -d <replaceable>user</replaceable>@ncvs.FreeBSD.org:/home/ncvs</programlisting> - - <para>Теперь все операции с CVS могут выполняться на локальной машине, - а для внесения изменений в официальное дерево CVS следует использовать - команду <command><replaceable>X</replaceable>cvs commit</command>. - Если вам нужно добавить в проект что-либо совершенно новое (например, - исходные тексты сторонних разработчиков), нужно использовать команду - <command>cvs import</command>; обратитесь к странице справочника по - &man.cvs.1; за подробностями.</para> - - <note> - <para>Пожалуйста, <emphasis>не используйте</emphasis> команды - <command>cvs checkout</command> или - <command>cvs update</command> для синхронизации ваших исходных текстов. - Протокол CVS не оптимизирован для удаленной работы и требует - значительных накладных расходов со стороны сервера. Пожалуйста, - используйте метод синхронизации посредством <command>cvsup</command>, - а основной хост используйте только для собственно коммитов. - Наша распределенная сеть серверов cvsup достаточно развита. При - необходимости синхронизации с самыми свежими изменениями вы можете - пользоваться машиной <systemitem>cvsup-master</systemitem>, которая обладает - достаточными ресурсами для удаленной работы с CVS; за нее отвечает - &a.kuriyama.email;. - </para> - </note> - - <para>Если вам нужно использовать команды CVS <command>add</command> и - <command>delete</command>, так чтобы в реальности переместить часть - исходных текстов подобно действию команды &man.mv.1;, нужно запросить - операцию <quote>репозиторного копирования</quote> (repository copy). - При этом кто-либо из <link linkend="repomeisters">CVS-мастеров</link> - скопирует необходимые файлы внутри репозитория на нужное место и даст вам - знать об этом. Репозиторное копирование производится для сохранения - истории (журналов изменения). Возможность отследить историю изменений - очень ценна для всего проекта FreeBSD.</para> - - <para>Документация по CVS, учебные материалы и FAQ можно найти по адресу: - <uri xlink:href="http://www.cvshome.org/docs/">http://www.cvshome.org/docs/</uri>. - Очень полезна также книга Карла Фогеля (Karl Fogel) - <link xlink:href="http://cvsbook.red-bean.com/cvsbook.html">Open Source - Development with CVS</link>. - Некоторая полезная информация о CVS на русском языке может быть найдена - <link xlink:href="http://alexm.here.ru/cvs-ru/">здесь</link>.</para> - - <para>&a.des.email; написал такой <quote>мини-пример</quote> работы с CVS:</para> - - <orderedlist> - <listitem> - <para>Извлечение нужного модуля из репозитория: команда - <command>co</command> или <command>checkout</command>.</para> - - <screen>&prompt.user; <userinput>cvs checkout shazam</userinput></screen> - - <para>Эта команда извлечет копию модуля <filename>shazam</filename>. - Если модуль с таким именем не существует (не описан в файле modules), - будет произведена попытка извлечь директорию верхнего уровня - <filename>shazam</filename>.</para> - - <table frame="none"> - <title>Полезные опции команды <command>cvs checkout</command></title> - - <tgroup cols="2"> - <tbody> - <row> - <entry><option>-P</option></entry> - <entry>Не создавать (точнее, удалить после завершения - выполнения) пустые каталоги</entry> - </row> - - <row> - <entry><option>-l</option></entry> - <entry>Извлекать один уровень каталогов (без - подкаталогов)</entry> - </row> - - <row> - <entry><option>-r<replaceable>rev</replaceable></option></entry> - <entry>Извлечь ревизию, ветвь или тег - <replaceable>rev</replaceable> для указанного модуля</entry> - </row> - - <row> - <entry><option>-D<replaceable>date</replaceable></option></entry> - <entry>Извлечь состояние модуля в репозитории на момент - <replaceable>date</replaceable></entry> - </row> - </tbody> - </tgroup> - </table> - - <para>Примеры в применении к FreeBSD:</para> - - <itemizedlist> - <listitem> - <para>Извлечь модуль <filename>miscfs</filename>, расположенный в - каталоге репозитория <filename>src/sys/miscfs</filename>:</para> - - <screen>&prompt.user; <userinput>cvs co miscfs</userinput></screen> - - <para>После выполнения вы получите каталог - <filename>miscfs</filename>, содержащий подкаталоги - <filename>CVS</filename>, <filename>deadfs</filename>, - <filename>devfs</filename> и т.д. Один из них - (<filename>linprocfs</filename>) будет пустым.</para> - </listitem> - - <listitem> - <para>Извлечь те же файлы, но с полным путем:</para> - - <screen>&prompt.user; <userinput>cvs co src/sys/miscfs</userinput></screen> - - <para>Теперь у вас есть каталог <filename>src</filename>, - содержащий подкаталоги <filename>CVS</filename> и - <filename>sys</filename>. Каталог <filename>src/sys</filename> - содержит подкаталоги <filename>CVS</filename> и - <filename>miscfs</filename> и т.д.</para> - </listitem> - - <listitem> - <para>Извлечь те же файлы, удалив при этом пустые - подкаталоги:</para> - - <screen>&prompt.user; <userinput>cvs co -P miscfs</userinput></screen> - - <para>Вы получите каталог - <filename>miscfs</filename> с подкаталогами - <filename>CVS</filename>, <filename>deadfs</filename>, - <filename>devfs</filename>... однако без подкаталога - <filename>linprocfs</filename>, поскольку он не содержит файлов.</para> - </listitem> - - <listitem> - <para>Извлечь каталог <filename>miscfs</filename> без - подкаталогов:</para> - - <screen>&prompt.user; <userinput>cvs co -l miscfs</userinput></screen> - - <para>Теперь в каталоге <filename>miscfs</filename> будет только - один подкаталог <filename>CVS</filename>.</para> - </listitem> - - <listitem> - <para>Извлечь модуль <filename>miscfs</filename> из ветви - 6.X:</para> - - <screen>&prompt.user; <userinput>cvs co -rRELENG_6 miscfs</userinput></screen> - - <para>Теперь вы можете изменить исходные тексты и произвести коммит - в эту ветвь.</para> - </listitem> - - <listitem> - <para>Извлечь модуль <filename>miscfs</filename> по состоянию на - момент выхода 6.0-RELEASE:</para> - - <screen>&prompt.user; <userinput>cvs co -rRELENG_6_0_0_RELEASE miscfs</userinput></screen> - - <para>В этом случае вы не сможете внести изменения в репозиторий, - поскольку <literal>RELENG_6_0_0_RELEASE</literal> описывает - момент времени, а не ветвь разработки.</para> - </listitem> - - <listitem> - <para>Извлечь модуль <filename>miscfs</filename> по состоянию на - 15 января 2000 г:</para> - - <screen>&prompt.user; <userinput>cvs co -D'01/15/2000' miscfs</userinput></screen> - - <para>Как и в предыдущем случае, изменения не могут быть - записаны.</para> - </listitem> - - <listitem> - <para>Извлечь модуль <filename>miscfs</filename>, каким он был - неделю назад:</para> - - <screen>&prompt.user; <userinput>cvs co -D'last week' miscfs</userinput></screen> - - <para>И вновь, изменения не могут быть записаны.</para> - </listitem> - </itemizedlist> - - <para>Обратите внимание, что мета-данные хранятся в подкаталогах - <filename>CVS</filename>.</para> - - <para>Аргументы опций <option>-D</option> and <option>-r</option> - сохраняются (являются <quote>клейкими</quote>, sticky), например, - при последующем использовании команды - <command>cvs update</command>.</para> - </listitem> - - <listitem> - <para>Проверка состояния извлеченных файлов: команда - <command>status</command>.</para> - - <screen>&prompt.user; <userinput>cvs status shazam</userinput></screen> - - <para>Эта команда покажет статус файла <filename>shazam</filename> - или каждого файла в директории <filename>shazam</filename>. - Для каждого из файлов статус может быть одним из:</para> - - <informaltable frame="none" pgwide="1"> - <tgroup cols="2"> - <tbody> - <row> - <entry>Up-to-date</entry> - <entry>Файл соответствует репозиторию и не - модифицировался</entry> - </row> - - <row> - <entry>Needs Patch</entry> - <entry>Файл не изменялся, но репозиторий содержит обновленную - версию</entry> - </row> - - <row> - <entry>Locally Modified</entry> - <entry>Файл соответствует репозиторию, но был изменен - локально</entry> - </row> - - <row> - <entry>Needs Merge</entry> - <entry>Файл изменен локально; вместе с тем, файл изменен и в - репозитории</entry> - </row> - - <row> - <entry>File had conflicts on merge</entry> - <entry>После последнего обновления возникли конфликты, и они - все еще не устранены</entry> - </row> - </tbody> - </tgroup> - </informaltable> - - <para>Кроме того, будут показаны локальная версия и дата модификации, - версия и дата последней из доступных (если вы применяли - <quote>клейкие</quote> дату, тег или ветвь, последняя доступная версия - может отличаться от вашей), а также клейкие теги, временные метки - и опции.</para> - </listitem> - - <listitem> - <para>Обновление извлеченного модуля: команда - <command>update</command>.</para> - - <screen>&prompt.user; <userinput>cvs update shazam</userinput></screen> - - <para>Эта команда обновит состояние файла <filename>shazam</filename> - или файлов в каталоге <filename>shazam</filename> до наиболее - свежих версий выбранной вами при извлечении ветви. Если выбирался - <quote>момент времени</quote>, не произойдет ничего, если только - за истекшее время в репозитории не был перемещен тег или не - произошло чего-нибудь еще непредвиденного.</para> - - <para>Полезные опции в дополнение к уже описанным для команды - <command>checkout</command>:</para> - - <informaltable frame="none" pgwide="1"> - <tgroup cols="2"> - <tbody> - <row> - <entry><option>-d</option></entry> - <entry>Извлечь вновь появившиеся или пропущенные ранее - подкаталоги</entry> - </row> - - <row> - <entry><option>-A</option></entry> - <entry>Обновиться до текущего состояния головной ветви</entry> - </row> - - <row> - <entry><option>-j<replaceable>rev</replaceable></option></entry> - <entry>магическая опция (см. ниже)</entry> - </row> - </tbody> - </tgroup> - </informaltable> - - <para>Если вы извлекали модуль с опциями <option>-r</option> или - <option>-D</option>, выполнение команды <command>cvs update</command> - с другими параметрами <option>-r</option> или <option>-D</option> - или с опцией <option>-A</option> приведет к выбору новой ветви, - ревизии или даты. Использование опции <option>-A</option> - удаляет использованные ранее клейкие свойства; опции - <option>-r</option> и <option>-D</option>, наоборот, фиксируют - их.</para> - - <para>Теоретически использование <literal>HEAD</literal> в качестве - аргумента опции <option>-r</option> должно дать тот же результат, что - и указание опции <option>-A</option>, однако это верно лишь - в теории.</para> - - <para>Опция <option>-d</option> полезна, если:</para> - <itemizedlist> - <listitem> - <para>после извлечения вами модуля кем-либо еще в него были - добавлены дополнительные каталоги;</para> - </listitem> - - <listitem> - <para>вы извлекали верхний уровень модуля при помощи опции - <option>-l</option>, а в дальнейшем решили извлечь и - подкаталоги;</para> - </listitem> - - <listitem> - <para>вы удалили какие-либо подкаталоги и теперь хотите - вновь извлечь их.</para> - </listitem> - </itemizedlist> - - <para><emphasis>Обращайте внимание на вывод команды <command>cvs - update</command>.</emphasis> Действие, произведенное с файлом, - обозначается буквой перед его именем:</para> - - <informaltable frame="none" pgwide="1"> - <tgroup cols="2"> - <tbody> - <row> - <entry><literal>U</literal></entry> - <entry>Файл был успешно обновлен.</entry> - </row> - - <row> - <entry><literal>P</literal></entry> - <entry>Файл был успешно обновлен (произведен успешный патч - из удаленного репозитория).</entry> - </row> - - <row> - <entry><literal>M</literal></entry> - <entry>Файл был изменен, и при этом обновлен успешно.</entry> - </row> - - <row> - <entry><literal>C</literal></entry> - <entry>Файл был изменен, и при объединении изменений возникли - конфликты.</entry> - </row> - </tbody> - </tgroup> - </informaltable> - - <para>Объединение (merging) производится, если вы выгрузили рабочую - копию какого-то модуля, изменили его, затем кто-либо еще произвел - коммит собственных изменений, и, наконец, вы выполняете команду - <command>cvs update</command>. CVS знает, что производились локальные - изменения, и пытается объединить ваши изменения с теми, что произошли - в репозитории (от состоянии версии, которую вы выгружали, до версии, - до которой вы пытаетесь обновиться). Если изменения происходили с - различными частями файла, объединение почти всегда произойдет успешно - (хотя результат при этом может не быть синтаксически или семантически - корректным).</para> - - <para>CVS выводит букву <literal>M</literal> перед именем всех локально - измененных файлов, даже если у них нет новых версий в репозитории, - так что команда <command>cvs update</command> удобна для быстрого - получения списка файлов, которые вы изменяли.</para> - - <para>Если в результате вы видите букву <literal>C</literal>, ваши - изменения конфликтуют с изменениями, внесенными в репозиторий - (изменения были в одних и тех же или рядом расположенных строках, - либо вы изменили файл настолько, что при сравнении - <command>cvs</command> не смогла удержать контекст и приложить - изменения из репозитория). Вам необходимо устранить конфликты, - вручную редактируя файл. Конфликтующие фрагменты помечаются - строками из знаков <literal><</literal>, <literal>=</literal> и - <literal>></literal>. В начале каждого из конфликтов присутствует - строка из семи знаков <literal><</literal> и имени файла, затем - идет фрагмент, содержащий внесенные вами изменения, разделитель - из семи знаков <literal>=</literal>, соответствующий фрагмент из - версии файла, содержащейся в репозитории, и, наконец, строка из семи - знаков <literal>></literal> совместно с номером версии, до которой - вы обновляли файл.</para> - - <para>Опция <option>-j</option> содержит некоторое количество черной - магии. При ее наличии локальный файл обновляется до указанной версии - так же, как и при использовании опции <option>-r</option>, но - отслеживаемые номер версии или ветвь не изменяются. Эта опция умеет - смысл лишь при парном использовании: при этом делается попытка - применить изменения между двумя указанными версиями к локальной - копии файла.</para> - - <para>К примеру, вы внесли изменения и произвели коммит в файл - <filename>shazam/shazam.c</filename> в &os.current;, а позднее - хотите перенести обновления в &os.stable; (Merge-From-Current, MFC). - Версия, которая требует переноса — 1.15:</para> - - <itemizedlist> - <listitem> - <para>Извлеките текущую версию модуля <filename>shazam</filename> - для ветви &os.stable;:</para> - - <screen>&prompt.user; <userinput>cvs co -rRELENG_6 shazam</userinput></screen> - </listitem> - - <listitem> - <para>Приложите изменения между версиями 1.14 и 1.15:</para> - - <screen>&prompt.user; <userinput>cvs update -j1.14 -j1.15 shazam/shazam.c</userinput></screen> - </listitem> - </itemizedlist> - - <para>Почти наверняка вы получите конфликт в строках, содержащих - идентификатор файла (<literal>$Id: article.xml,v 1.19 2007-05-09 06:08:50 bvs Exp $</literal> или, в случае FreeBSD, - <literal>$FreeBSD$</literal>). - Вам потребуется отредактировать файл для устранения конфликта - (в данном случае достаточно убрать строки-разделители и вторую строку - <literal>$Id: article.xml,v 1.19 2007-05-09 06:08:50 bvs Exp $</literal>, оставив лишь строку с <literal>$Id: article.xml,v 1.19 2007-05-09 06:08:50 bvs Exp $</literal> - для &os.stable;).</para> - </listitem> - - <listitem> - <para>Просмотр изменение между локальной версией и версией из - репозитория: команда <command>diff</command>.</para> - - <screen>&prompt.user; <userinput>cvs diff shazam</userinput></screen> - - <para>Эта команда покажет все отличия локального состояния файла (или - файлов модуля) <filename>shazam</filename> от состояния, сохраненного - в репозитории.</para> - - <table frame="none"> - <title>Полезные опции команды <command>cvs diff</command></title> - - <tgroup cols="2"> - <tbody> - <row> - <entry><option>-u</option></entry> - <entry>Использовать унифицированный (unified) формат.</entry> - </row> - - <row> - <entry><option>-c</option></entry> - <entry>Использовать контекстный (context) формат.</entry> - </row> - - <row> - <entry><option>-N</option></entry> - <entry>Показывать отсутствующие или созданные файлы.</entry> - </row> - </tbody> - </tgroup> - </table> - - <para>Всегда имеет смысл пользоваться опцией <option>-u</option>, - поскольку унифицированный формат гораздо удобнее и лучше читаем, - чем почти все другие (в некоторых случаях контекстный формат, - генерируемый опцией <option>-c</option> может быть несколько лучше, - но он гораздо более громоздок). Унифицированный формат различий - состоит из серии фрагментов, каждый из которых начинается со строки, - состоящей из двух символов <literal>@</literal> и номеров строк, - описывающих положение изменившегося участка. Затем следует группа - строк: те, что начинаются с пробела, описывают контекст, начинающиеся - с символа <literal>-</literal> определяют удаленные строки, наконец, - начинающиеся с символа <literal>+</literal> — - добавленные.</para> - - <para>Вы можете сравнивать текущее состояние с версией, отличающейся - от той, с которой вы извлекали файл, указав опцию <option>-r</option> - или <option>-D</option> подобно командам <command>checkout</command> - и <command>update</command>, или даже получить список изменений между - любыми двумя версиями (вне зависимости от того, что лежит в вашей - локальной копии), указав <emphasis>две</emphasis> версии при помощи - опций <option>-r</option> или <option>-D</option>.</para> - </listitem> - - <listitem> - <para>Просмотр журнала изменений: команда <command>log</command>.</para> - - <screen>&prompt.user; <userinput>cvs log shazam</userinput></screen> - - <para>Если <filename>shazam</filename> является обычным файлом, эта - команда выдаст на экран <emphasis>заголовок</emphasis> с информацией - о файле, в частности, его местоположении в репозитории, какая версия - соответствует текущему состоянию (<literal>HEAD</literal>), в каких - ветвях разработки файл присутствует, а также перечислит теги, которыми - он помечен. Затем, для каждой версии файла выводится соответствующее - ей журнальное сообщение, включающее дату, время и автора коммита, - количество добавленных и удаленных строк и собственно журнального - сообщения, написанного коммиттером.</para> - - <para>Если <filename>shazam</filename> является каталогом, вышеописанная - процедура выполняется для каждого файла в каталоге. Если при этом - команде <command>log</command> не был указан флаг <option>-l</option>, - процедура рекурсивно повторяется для всех подкаталогов.</para> - - <para>Команда <command>log</command> используется для просмотра истории - одного или нескольких файлов в том виде, как она сохранена в - репозитории CVS. Используя опцию - <option>-r<replaceable>rev</replaceable></option>, вы можете - посмотреть журнальное сообщение к одной определенной версии:</para> - - <screen>&prompt.user; <userinput>cvs log -r1.2 shazam</userinput></screen> - - <para>Эта команда покажет журнальное сообщение для версии - <literal>1.2</literal> файла <filename>shazam</filename> (или для - версий <literal>1.2</literal> каждого из файлов в каталоге - <filename>shazam</filename>).</para> - </listitem> - - <listitem> - <para>Кто что делал: команда <command>annotate</command>. - Эта команда показывает перед каждой строкой указанного файла (файлов) - имя пользователя, вносившего последние изменения в эту строку.</para> - - <screen>&prompt.user; <userinput>cvs annotate shazam</userinput></screen> - </listitem> - - <listitem> - <para>Добавление новых файлов: команда <command>add</command>.</para> - - <para>Создайте файл, выполните для него команду - <command>cvs add</command>, затем произведите запись в репозиторий - (коммит): <command>cvs commit</command>.</para> - - <para>Точно так же, новые каталоги добавляются в репозиторий путем - создания и последующего выполнения команды <command>cvs add</command>. - Заметьте, что выполнять коммит после добавления каталога не - надо.</para> - </listitem> - - <listitem> - <para>Удаление устаревших файлов: команда - <command>remove</command>.</para> - - <para>Удалите файл, затем выполните команду <command>cvs rm</command> - с его именем в качестве параметра, наконец, выполните для него - <command>cvs commit</command>.</para> - </listitem> - - <listitem> - <para>Внесение изменений в репозиторий: команда - <command>commit</command> или <command>checkin</command>.</para> - - <table frame="none"> - <title>Useful <command>cvs commit</command> options</title> - - <tgroup cols="2"> - <tbody> - <row> - <entry><option>-f</option></entry> - <entry>Форсировать внесение изменений для не модифицированного - файла.</entry> - </row> - - <row> - <entry><option>-m<replaceable>msg</replaceable></option></entry> - <entry>Указать сообщение для журнала в командной строке (не - запускать текстовый редактор).</entry> - </row> - </tbody> - </tgroup> - </table> - - <para>Опцию <option>-f</option> следует использовать, если вы поняли, - что забыли указать какую-либо важную информацию в журнале - изменений.</para> - - <para>Хорошие журнальные сообщения очень важны. Они дают возможность - другим узнать, зачем вы производили изменения, причем не только в - момент их произведения, но и месяцы или годы спустя, когда кто-либо - заинтересуется, почему выглядящий нелогично или неэффективно фрагмент - кода попал в каши исходные тексты. Кроме того, это очень помогает - в оценке того, нужно ли переносить соответствующий код в &os.stable; - (MFC).</para> - - <para>Сообщения должны быть ясными, краткими, четкими, и представлять - из себя разумную аннотацию, какие изменения были произведены и - почему.</para> - - <para>Сообщения должны достаточно ясно показывать сторонним - разработчикам, насколько их касаются изменения и нужно ли - им исследовать изменения подробно.</para> - - <para>Избегайте внесения нескольких не связанных друг с другом - изменений за один раз. Это затрудняет объединение изменений, - а также, при обнаружении ошибок, усложняет поиск ответственного - за ошибки участка.</para> - - <para>Избегайте смешивания в одном коммите изменений функциональности - со стилистическими правками или исправлениями в пробелах. - Это усложняет объединение, и, кроме того, затрудняет понимание того, - какие именно функциональные изменения были внесены. В случае коммита - в файлы документации, это затруднит работу групп поддержки перевода, - поскольку становится сложнее отделить изменения, требующие - перевода.</para> - - <para>Избегайте коммита большой группы файлов за один раз с одним - общим и невнятным сообщением. Напротив, вносите изменения в отдельные - файлы (или небольшие группы связанных файлов) с адекватными - сообщениями для журналирования.</para> - - <para>Перед коммитом, <emphasis>обязательно</emphasis>:</para> - - <itemizedlist> - <listitem> - <para>проверьте, что вы будете выполнять коммит в правильную ветвь, - посредством команды <command>cvs status</command>.</para> - </listitem> - - <listitem> - <para>проверьте ваши изменения при помощи команды - <command>cvs diff</command></para> - </listitem> - </itemizedlist> - - <para>Кроме того, ВСЕГДА указывайте, в какие именно файлы вы вносите - изменения, так чтобы не включить в этот список лишних файлов. - Команда <command>cvs commit</command> без аргументов включит - все измененные файлы в текущем каталоге и всех подкаталогах. - </para> - </listitem> - </orderedlist> - - <para>Еще несколько полезных советов:</para> - - <orderedlist> - <listitem> - - <para>Часто используемые опции можно занести в файл - <filename>~/.cvsrc</filename>, например:</para> - - <programlisting>cvs -z3 -diff -Nu -update -Pd -checkout -P</programlisting> - - <para>Для данного случая:</para> - - <itemizedlist> - <listitem> - <para>всегда использовать компрессию уровня 3 для связи с удаленным - сервером CVS. В случае медленного соединения это избавит вас от - лишней головной боли.</para> - </listitem> - - <listitem> - <para>всегда использовать опции <option>-N</option> (показывать - добавленные или удаленные файлы) и <option>-u</option> - (унифицированный формат) для &man.diff.1;.</para> - </listitem> - - <listitem> - <para>всегда использовать опции <option>-P</option> (удалять пустые - каталоги) и <option>-d</option> (добавлять новые каталоги) - при обновлении.</para> - </listitem> - - <listitem> - <para>всегда использовать опцию <option>-P</option> (удалять пустые - каталоги) при извлечении файлов и модулей.</para> - </listitem> - </itemizedlist> - </listitem> - - <listitem> - <para>Пользуйтесь скриптом Эйвинда Эклунда (Eivind Eklund) - <command>cdiff</command> для просмотра изменению унифицированного - формата. Он является оберткой для &man.less.1;, добавляющей - цветовые коды ANSI для выделения заголовком, добавленных и удаленных - строк; прочие строки не модифицируются. Помимо этого, скрипт - корректно разворачивает табуляции (которые часто выглядят неправильно - в изменениях из-за дополнительного символа в начале строки).</para> - - <para><package>textproc/cdiff</package></para> - - <para>Просто используйте его вместо &man.more.1; или &man.less.1;:</para> - - <screen>&prompt.user; <userinput>cvs diff -Nu shazam | cdiff</userinput></screen> - - <para>Помимо этого, некоторые текстовые редакторы, такие как &man.vim.1; - (<package>editors/vim</package>) поддерживают - цветовую синтаксическую разметку многих типов файлов, в том числе - файлов изменений и журналов CVS/RCS.</para> - - <screen>&prompt.user; <userinput>echo "syn on" >> ~/.vimrc </userinput> -&prompt.user; <userinput>cvs diff -Nu shazam | vim -</userinput> -&prompt.user; <userinput>cvs log shazam | vim -</userinput> </screen> - </listitem> - - <listitem> - <para>CVS — старая, загадочная и порой слабо предсказуемая - в своем поведении программа. <!-- XXX - exhibits non-deterministic behavior which some claim as proof - that it is actually merely the Newtonian manifestation of a - sentient transdimensional entity. --> - Ни один человек не способен удержать в голове все тонкости ее работы, - так что не бойтесь спрашивать совета у Искусственного Интеллекта - (а именно &a.cvsadm;).</para> - </listitem> - - <listitem> - <para>Не оставляйте компьютер в процессе работы команды - <command>cvs commit</command> (в редакторе при написании журнального - сообщения) слишком надолго (более чем на 2–3 минуты). Эта - команда блокирует каталог репозитория, в котором она запущена, и не - позволяет другим разработчикам изменять его содержимое. Если вам - нужно написать длинное журнальное сообщение, подготовьте его заранее - и вставьте в редакторе во время выполнения команды - <command>cvs commit</command>, либо запишите его в файл и используйте - опцию CVS <option>-F</option>:</para> - - <screen>&prompt.user; <userinput>vi logmsg</userinput> -&prompt.user; <userinput>cvs ci -F logmsg shazam</userinput></screen> - - <para>Это самый быстрый способ передать журнальное сообщение CVS; - однако, вы должны быть внимательны при редактировании файла - <filename>logmsg</filename>, поскольку при выполнении коммита - у вас не будет шансов его поправить.</para> - </listitem> - - <listitem> - <para>Вы можете существенно ускорить скорость работы CVS с центральным - репозиторием, используя постоянное соединение с репозиторием. - Для этого добавьте в файл <filename>~/.ssh/config</filename> строки - </para> - - <programlisting>Host ncvs.FreeBSD.org - ControlPath /home/<replaceable>user</replaceable>/.ssh/cvs.cpath -Host dcvs.FreeBSD.org - ControlPath /home/<replaceable>user</replaceable>/.ssh/cvs.cpath -Host projcvs.FreeBSD.org - ControlPath /home/<replaceable>user</replaceable>/.ssh/cvs.cpath -Host pcvs.FreeBSD.org - ControlPath /home/<replaceable>user</replaceable>/.ssh/cvs.cpath</programlisting> - - <para>Затем откройте постоянное соединение с машиной repoman:</para> - - <screen>&prompt.user; <userinput>ssh -fNM ncvs.FreeBSD.org</userinput></screen> - - <para>Теперь команды CVS должны выполняться быстрее, поскольку - используют существующее соединение с репозиторием. Учтите, что - регистр в именах хостов имеет значение.</para> - - </listitem> - - </orderedlist> - - </sect1> - - <sect1 xml:id="conventions"> - <title>Соглашения и традиции</title> - - <para>Став коммиттером, вы должны прежде всего произвести некоторые - стандартные действия.</para> - - <itemizedlist> - <listitem> - <para>Добавьте себя в список <quote>SGML сущностей</quote> авторов - в файл - <filename>doc/en_US.ISO8859-1/share/xml/authors.ent</filename>; - это изменение должно быть сделано прежде прочих, поскольку в - противном случае следующий ваш коммит неизбежно разрушит - процесс построения дерева doc/.</para> - - <para>Это довольно простая задача, но при этом она является неплохим - первым тестом ваших навыков работы с CVS.</para> - </listitem> - - <listitem> - <para>Также добавьте свою <quote>SGML сущность</quote> в - <filename>www/en/developers.xml</filename>.</para> - </listitem> - - <listitem> - <para>Добавьте себя в раздел <quote>Разработчики</quote> статьи - <link xlink:href="&url.articles.contributors;/index.html">Участники проекта - FreeBSD</link> - (<filename>doc/en_US.ISO8859-1/articles/contributors/contrib.committers.xml</filename>) - и удалите свою запись из раздела <quote>Прочие участники</quote> - (<filename>doc/en_US.ISO8859-1/articles/contributors/contrib.additional.xml</filename>).</para> - </listitem> - - <listitem> - <para>Добавьте новость о новом коммиттере в файл - <filename>www/share/xml/news.xml</filename>. Используйте существующие - записи вида <quote>Новый коммиттер</quote> как шаблон.</para> - </listitem> - - <listitem> - <para>Вам нужно добавить ваш PGP или GnuPG ключ в каталог - <filename>doc/share/pgpkeys</filename> (а если у вас нет ключа, - вам нужно его создать). Не забудьте изменить и произвести коммит - в файл <filename>doc/share/pgpkeys/pgpkeys.ent</filename>.</para> - - <para>&a.des.email; написал скрипт для упрощения этого процесса. - Дополнительную информацию можно прочесть в файле <link xlink:href="http://cvsweb.FreeBSD.org/doc/share/pgpkeys/README">README</link>.</para> - - <note> - <para>Очень важно, чтобы в Руководстве пользователя был записан - актуальный PGP/GnuPG ключ, поскольку он может потребоваться - для идентификации коммиттера (например, его будет проверять группа - &a.admins; для аварийного восстановления учетной записи). Полный - набор актуальных ключей пользователей домена <systemitem class="fqdomainname">FreeBSD.org</systemitem> можно найти по адресу <link xlink:href="&url.base;/doc/pgpkeyring.txt">http://www.FreeBSD.org/doc/pgpkeyring.txt</link>.</para> - </note> - </listitem> - - <listitem> - <para>Добавьте себя в файл <filename>src/share/misc/committers-<replaceable>репозиторий</replaceable>.dot</filename>, - где репозиторием будет являться либо doc, либо ports, либо src в зависимости от полученных вами коммиттерских - привилегий.</para> - </listitem> - - <listitem> - <para>Некоторые коммиттеры добавляют информацию о своем местоположении - в файл - <filename>ports/astro/xearth/files/freebsd.committers.markers</filename>.</para> - </listitem> - - <listitem> - <para>Некоторые добавляют данные о дне своего рождения в файл - <filename>src/usr.bin/calendar/calendars/calendar.freebsd</filename>.</para> - </listitem> - - <listitem> - <para>Представьтесь другим коммиттерам, иначе никто не будет знать, - кто вы и чем занимаетесь. От вас не требуется писать подробное - резюме или биографию: будут достаточны один-два абзаца о себе и - областях FreeBSD, в которых вы планируете работать. Пошлите это - письмо в &a.developers; — и все!</para> - </listitem> - - <listitem> - <para>Зайдите на машину <systemitem>hub.FreeBSD.org</systemitem> и создайте - файл <filename>/var/forward/<replaceable>user</replaceable></filename> - (замените <replaceable>user</replaceable> на ваше имя пользователя). - Этот файл должен содержать адрес электронной почты, на который - будет переправляться вся почта на адрес - <replaceable>yourusername</replaceable>@FreeBSD.org, в том числе - сообщения о коммитах и другая почта на адреса &a.committers; и - &a.developers;. Слишком большие почтовые ящики на машине - <systemitem>hub</systemitem> могут быть <quote>нечаянно</quote> удалены - или обрезаны без предупреждения, так что, чтобы не потерять почту, - регулярно читайте ее либо перенаправьте куда-нибудь еще.</para> - - <para>Из-за ощутимой загрузки, возникающей на серверах, обрабатывающих - списки рассылки, из-за большого количества незапрошенной почты - (спама), сервер, принимающий почту для домена FreeBSD.org, - производит некоторые основные проверки и на основании их отвергает - некоторые письма. На настоящий момент единственным проверяемым - параметром является корректность информации DNS для хоста, - доставляющего почту, но в будущем список может вырасти. Эти - проверки временами обвиняют в том, что они отвергают правильную - почту. Если вы хотите отключить проверки для своего адреса, - создайте файл <filename>~/.spam_lover</filename> в своей - домашней директории на машине - <systemitem class="fqdomainname">freefall.FreeBSD.org</systemitem>.</para> - </listitem> - - <listitem> - <para>Если вы были подписаны на &a.cvsall;, вам, скорее всего, - следует отписаться от него, чтобы не получать дубликатов - каждого сообщения о коммитах.</para> - </listitem> - </itemizedlist> - - <para>Все новые коммиттеры первоначально работают под руководством - ментора. Ваш ментор отвечает за обучение вас правилам и соглашениям, - принятым в проекте, и помогает вам сделать первые шаги в среде - коммиттеров. Он(а) также персонально отвечает за ваши действия - в этот начальный период. До тех пор, пока ваш ментор не решит - (и не анонсирует это посредством форсированного коммита файла - <filename>access</filename>), что вы достаточно освоились и готовы - работать самостоятельно, перед любым коммитом вы должны получить - одобрение (approval) ментора и указать это в журнальном сообщении - коммита строкой <literal>Approved by:</literal>.</para> - - <para>Все коммиты в дерево <filename>src</filename> сначала должны - производиться в ветвь &os.current; и лишь затем интегрироваться - в &os.stable;. Никакие серьезные изменения, новые возможности - или рискованные модификации не должны производиться напрямую - в ветви &os.stable;.</para> - </sect1> - - <sect1 xml:id="pref-license"> - <title>Предпочтительная лицензия для новых файлов</title> - - <para>В настоящее время Проект &os; считает предпочтительной формой - лицензии на исходные тексты следующий текст:</para> - -<programlisting>/*- -* 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] -*/</programlisting> - -<!-- XXX дать перевод *вместе* с оригинальным английским текстом --> - - <para>Проект &os; крайне не рекомендует так называемый <quote>третий - пункт</quote>, или <quote>пункт о рекламе</quote> в лицензии на новый - исходный код. В связи с большим количеством участников проекта &os;, - выполнение этого пункта большинством коммерческих производителей все - более затруднительно. Если ваш код в дереве исходников содержит - <quote>пункт о рекламе</quote>, рассмотрите возможность его удаления. - На самом деле, рассмотрите возможность перехода на приведенную - лицензию.</para> - - <para>Проект &os; не рекомендует использование полностью новых лицензий - или вариаций стандартных лицензий. Новые лицензии перед использованием - в репозитории проекта требуют утверждения группой - <email>core@FreeBSD.org</email>. Большое число различных лицензий - затрудняет использование кода, в основном из-за ненамеренных - неверных выводов из плохо сформулированных формулировок лицензии.</para> - - <para>Политика проекта требует, чтобы код под НЕ-BSD лицензиями располaгался - только в определённых местах репозитория, а в некоторых случаях компиляция - должна быть условной по умолчанию или вообще отключена. К примеру, ядро - GENERIC должно состоять только из лицензий идентичных или в значительной степени - схожих с BSD лицензией. Программное обеспечение под лицензиями GPL, APSL, CDDL - и др. не должно включаться в состав GENERIC.</para> - - <para>Разработчикам напоминается, что в open source правильное понимание "open" - также важно, как правильное понимание "source", ибо некорректное использование - интеллектуальной собственности имеет серьезные последствия. Какие-либо вопросы - или беспокойства на этот счёт должны быть немедленно вынесены на обсуждение - главной команде разработчиков (core team).</para> - - </sect1> - - <sect1 xml:id="developer.relations"> - <title>Взаимодействие между разработчиками</title> - - <para>Если вы работаете над собственным исходным кодом, либо в области, - в которой вы уже определены как ответственная персона, вам, скорее всего, - не потребуется согласовывать коммит с кем-либо еще из разработчиков. - Те же правила действуют, если вы нашли ошибку в той части системы, - которой явно давно никто не занимается (к нашему стыду, существует - несколько таких областей). Если же вы собираетесь модифицировать - что-либо активно поддерживаемое (по-хорошему, узнать это можно только - исследуя архивы списка рассылки <literal>cvs-committers</literal>), - стоит послать предполагаемый патч ответственному за этот участок кода, - как вы бы поступали, пока не были коммиттером. В случае портов нужно - обращаться по адресу, указанному в строке <varname>MAINTAINER</varname> - в файле <filename>Makefile</filename>. Для других частей репозитория, - в случае если вам не очевидно, кто ведет данный участок кода, может - помочь исследование вывода команды <command>cvs log</command>. - &a.fenner.email; написал отличный скрипт для определения разработчиков, - наиболее активно производивших коммиты, выводящий для каждого из - указанных файлов имя пользователя вместе с количеством произведенных - им коммитов в данный файл. Скрипт можно найти на машине - <systemitem>freefall</systemitem> в файле <filename>~fenner/bin/whodid</filename>. - Если найденная вами персона не отвечает на ваши вопросы или иным образом - демонстрирует отсутствие интереса к проблеме, смело производите коммит - самостоятельно.</para> - - <para>Если вы по каким-либо причинам не уверены в своих изменениях, - предложите их для оценки в списке рассылки <literal>-hackers</literal> - перед коммитом. Будет лучше, если вас обругают там и тогда, чем - когда предлагаемое изменение уже будет частью репозитория. Если - случилось так, что ваш коммит встретил сопротивление, возможно, - стоит его откатить (back out) до тех пор, пока не будет достигнут - консенсус. Помните — с помощью CVS всегда можно вернуться - к предыдущему состоянию.</para> - - <para>Не принимайте в штыки мнения других разработчиков, с которыми вы не - согласны. Если они предлагают иное решение проблемы чем вы, или даже - иначе воспринимают проблему, это не значит, что они глупы, имеют - сомнительное происхождение, хотят разрушить вашу работу, очернить - ваше доброе имя, или развалить проект FreeBSD. Просто они смотрят на - мир под иным углом. Различные взгляды — благо.</para> - - <para>Будьте честны в спорах. Оценивайте свою позицию по заслугам, честно - относитесь к ее слабым сторонам и будьте готовы принять другие точки - зрения и пути решения. Будьте открыты.</para> - - <para>Будьте терпимы, если вас поправляют. Все мы совершаем ошибки. - Если вы ошиблись, извинитесь. Не обвиняйте ни себя, ни, тем более, - других в ошибке. Не теряйте времени на смущение или упреки, просто - исправьте ошибку и двигайтесь дальше.</para> - - <para>Спрашивайте и просите о помощи. Предлагайте ваши изменения для - рассмотрения коллегам и рассматривайте их изменения. Одним из - преимуществ программного обеспечения с открытыми исходными текстами - является открытость разработки. Если никто не будет исследовать - чужой код, это преимущество исчезнет.</para> - - </sect1> - - <sect1 xml:id="gnats"> - <title>GNATS</title> - - <para>Для отслеживания ошибок и запросов на изменения проект FreeBSD - использует <application>GNATS</application>. Если вы исправили ошибку - или внесли изменения, описанные в одном из сообщений об ошибках (PR), - не забудьте закрыть это сообщение, используя команду - <command>edit-pr <replaceable>pr-number</replaceable></command> на машине - <systemitem>freefall</systemitem>. Хорошо будет, если вы потратите немного - времени на поиск и закрытие других PR по этой теме. Вы и сами можете - пользоваться &man.send-pr.1; для предложения изменений, которые, по - вашему мнению, могут потребовать более подробного обсуждения с - коллегами.</para> - - <para>Более подробно о <application>GNATS</application> можно прочитать - по адресам:</para> - - <itemizedlist> - <listitem> - <para><uri xlink:href="http://www.cs.utah.edu/csinfo/texinfo/gnats/gnats.html">http://www.cs.utah.edu/csinfo/texinfo/gnats/gnats.html</uri></para> - </listitem> - - <listitem> - <para><link xlink:href="&url.base;/support.html">http://www.FreeBSD.org/support.html</link></para> - </listitem> - - <listitem> - <para>&man.send-pr.1;</para> - </listitem> - </itemizedlist> - - <para>Вы можете пользоваться локальной копией GNATS, поддерживая ее - синхронность при помощи CVSup. При этом вы можете использовать - команды GNATS локально, а также пользоваться другими интерфейсами, - такими как <command>tkgnats</command>, что позволит вам работать с - базой сообщений об ошибках без соединения с Интернет.</para> - - <procedure> - <title>Использование локальной копии GNATS</title> - - <step> - <para>Если вы еще не поддерживаете зеркало дерева GNATS, добавьте в ваш - <filename>supfile</filename> строку</para> - - <programlisting>gnats release=current prefix=/usr</programlisting> - - <para>Учтите, что эта строка должна предшествовать любым строкам, - содержащим параметр <quote>tag=</quote>, поскольку дерево GNATS не - находится под управлением CVS и не имеет символьных меток.</para> - - <para>После запуска cvsup в каталоге <filename>/usr/gnats</filename> - будет создана копия дерева GNATS FreeBSD. Вы можете использовать - файл <emphasis>refuse</emphasis> для копирования отдельных категорий. - Например, если вас интересуют только сообщения категории - <literal>docs</literal>, добавьте в файл - <filename>/usr/local/etc/cvsup/sup/refuse</filename><footnote> - <para>Точный путь к файлу зависит от установок <literal>*default - base</literal> в вашем файле - <filename>supfile</filename>.</para> - </footnote> строку</para> - - <programlisting>gnats/[a-ce-z]*</programlisting> - - <para>Прочие примеры в этом разделе подразумевают, что вы - синхронизируете только категорию <literal>docs</literal>.</para> - </step> - - <step> - <para>Установите порт GNATS из - <filename>ports/databases/gnats</filename>. После установки вы - обнаружите различные служебные каталоги в дереве - <filename>$PREFIX/share/gnats</filename>.</para> - </step> - - <step> - <para>Создайте символьные ссылки на синхронизированные каталоги GNATS - в служебный каталог GNATS:</para> - - <screen>&prompt.root; <userinput>cd /usr/local/share/gnats/gnats-db</userinput> -&prompt.root; <userinput>ln -s /usr/gnats/docs</userinput></screen> - - <para>Проделайте эту операцию для всех синхронизируемых категорий.</para> - </step> - - <step> - <para>Обновите служебный файл GNATS <filename>categories</filename>, - расположенный в каталоге - <filename>$PREFIX/share/gnats/gnats-db/gnats-adm</filename>:</para> - - <programlisting># This category is mandatory -pending:Category for faulty PRs:gnats-admin: -# -# FreeBSD categories -# -docs:Documentation Bug:freebsd-doc:</programlisting> - </step> - - <step> - <para>Запустите <filename>$PREFIX/libexec/gnats/gen-index</filename> - для создания индекса. Вывод этой команды должен быть перенаправлен - в файл - <filename>$PREFIX/share/gnats/gnats-db/gnats-adm/index</filename>. - Эту операцию можно выполнять периодически при помощи &man.cron.8; - или запускать &man.cvsup.1; из скрипта, который затем сгенерирует - новый индекс:</para> - - <screen>&prompt.root; <userinput>/usr/local/libexec/gnats/gen-index \ - > /usr/local/share/gnats/gnats-db/gnats-adm/index</userinput></screen> - </step> - - <step> - <para>Протестируйте созданную конфигурацию запросом к базе данных - GNATS. Следующая команда выведет список открытых сообщений об - ошибках в категории <literal>docs</literal>:</para> - - <screen>&prompt.root; <userinput>query-pr -c docs -s open</userinput></screen> - - <para>Другие интерфейсы, например, порт - <package>databases/tkgnats</package> также должны - работать.</para> - </step> - - <step> - <para>Выберите PR и закройте его.</para> - </step> - </procedure> - - <note> - <para>Описанная процедура позволяет вам выбирать и просматривать - сообщения об ошибках локально. Для редактирования или закрытия вам - потребуется зайти на машину <systemitem>freefall</systemitem>.</para> - </note> - </sect1> - - <sect1 xml:id="people"> - <title>Кто есть кто</title> - - <para>Помимо мастеров репозитория, существует еще несколько участников и - групп проекта FreeBSD, с которыми вам как коммиттеру может потребоваться - общаться. Краткий и ни в коем случае не полный список приводится ниже. - </para> - - <variablelist> - - <varlistentry> - <term>&a.jhb.email;</term> - - <listitem> - <para>Джон возглавляет проект SMPng и отвечает за архитектуру, - дизайн и реализацию перехода на многонитевое ядро. Джон также - является редактором статьи "Архитектура SMPng". Если вы работаете - с тонкими блокировками многопроцессорного ядра, координируйте свою - работу с Джоном.</para> - </listitem> - </varlistentry> - - <varlistentry> - <term>&a.doceng;</term> - - <listitem> - <para>doceng — группа, отвечающая за инфраструктуру - построения документации, прием новых коммиттеров документации и - актуальность информации относительно CVS на веб-сайте и FTP-сайте - FreeBSD. Эта группа не разбирает конфликты. Большая часть - обсуждений, связанных с документацией, происходит в &a.doc;. - Дополнительную информацию о деятельности группы можно найти в ее - <link xlink:href="http://www.FreeBSD.org/internal/doceng.html">собственном - документе</link>. - Коммиттеры, заинтересованные в обновлении документации, должны - ознакомиться с <link xlink:href="&url.books.fdp-primer;/index.html">Учебником по Проекту - Документирования FreeBSD для новых участников</link>.</para> - </listitem> - </varlistentry> - - <varlistentry> - <term>&a.ru.email;</term> - - <listitem> - <para>Руслан великолепно знает тонкости &man.mdoc.7;. Если вы - пишете справочную страницу и нуждаетесь в совете по ее структуре - или разметке, обратитесь к Руслану.</para> - </listitem> - </varlistentry> - - <varlistentry> - <term>&a.bde.email;</term> - - <listitem> - <para>Брюс занимается общим стилем кода проекта. Если ваш коммит - мог бы быть лучше оформлен, Брюс укажет вам на это. Радуйтесь, - что такой человек вообще есть. Брюс также является знатоком - различных стандартов, применимых к FreeBSD.</para> - </listitem> - </varlistentry> - - <varlistentry> - <term>&a.murray.email;</term> - <term>&a.dwhite.email;</term> - <term>&a.rwatson.email;</term> - <term>&a.kensmith.email;</term> - <term>&a.hrs.email;</term> - <term>&a.mux.email;</term> - <term>&a.bmah.email;</term> - - <listitem> - <para>Таков состав группы &a.re;. Эта группа отвечает за сроки - и процесс выпуска релизов. В период заморозки кода, выпускающие - инженеры принимают окончательные решения по поводу всех изменений - системы в ветви, готовящейся к очередному релизу. Если вы хотите - интегрировать какие-либо изменения из &os.current; в - &os.stable; (какими бы они ни были в данный конкретный момент), - вам предстоит общаться с этой группой.</para> - - <para>Хироки, кроме того, ведет раздел документации к релизам - (<filename>src/release/doc/*</filename>). Если ваши изменения - стоят того, чтобы быть упомянутыми в информации о релизе, - сообщите об этом Хироки. Еще лучше, если вы пошлете патч - с предлагаемыми изменениями к документу.</para> - </listitem> - </varlistentry> - - <varlistentry> - <term>&a.cperciva.email;</term> - - <listitem> - <para>Колин — - <link xlink:href="&url.base;/security/">FreeBSD Security - Officer</link> - и отвечает за деятельность группы &a.security-officer;. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>&a.wollman.email;</term> - - <listitem> - <para>Если вам нужен совет по поводу темных мест сетевой части ядра, - или вы не уверены в планируемом изменении сетевой подсистемы, - мудрым решением будет обратиться к Гарретту. Помимо того, он - хорошо разбирается в различных стандартах, применимых к - FreeBSD.</para> - </listitem> - </varlistentry> - - <varlistentry> - <term>&a.committers;</term> - - <listitem> - <para>cvs-committers — адрес, используемый CVS для посылки - сообщений о коммитах. Вы <emphasis>никогда</emphasis> не должны - посылать письма напрямую на этот адрес; следует лишь отвечать на - него, когда вам нужно послать короткие комментарии, непосредственно - относящиеся к коммиту.</para> - </listitem> - </varlistentry> - - <varlistentry> - <term>&a.developers;</term> - - <listitem> - <para>Все коммиттеры подписаны на список рассылки -developers. - Этот список создан для обсуждения вопросов, касающихся - <quote>сообщества</quote> коммиттеров FreeBSD, таких как выборы - Правления, анонсы и т.п.</para> - - <para>&a.developers; служит для только для использования FreeBSD - коммиттерами. Коммиттеры должны иметь возможность публично - обсуждать вещи, которые должны быть разрешены, перед тем, как - они будут публично объявлены. Данные дискуссии - не предназначены для широкой публики и могут нанести вред - FreeBSD.</para> - - <para>Все FreeBSD коммиттеры должны соблюдать авторские права - оригинального автора или авторов писем из этого списка рассылки. Не - публикуйте и не пересылайте сообщения из &a.developers; вне - подписчиков данного списка рассылки без согласия всех авторов.</para> - - <para>Нарушители авторских прав будут удалены из списка - подписчиков &a.developers;, и будут приостановлены их коммиттерские - привилегии. Повторяющиеся или вопиющие нарушения приведут к - полному лишению коммиттерских прав.</para> - - <para>Этот список <emphasis>не</emphasis> - предназначен для обсуждения кода, и <emphasis>не - является</emphasis> заменой списков &a.arch; или &a.audit;. - На самом деле, такое его использование вредит проекту, поскольку - открытые обсуждения вопросов, касающихся всего сообщества - пользователей FreeBSD в закрытом списке недопустимы. И, наконец: - <emphasis>никогда, действительно никогда не пишите в &a.developers; - с копией в другой список рассылки FreeBSD</emphasis>. Никогда не - пишите в какой-либо другой список рассылки с копией в - &a.developers;. Подобные действия серьезно подрывают смысл - существования данного списка рассылки.</para> - </listitem> - </varlistentry> - </variablelist> - </sect1> - - <sect1 xml:id="ssh.guide"> - <title>SSH: быстрый старт</title> - - <procedure> - <step> - <para>Если вы используете FreeBSD версии 4.0 или более позднюю, - OpenSSH включен в базовую поставку системы. Для более ранних версий - обновите и установите OpenSSH из порта - <package>security/openssh</package>.</para> - </step> - - <step> - <para>Для тех, кто не хочет набирать свой пароль каждый раз при - использовании &man.ssh.1; и использует для авторизации ключи - RSA или DSA, удобной будет утилита &man.ssh-agent.1;. Если вы - собираетесь использовать ее, убедитесь, что она запущена раньше - прочих приложений. Пользователи X Window, например, обычно - запускают ее из файлов <filename>.xsession</filename> или - <filename>.xinitrc</filename>. Подробнее смотрите в справочной - странице &man.ssh-agent.1;.</para> - </step> - - <step> - <para>Создайте пару ключей при помощи &man.ssh-keygen.1;. Ключи - появятся в каталоге - <filename>$HOME/.ssh/</filename>.</para> - </step> - - <step> - <para>Пошлите ваш публичный ключ (содержимое файла - <filename>$HOME/.ssh/id_dsa.pub</filename> - или <filename>$HOME/.ssh/id_rsa.pub</filename>) - вашему будущему ментору, чтобы он мог быть помещен в файл - <filename><replaceable>yourlogin</replaceable></filename> в каталоге - <filename>/c/ssh-keys/</filename> на машине - <systemitem>freefall</systemitem>. - </para> - </step> - </procedure> - - <para>Теперь вы можете пользоваться утилитой &man.ssh-add.1; для - авторизации один раз за сессию. Утилита запросит кодовую фразу - для вашего секретного ключа и затем сохранит ее в агенте авторизации - (&man.ssh-agent.1;). Если вы хотите удалить сохраненный секретный - ключ из агента, используйте команду <command>ssh-add -d</command>.</para> - - <para>Для теста используйте команду типа <command>ssh - freefall.FreeBSD.org ls /usr</command>.</para> - - <para>За дополнительной информацией обращайтесь к - <package>security/openssh</package>, &man.ssh.1;, - &man.ssh-add.1;, &man.ssh-agent.1;, &man.ssh-keygen.1; и - &man.scp.1;.</para> - </sect1> - - <sect1 xml:id="rules"> - <title>Большой Список Правил Коммиттера FreeBSD</title> - - <orderedlist> - <listitem> - <para>Уважайте других коммиттеров.</para> - </listitem> - - <listitem> - <para>Уважайте других участников проекта.</para> - </listitem> - - <listitem> - <para>Обсудите любые значимые изменения - <emphasis>до</emphasis> коммита.</para> - </listitem> - - <listitem> - <para>Уважайте существующих мейнтейнеров (указанных в поле - <varname>MAINTAINER</varname> файлов <filename>Makefile</filename> - или в файле <filename>MAINTAINER</filename> в корневом каталоге - репозитория).</para> - </listitem> - - <listitem> - <para>Любое спорное изменение необходимо откатить (back out) в ожидании - решения, если того требует мейнтейнер. Вопросы безопасности могут - перекрывать мнение мейнтейнера, если так решит Security Officer. - </para> - </listitem> - - <listitem> - <para>Изменения вносятся в ветвь &os.current; до &os.stable;, за - исключением случаев, прямо разрешенных выпускающими инженерами или - неприменимости изменения к &os.current;. Любое нетривиальное и - не срочное изменение должно быть выдержано в &os.current; в течение - по крайней мере 3 дней перед переносом, чтобы его могли адекватно - протестировать. Выпускающие инженеры обладают той же властью в - ветви &os.stable;, что и мейнтейнеры (см. правило 5).</para> - </listitem> - - <listitem> - <para>Не пререкайтесь с другими коммиттерами публично: это дурно - выглядит. Если вам необходимо с чем-либо <quote>категорически не - согласиться</quote>, делайте это личной почтой.</para> - </listitem> - - <listitem> - <para>Соблюдайте все периоды заморозки кода (core freeze), а также - своевременно читайте списки рассылки <literal>committers</literal> и - <literal>developers</literal>, чтобы быть в курсе расписания таких - периодов.</para> - </listitem> - - <listitem> - <para>Если вы сомневаетесь в какой-либо процедуре, сначала - спросите!</para> - </listitem> - - <listitem> - <para>Тестируйте свои изменения перед коммитом.</para> - </listitem> - - <listitem> - <para>Не производите коммит в деревья - <filename>src/contrib</filename>, - <filename>src/crypto</filename> и - <filename>src/sys/contrib</filename> без - <emphasis>прямого</emphasis> разрешения (approval) соответствующего - мейнтейнера(ов).</para> - </listitem> - </orderedlist> - - <para>Невыполнение этих правил может служить основанием для приостановки - или, в случае рецидивов, полного лишения коммиттерских прав. Члены - Правления (Core) имеют право временно приостановить права коммиттера - до момента, когда Правление в целом сможет решить вопрос. - В <quote>аварийном</quote> случае (коммиттер разрушает репозиторий) - такие права имеют также ответственные за репозиторий. Для приостановки - прав коммиттера более чем на неделю или для полного лишения таковых прав - требуется квалифицированное большинство (2/3) голосов Правления. Это - правило существует не потому, что Правление состоит из злобных - диктаторов, разбрасывающихся коммиттерами словно банками из-под колы, - но ради предоставления проекту аварийного выключателя. Если кто-то - выходит из-под контроля, важно иметь возможность справиться с ситуацией - немедленно, а не быть втянутыми в дебаты. В любом случае, коммиттер, - чьи права приостановлены, имеет право на <quote>слушания - Правления</quote>, на которых определяется срок приостановки или - лишения коммиттерских прав. Коммиттер, права которого приостановлены - может запросить пересмотр своего вопроса через 30 дней и каждые - последующие 30 дней (если общий период приостановки превышает 30 дней). - Коммиттер, полностью лишенный прав, может запросить пересмотр по - истечении 6 месяцев. Правила пересмотра являются <emphasis>полностью - неформальными</emphasis> и во всех случаях Правление имеет право - отвергнуть запрос на пересмотр, если считает свое первоначальное решение - верным.</para> - - <para>Во всех прочих аспектах деятельности проекта, Правление является - подмножеством коммиттеров и ограничено <emphasis>теми же - правилами</emphasis>. Само по себе членство в Правлении не дает права - преступать описанные правила. Правление обладает <quote>особой - силой</quote> только в случае деятельность как целое, а не на - индивидуальной основе. Члены Правления — в первую очередь - коммиттеры.</para> - - <sect2> - <title>Подробности</title> - - <orderedlist> - <listitem xml:id="respect"> - <para>Уважайте других коммиттеров.</para> - - <para>Вы должны относиться к другим коммиттерам как к коллегам по - разработке (кем они и являются). Несмотря на возникающие временами - попытки утверждать обратное, никто не стал коммиттером по своей или - чьей-либо еще глупости, и мало что обижает сильнее, чем подобные - обвинения от коллег. Вне зависимости от того, всегда ли мы - чувствуем уважение друг к другу или нет (у каждого бывают не лучшие - дни), мы всегда должны <emphasis>выказывать</emphasis> уважение к - другим коммиттерам, как в публичных форумах, так и в личной почте. - </para> - - <para>Способность совместной работы в течение длительного - времени — одно из главных достижений проекта, много - более важное, чем любой набор изменений в коде, и никакие аргументы - относительно кода не стоят потерь в возможности гармонично работать - вместе.</para> - - <para>Чтобы не противоречить этому правилу, никогда не посылайте - писем, когда вы злы или каким-либо иным образом можете - спровоцировать других на конфронтацию. Сначала успокойтесь, - затем подумайте о том, как наиболее эффективно убедить оппонента(ов) - в правильности ваших аргументов; не подливайте масла в огонь ради - краткого мига злорадства, если ценой будет долгая ругань. - Это не просто крайне <quote>энергетически неэффективно</quote>: - повторяющиеся прецеденты публичной агрессии, влияющие на нашу - способность работать вместе, будут всерьез рассмотрены лидерами - проекта, и могут привести к приостановке или потере прав - коммиттера. Во внимание будут приниматься как публичные - высказывания, так и личная переписка; это не означает, что Правление - будет требовать раскрытия тайны переписки, однако, все - предоставленные затронутыми коммиттерами материалы будут - рассмотрены.</para> - - <para>Описанные процедуры никого не могут порадовать даже в малом, - однако <quote>целостность проекта превыше всего</quote>. Никакой - объем кода не стоит потери целостности.</para> - </listitem> - - <listitem> - <para>Уважайте других участников проекта.</para> - - <para>Вы не всегда были коммиттером. В свое время вы были простым - сторонним участником (contributor). Помните об этом все время. - Помните, сколь важно было добиться внимания и помощи. Не забывайте, - насколько ваше участие было важным для вас. Помните свои ощущения. - Не препятствуйте другим участникам и не унижайте их. Относитесь к - ним с уважением. Возможно, они наши будущие коммиттеры, и они - настолько же важны для проекта, как и коммиттеры. Их вклад в - проект настолько же ценен и важен, как и ваш. В конце концов, - вам пришлось приложить немало усилий для проекта, чтобы стать - коммиттером. Всегда помните об этом.</para> - - <para>Обдумайте первое правило <xref linkend="respect"/> и применяйте - его и к другим участникам проекта.</para> - </listitem> - - <listitem> - <para>Обсудите любые значимые изменения - <emphasis>до</emphasis> коммита.</para> - - <para>Репозиторий CVS — не место для анонса изменений или - обсуждения их. Все изменения должны обсуждаться в списках - рассылки, и лишь после достижения консенсуса вносится в - репозиторий. Это не означает, что вы должны спрашивать разрешения - на исправление очевидной синтаксической ошибки в коде или опечатки - в странице справочника. Вы должны ощутить, когда предполагаемое - изменение требует предварительного обсуждения и обратной связи. - Как правило, никто не станет возражать против обширных изменений, - если результат очевидно лучше предыдущего состояния, однако - никто не любит, когда эти изменения <emphasis>неожиданны</emphasis>. - Лучший способ убедиться, что вы на правильном пути — - дать ваш код просмотреть кому-либо еще из коммиттеров.</para> - - <para>Если вы сомневаетесь, просите отзыва!</para> - </listitem> - - <listitem> - <para>Уважайте существующих мейнтейнеров.</para> - - <para>Многие части кода FreeBSD не являются чьей-либо - <quote>собственностью</quote>: ситуация, когда некто подпрыгнет - и завопит, если вы внесете изменения в <quote>его</quote> код, - редка; однако, всегда стоит предварительно проверить. Одним из - используемых соглашений было добавление строки MAINTAINER в файл - <filename>Makefile</filename> пакета или части дерева, которая - активно поддерживается одним или несколькими коммиттерами; см. - также соответствующий раздел <link xlink:href="&url.books.developers-handbook;/policies.html"> - http://www.FreeBSD.org/doc/ru_RU.KOI8-R/books/developers-handbook/policies.html</link>. - В случае, если какой-то участок системы - имеет несколько мейнтейнеров, изменение его одним из них должно - быть одобрено по крайней мере одним из других. В случаях, когда - <quote>принадлежность</quote> кода неясна, вы можете взглянуть - на историю коммитов, чтобы понять, кто наиболее активно либо в - последнее время работал в этой области.</para> - - <para>Отдельные области FreeBSD попадают под контроль коммиттеров, - занимающихся поддержкой целых категорий на пути эволюции FreeBSD, - таких как локализация или сетевая подсистема. Для дополнительной - информации смотрите <link xlink:href="&url.articles.contributors;/staff-who.html"> - http://www.FreeBSD.org/doc/en_US.ISO8859-1/articles/contributors/staff-who.html</link> - </para> - </listitem> - - <listitem> - <para>Любое спорное изменение необходимо откатить в ожидании - решения, если того требует мейнтейнер. Вопросы безопасности могут - перекрывать мнение мейнтейнера, если так решит Security Officer. - </para> - - <para>Это может быть нелегко, особенно в период конфликта (когда - каждый участник уверен, что прав именно он). К счастью, CVS - дает возможность, вместо того чтобы вести бушующую перебранку, - просто откатить внесенные изменения, успокоиться всем участникам - конфликта, а затем попробовать найти взаимоприемлемый путь. - Если в конце концов окажется, что изменение стоит того, оно - может быть легко применено вновь. В противном случае, - пользователям не придется жить с неправильным состоянием дерева - исходных текстов, пока стороны заняты выяснением отношений. - Запросы на откаты возникают <emphasis>крайне</emphasis> редко, поскольку обсуждение обычно - выявляет неверные или спорные моменты до коммита; однако, если - такой запрос все же возник, он должен быть безусловно удовлетворен, - чтобы мы могли спокойно выяснить, было изменение неверным или - нет.</para> - </listitem> - - <listitem> - <para>Изменения вносятся в ветвь &os.current; до &os.stable;, за - исключением случаев, прямо разрешенных выпускающими инженерами или - неприменимости изменения к &os.current;. Любое нетривиальное и - не срочное изменение должно быть выдержано в &os.current; в течение - по крайней мере 3 дней перед переносом, чтобы его могли адекватно - протестировать. Выпускающие инженеры обладают той же властью в - ветви &os.stable;, что и мейнтейнеры (см. правило 5).</para> - - <para>Это еще одно <quote>не обсуждаемое</quote> правило: выпускающий - инженер безусловно отвечает за последствия, если выясняется что - внесенные изменения неверны. Уважайте эти права, и помогайте - группе выпуска релизов в работе с ветвью &os.stable;. На первый - взгляд может показаться, что ветвь &os.stable; развивается - чересчур консервативно. Не забывайте, однако, что разумный - консерватизм — отличительное свойство &os.stable;, - и что эта ветвь развивается по законам, отличным от законов - &os.current;. Кроме того, нет смысла тестировать изменения в - &os.current;, если они немедленно переносятся в &os.stable;. - Разработчики &os.current; должны иметь возможность протестировать - внесенные изменения, так что оставьте время для такого - тестирования, если только речь не идет о критическом исправлении - или о чем-либо очевидно не требующем тестирования (например, - исправления опечаток в страницах справочника, очевидных ошибок или - опечаток в исходных текстах и т.п.) Иными словами, исходите из - соображений здравого смысла.</para> - - <para>Изменения в ветви поддержки безопасности (security branches, - например, <literal>RELENG_6_0</literal>) должны быть одобрены - членом группы &a.security-officer; или, в некоторых случаях, одним - из выпускающих инженеров (&a.re;).</para> - </listitem> - - <listitem> - <para>Не пререкайтесь с другими коммиттерами публично: это дурно - выглядит. Если вам необходимо с чем-либо <quote>категорически не - согласиться</quote>, делайте это личной почтой.</para> - - <para>Для всех участников проекта очень важно поддержание его - публичного образа; особенно это важно, если мы хотим продолжать - привлекать новых участников. Случается, что, несмотря на все - усилия по сохранению власти над собой, люди срываются и грубят - друг другу. Лучшее, что здесь можно сделать — - минимизировать эффект, пока все участники не успокоятся. - Следовательно, вы не должны озвучивать свою ярость публично, - а равно и пересылать частную переписку в общедоступные списки - рассылки. Выражения, употребляющиеся в переписке один на один - зачастую гораздо менее сдержанны, чем те, которые каждый участник - употребил бы публично, так что подобной переписке нет места в - публичных рассылках: это лишь усугубит и без того неприятную - ситуацию. Если кто-либо, говорящий вам нелицеприятные слова, - делает это в частной переписке, соблюдайте приличия и вы: - отвечайте приватно. Если, по вашему мнению, кто-либо из - разработчиков поступает с вами нечестно, и это настолько - мучит вас, обратитесь к Правлению, а не выносите конфликт - наружу. Правление приложит все силы к разрешению ситуации, - выступая в роли третейского судьи. В случаях, когда спор - затрагивает какие-либо части кода, и участники не могут прийти к - взаимно приемлемому соглашению, Правление может привлечь - независимого участника для разрешения вопроса. В этом случае - все участники конфликта должны согласиться принять решение, - вынесенное третьей стороной.</para> - </listitem> - - <listitem> - <para>Соблюдайте все периоды заморозки кода (core freeze), а также - своевременно читайте списки рассылки <literal>committers</literal> и - <literal>developers</literal>, чтобы быть в курсе расписания таких - периодов.</para> - - <para>Внесение не одобренных изменений в период заморозки кода - является довольно большой ошибкой. Коммиттеры должны быть - в курсе событий, прежде чем внести 10 мегабайт изменений - после долгого отсутствия. Нарушающие это правило будут - подвергаться заморозке коммиттерского бита до прохождения курса - в Счастливом Лагере Повышения Квалификации FreeBSD, который - организован в Гренландии.</para> - </listitem> - - <listitem> - <para>Если вы сомневаетесь в какой-либо процедуре, сначала - спросите!</para> - - <para>Множество ошибок совершается, когда кто-либо совершает - поспешные действия, думая, что поступает правильно. Делая - что-либо впервые, вы, скорее всего, не знаете принятых мелочей - и тонкостей, и лучше всего будет сначала спросить, не то вы - имеете шансы выставить себя не в лучшем свете. Не стоит - стыдиться спросить <quote>Как, черт возьми, это надо - делать?</quote> Мы и так знаем, что вы умны: иначе вы не стали - бы коммиттером.</para> - </listitem> - - <listitem> - <para>Тестируйте свои изменения перед коммитом.</para> - - <!-- XXX Needs update re sparc64 + pc98 - Also, needs more details on which machines are available for testing - --> - <para>Это правило может показаться очевидным. Впрочем, если бы оно - действительно было очевидно для всех, мы не так часто сталкивались - со случаями явного его нарушения. Если ваши изменения затрагивают - ядро, убедитесь, что после него нормально собираются ядра GENERIC - и LINT. Если вы изменяете другую часть исходного кода, убедитесь, - что код собирается (успешно завершается make buildworld). Если - вы изменяете код в какой-либо ветви, убедитесь, что вы тестируете - его на машине, которая работает именно на этой ветви кода. Если - ваши изменения могут затронуть другие архитектуры, проверьте его - на всех поддерживаемых архитектурах. Список доступных ресурсов - можно найти на странице <uri xlink:href="&url.base;/internal/">&url.base;/internal/</uri>. По мере расширения списка поддерживаемых платформ - в кластер будут добавляться соответствующие машины для - тестирования.</para> - </listitem> - - <listitem> - <para>Не производите коммит в деревья - <filename>src/contrib</filename>, - <filename>src/crypto</filename> и - <filename>src/sys/contrib</filename> без - <emphasis>прямого</emphasis> разрешения (approval) соответствующего - мейнтейнера(ов).</para> - - <para>Описанные деревья содержат исходный код сторонних - производителей, который, как правило, импортируется в - соответствующие ветви. Любой коммит, даже не выводящий файл из - ветви производителя, может стать головной болью для ответственных - за эту часть проекта разработчиков. Так что, если у вас нет - <emphasis>прямого</emphasis> разрешения от мейнтейнера, - <emphasis>ничего</emphasis> не делайте с этой частью - репозитория (если, конечно, вы не поддерживаете этот код - сами).</para> - - <para>Отметим, что только что сказанное вовсе не означает, что вы не - должны пытаться улучшить упомянутый код, наоборот, этому будут - только рады. Лучше всего, если вы передадите ваши исправления - вендору. Если изменения специфичны для FreeBSD, обсудите вопрос - с мейнтейнером, возможно, он посчитает разумным применить их - локально. Тем не менее, что бы вы ни делали, - <emphasis>не</emphasis> производите коммит сами!</para> - - <para>Если вы хотите стать ответственным за <quote>ничей</quote> - участок дерева исходников, свяжитесь с &a.core;.</para> - </listitem> - </orderedlist> - </sect2> - - <sect2> - <title>Правила работы с различными архитектурами</title> - - <para>Начиная с версии 5.0 проект FreeBSD начал поддерживать несколько - новых вычислительных архитектур, и более не является - <quote>&i386;-центричным</quote>. Для упрощения поддержки FreeBSD - на базе всех этих платформ Правлением было сформулировано следующее - заявление:</para> - - <blockquote> - <para>Основной 32-битной платформой разработки является i386; - основная 64-битная платформа — Sparc64. Крупные - изменения в дизайне (в том числе основные изменения в API и ABI) - до попадания в репозиторий должны быть отлажены по крайней мере - на одной 32 и одной 64-битной платформе, желательно на основных - поддерживаемых платформах.</para> - </blockquote> - - <para>Платформы i386 и Sparc64 были выбраны по причине широкой - распространенности доступности для разработчиков; кроме того, они - представляют принципиально разные подходы к дизайну процессора и - системы в целом: порядок байт в слове, организация регистров, - реализация DMA, кэша, страничной адресации и т.д.</para> - - <para>Процессор Alpha, конечно, является 64-битным, однако он - представляет более традиционный дизайн и потому не может служить - достаточно хорошей тестовой платформой для отработки тонкостей, - с которыми разработчик может столкнуться на других 64-битных - платформах. Платформа ia64 во многом сложна так же, как и - Sparc64, однако ее доступность для разработчиков пока оставляет - желать лучшего.</para> - - <para>Мы будем переформулировать эти правила по мере того, как будут - меняться цены и доступность 64-битных платформ.</para> - - <!-- XXX ??? XXX --> - <para>Кроме того, разработчики должны быть в курсе наших правил классов - поддержки (Tier Policy) различных аппаратных архитектур. Эти правила - предназначены для общего описание процесса разработки, и потому - отличаются от вышеописанных требований к возможностям и архитектурам. - Правила классов поддержки на период выпуска релизов много жестче, чем - ограничения на изменения в процессе разработки.</para> - </sect2> - - <sect2> - <title>Другие рекомендации</title> - - <para>Перед коммитом в области документации используйте какие-либо - средства проверки орфографии. Для документов SGML, кроме того, - при помощи команды <command>make lint</command> следует проверить - корректность форматирования.</para> - - <para>Для страниц справочника, при помощи утилиты из коллекции портов - <command>manck</command> проверяйте корректность перекрестных ссылок - и ссылок на файлы, а также наличие всех необходимых ссылок на синонимы - (переменная <varname>MLINK</varname>).</para> - - <para>Не смешивайте функциональные изменения со стилистическими - (не изменяющими функциональных свойств кода). Такое смешивание - затрудняет вычленение изменений при использовании команды - <command>cvs diff</command> и, таким образом, может скрыть появившиеся - ошибки. Не смешивайте в коммите в деревья <filename>doc/</filename> и - <filename>www/</filename> изменения текста и переформатирование: это - затрудняет работу переводчиков. Производите все стилистические - изменения или переформатирования отдельными коммитами, и четко - обозначайте их как таковые в журнальных сообщениях к коммиту.</para> - </sect2> - - <sect2> - <title>Удаление возможностей</title> - - <para>При необходимости удаления какой-либо функциональной возможности - из утилит базовой системы следует использовать следующую схему - действий:</para> - - <orderedlist> - <listitem> - <para>В странице справочника и, возможно, в комментариях к релизу - опция, утилита или интерфейс объявляются устаревающими и не - рекомендованными к использованию (deprecated); их использование - выводит предупреждение.</para> - </listitem> - - <listitem> - <para>Опция, утилита или интерфейс сохраняются до очередного - основного релиза (релиз X.0).</para> - </listitem> - - <listitem> - <para>Опция, утилита или интерфейс удаляются, в том числе из - документации: теперь они являются устаревшими. Как правило, - об этом стоит упомянуть в комментариях к релизу.</para> - </listitem> - </orderedlist> - </sect2> - </sect1> - - <sect1 xml:id="archs"> - <title>Поддержка различных архитектур</title> - - <para>FreeBSD является хорошо портируемой операционной системой и - предназначена для работы на самых разнообразных аппаратных - архитектурах. Важной частью процесса обеспечения гибкости в - поддержке современных тенденций развития оборудования является - деление кода на машинно-зависимый (Machine Dependent, MD) и - машинно-независимый (Machine Independent, MI), а также, по возможности, - минимизация машинно-зависимой части кода. Каждая новая аппаратная - архитектура, которую начинает поддерживать FreeBSD, ощутимо увеличивает - работу по поддержке кода, инструментария и процесса выпуска релизов. - Кроме того, становится значительно сложнее эффективно тестировать - изменения в коде ядра. Все это делает необходимым введение различных - классов поддержки для различных архитектур, при сохранении максимальной - стабильности малого числа "основных платформ".</para> - - <sect2> - <title>Основные намерения</title> - - <para>Проект FreeBSD предназначен для работы на рабочих станциях, - серверах и высокопроизводительных встроенных системах. Сохраняя - ориентир на малое количество архитектур в интересах таких систем, - проект FreeBSD остается способен поддерживать высокий уровень - надежности, стабильности и производительности, а также уменьшить - нагрузку на различные группы поддержки проекта, такие как группы - поддержки портов, документации, безопасности и выпуска релизов. - Разнообразие поддерживаемых аппаратных платформ расширяет область - применимости FreeBSD за счет поддержки новых возможностей (например, - поддержка 64-битных процессоров, использование во встроенных системах - и т.п.); тем не менее, расширение этого списка всегда должно быть - тщательно оценено с позиций увеличения затрат на поддержку - дополнительной аппаратной платформы.</para> - - <para>Проект FreeBSD делит различные аппаратные платформы на 4 класса. - Для каждого класса описывается набор требований, необходимых для - присвоения платформе данного класса, и обязательства разработчиков - по отношению к платформе. Кроме того, определяется порядок смены - класса для архитектуры.</para> - </sect2> - - <sect2> - <title>Класс 1: Полностью поддерживаемые архитектуры</title> - - <para>Платформы 1 класса полностью поддерживаются группой безопасности, - группой выпуска релизов и мейнтейнерами инструментария. Новые - возможности, добавляемые в код системы, должны быть полностью - функциональны для всех архитектур первого класса для каждого из - релизов (исключением могут быть архитектурно-зависимые возможности, - такие как драйвера аппаратуры). Как правило, все платформы 1 класса - должны поддерживаться системами сборки либо расположенными - непосредственно в кластере FreeBSD.org, либо легко доступными для - всех разработчиков.</para> - - <para>Архитектуры первого класса должны быть готовыми к эксплуатации - под управлением FreeBSD во всех аспектах, включая процесс установки - и среду разработки.</para> - - <para>В настоящее время платформами 1 класса являются i386, Sparc64, - AMD64, and PC98.</para> - </sect2> - - <sect2> - <title>Класс 2: Архитектуры для разработчиков</title> - - <para>Платформы 2 класса не поддерживаются группами безопасности и - выпуска релизов. Поддержка инструментария оставляется на усмотрение - его мейнтейнеров. Новые возможности, реализуемые в FreeBSD, должны - быть реализуемы на этих платформах, однако непосредственная реализация - на момент добавления кода в дерево исходных текстов не требуется. - Реализация порта на архитектуру 2 класса может быть добавлена в - репозиторий, если она не входит в противоречие с текущим состоянием - систем первого класса и не влияет в существенной степени на прочие - платформы 2 класса. Для добавления архитектуры 2 класса в дерево - исходных текстов FreeBSD система должна быть способна загрузиться - хотя бы в однопользовательский режим на реальной аппаратуре. - Некоторые исключения из последнего правила могут быть сделаны для - новой аппаратуры, находящейся в состоянии разработки и временно - не доступной для проекта.</para> - - <para>Обычно архитектурами 2 класса являются те, которые планируются - к переходу в 1 класс, но пока находятся в состоянии разработки. - Также во втором классе могут находится платформы, перешедшие из - 1 класса по причине потери актуальности, по мере того как уменьшается - количество ресурсов, доступных для поддержки системы в состоянии - готовности к промышленной эксплуатации.</para> - - <para>В настоящее время платформами 2 класса являются PowerPC - и ia64.</para> - </sect2> - - <sect2> - <title>Класс 3: Экспериментальные архитектуры</title> - - <para>Платформы 3 класса не поддерживаются группами безопасности и - выпуска релизов. Поддержка инструментария оставляется на усмотрение - его мейнтейнеров. Архитектурами третьего класса могут быть: те, для - которых нет и в ближайшее время не предвидится доступного проекту - оборудования; имеющие менее трех активных разработчиков; не способные - загрузиться в однопользовательский режим на реальной аппаратуре (или - под управлением эмулятора, если реальная аппаратура недоступна); - наконец, системы, которые оцениваются как исчезающие, чья дальнейшая - распространенность сомнительна. Поддержка систем 3 класса не вносится - в основное дерево исходных текстов FreeBSD, однако работа над такими - архитектурами может производиться в репозитории Perforce FreeBSD, для - облегчения контроля версий и дальнейшей интеграции с основной массой - кода.</para> - - <para>В настоящее время единственной платформой 3 класса является - &s390;.</para> - </sect2> - - <sect2> - <title>Класс 4: не поддерживаемые архитектуры</title> - - <para>Системы 4 класса никак не поддерживаются проектом.</para> - - <para>К 4 классу относятся все архитектуры, не перечисленные выше.</para> - </sect2> - - <sect2> - <title>Правила смены класса для архитектуры</title> - - <para>Для переноса платформы из класса в класс требуется решение, - утвержденное Правлением, которое, в свою очередь, согласует его - с группами безопасности, выпуска релизов и поддержки инструментария. - </para> - </sect2> - </sect1> - - <sect1 xml:id="ports"> - <title>FAQ по работе с портами</title> - - <qandaset> - <qandadiv> - <title>Добавление нового порта</title> - - <qandaentry> - <question> - <para>Как добавить новый порт?</para> - </question> - - <answer> - <para>Для начала прочитайте раздел, посвященный репозиторному - копированию.</para> - - <para>Самым простым будет использовать скрипт - <command>addport</command> на машине - <systemitem>freefall</systemitem>. Он добавит порт из указанного вами - каталоге, определив нужную категорию из файла - <filename>Makefile</filename>, добавит строку в файл - <filename>CVSROOT/modules</filename> и в файл - <filename>Makefile</filename> для нужной категории. - Скрипт был написан &a.mharo.email; и &a.will.email;; вопросы и исправления - по поводу <command>addport</command> следует отправлять Уиллу, - как текущему мейнтейнеру.</para> - </answer> - </qandaentry> - - <qandaentry> - <question> - <para>Что еще следует сделать, добавляя новый порт?</para> - </question> - - <answer> - <para>Проверьте его. Желательно убедиться в том, что порт и - соответствующий пакет корректно собираются. Рекомендуемая - последовательность действий такова:</para> - - <screen>&prompt.root; <userinput>make install</userinput> -&prompt.root; <userinput>make package</userinput> -&prompt.root; <userinput>make deinstall</userinput> -&prompt.root; <userinput>pkg_add <replaceable>имя собранного пакета</replaceable></userinput> -&prompt.root; <userinput>make deinstall</userinput> -&prompt.root; <userinput>make reinstall</userinput> -&prompt.root; <userinput>make package</userinput> - </screen> - - <para>Более подробные инструкции можно найти в - <link xlink:href="&url.books.porters-handbook;/index.html">Руководстве - FreeBSD по созданию портов</link>.</para> - - <para>Пользуйтесь &man.portlint.1; для проверки корректности порта. - Не обязательно добиваться полного отсутствия предупреждений, - но по крайней мере исправьте простейшие из них.</para> - - <para>Если новый порт прислал человек, еще не упомянутый в - <link xlink:href="&url.articles.contributors;/contrib-additional.html">Списке - прочих участников</link>, добавьте его имя туда.</para> - - <para>Закройте PR, если новый порт пришел в виде PR. Для этого - воспользуйтесь командой - <userinput>edit-pr <replaceable>PR#</replaceable></userinput> - на машине <systemitem>freefall</systemitem> и измените значение в строке - <varname>state</varname> с <constant>open</constant> на - <constant>closed</constant>. Затем опишите причину смены - статуса, и на этом работа закончена.</para> - </answer> - </qandaentry> - </qandadiv> - - <qandadiv> - <title>Удаление порта</title> - - <qandaentry> - <question> - <para>Как удалить существующий порт?</para> - </question> - - <answer> - <para>Для начала прочтите раздел о репозиторном копировании. - Прежде чем удалить порт, вы должны проверить, что удаление не - затронет другие порты коллекции.</para> - <itemizedlist> - <listitem> - <para>Убедитесь, что другие порты не зависят от удаляемого:</para> - <itemizedlist> - <listitem> - <para>Имя пакета (PKGNAME) должно встречаться в свежем - файле INDEX ровно один раз.</para> - </listitem> - <listitem> - <para>В файлах Makefile* других портов не должно - встречаться ни одной ссылки на каталог удаляемого - порта или имя его пакета (PKGNAME).</para> - </listitem> - </itemizedlist> - </listitem> - <listitem> - <para>Удалите порт:</para> - - <procedure> - <step> - <para>Удалите файлы порта командой - <command>cvs remove</command>.</para> - </step> - - <step> - <para>Удалите строку <varname>SUBDIR</varname> для - удаляемого порта из файла <filename>Makefile</filename> - категории.</para> - </step> - - <step> - <para>Удалите запись для порта из файла модулей - <filename>CVSROOT/modules</filename>.</para> - </step> - - <step> - <para>Добавьте соответствующую строку в файл - <filename>ports/MOVED</filename>.</para> - </step> - - <step> - <para>Если порт упоминается в файле - <filename>ports/LEGAL</filename>, удалите его оттуда. - </para> - </step> - </procedure> - </listitem> - </itemizedlist> - - <para>Вы можете воспользоваться скриптом <command>rmport</command> - из каталога <filename>ports/Tools/scripts</filename>. - Этот скрипт написал &a.vd.email;, и он же его поддерживает, так что - вопросы, исправления и замечания по поводу <command>rmport</command> - следует посылать непосредственно ему.</para> - </answer> - </qandaentry> - </qandadiv> - - <qandadiv> - <title>Репозиторное копирование</title> - - <qandaentry> - <question> - <para>Когда требуется репозиторное копирование?</para> - </question> - - <answer> - <para>При необходимости добавления порта, имеющего отношение - к другому, уже находящемуся в репозитории в другом каталоге, - необходимо произвести репозиторное копирование. В данном - случае <wordasword>имеющий отношение</wordasword> означает - другую версию или небольшую модификацию. Примерами могут - служить различные версии - <filename>print/ghostscript*</filename> и английская и - локализованные версии - <filename>x11-wm/windowmaker*</filename>.</para> - - <para>Другим примером является необходимость перенести порт из - одного подкаталога в другой, или переименовать каталог, когда - автор меняет имя своей программы.</para> - </answer> - </qandaentry> - - <qandaentry> - <question> - <para>Когда репозиторное копирование <emphasis>не</emphasis> - требуется?</para> - </question> - - <answer> - <para>Если нет истории, которую стоило бы сохранять. Для порта, - добавленного в неправильную категорию и сразу же перемещенного, - будет вполне достаточно выполнить команды - <command>cvs remove</command> для старого варианта и - <command>addport</command> для нового.</para> - </answer> - </qandaentry> - - <qandaentry> - <question> - <para>Что нужно делать?</para> - </question> - - <answer> - <para>Создайте в <application>GNATS</application> PR, описав - причины репозиторного копирования. Поменяйте ответственного - на <literal>portmgr</literal> и установите статус - (<varname>state</varname>) в состояние - <literal>repocopy</literal>. Если ваш запрос будет одобрен - группой &a.portmgr;, он будет переадресован на - <literal>pcvs</literal>. &a.portmgr; может произвести - копирование каталогов самостоятельно; в противном случае - группа &a.pcvs; произведет собственно - копирование и вернет вам ваш PR. После этого, вам необходимо - проделать следующее:</para> - - <itemizedlist> - <listitem> - <para>После репозиторного копирования порта:</para> - - <procedure> - <step> - <para>Обновите новый вариант порта до новой версии. - Не забудьте изменить строку <varname>LATEST_LINK</varname>, - чтобы не получить двух портов с одним именем. В - некоторых исключительных случаях может быть необходимо - изменить переменную <varname>PORTNAME</varname> вместо - <varname>LATEST_LINK</varname>, но это должно быть сделано - только тогда когда это действительно нужно. Например, - при использовании существующего порта в качестве основы для - весьма похожей программы с другим именем или при обновлении - порта до новой основной версии программы, при котором изменяется - имя самого дистрибутива, как в случае перехода с - <filename>textproc/libxml</filename> на - <filename>textproc/libxml2</filename>. В большинстве случаев - изменение <varname>LATEST_LINK</varname> должно быть достаточно.</para> - </step> - - <step> - <para>Добавьте новый каталог в список - <varname>SUBDIR</varname> в родительском файле - <filename>Makefile</filename>. - Для проверки вы можете воспользоваться - командой <command>make checksubdirs</command>.</para> - </step> - - <step> - <para>Если порт менял категорию, измените строку - <varname>CATEGORIES</varname> в файле - <filename>Makefile</filename>.</para> - </step> - - <step> - <para>Добавьте строку для нового модуля в - <filename>CVSROOT/modules</filename>.</para> - </step> - - <step> - <para>Добавьте строку в файл - <filename>ports/MOVED</filename>, в случае - если вы удалили первоначальный порт.</para> - </step> - </procedure> - </listitem> - - <listitem> - <para>При удалении порта:</para> - - <procedure> - <step> - <para>Тщательно проверьте коллекцию на предмет портов, - зависящих от удаляемого и обновите их при необходимости. - Выполнение команды <command>grep</command> по содержимому - файла <filename>INDEX</filename> недостаточно, поскольку - некоторые порты могут быть сконфигурированы на этапе - сборки. Рекомендуется использовать полный поиск при - помощи команды <command>grep -r</command>.</para> - </step> - - <step> - <para>Удалите старый порт, запись <varname>SUBDIR</varname> - и строку, описывающую модуль.</para> - </step> - - <step> - <para>Добавьте строку в файл - <filename>ports/MOVED</filename>.</para> - </step> - </procedure> - </listitem> - - <listitem> - <para>После репозиторного перемещения (операции - <quote>переименования</quote>, когда после копирования - старый вариант удаляется):</para> - - <procedure> - <step> - <para>Используйте процедуры из предыдущих двух пунктов для - активации нового порта и удаления старого.</para> - </step> - </procedure> - </listitem> - </itemizedlist> - </answer> - </qandaentry> - </qandadiv> - - <qandadiv> - <title>Заморозка портов</title> - - <qandaentry> - <question> - <para>Что такое <quote>заморозка портов</quote>?</para> - </question> - - <answer> - <para>Перед выпуском релиза для сохранения целостности различных - частей системы требуется на некоторое время ограничить - коммиты в дерево портов. Этот процесс и называется - <quote>заморозкой портов</quote>.</para> - - <para>За дополнительной информацией по поводу правил поведения - во время заморозки обращайтесь к документу - <link xlink:href="&url.base;/ru/portmgr/qa.html">Задачи контроля - качества для Группы управления портами</link>.</para> - </answer> - </qandaentry> - - <qandaentry> - <question> - <para>Сколько длится заморозка?</para> - </question> - - <answer> - <para>Обычно неделю или две.</para> - </answer> - </qandaentry> - - <qandaentry> - <question> - <para>Что это значит для меня?</para> - </question> - - <answer> - <para>Во время заморозки вы не можете производить какие-либо - коммиты в дерево портов без прямого разрешения группы порт-менеджеров. - <quote>Прямое разрешение</quote> здесь означает, что вы послали - свой патч группе порт-менеджеров и получили ответ - <quote>Вперед, производите коммит</quote>. - </para> - - <para>В период заморозки не все изменения могут быть внесены - в дерево. За подробностями обращайтесь к документу - <link xlink:href="&url.base;/ru/portmgr/qa.html">Задачи контроля - качества для Группы управления портами</link>. - </para> - - <para>Отметим, что у вас нет подразумеваемого разрешения - исправлять неработающий порт в период заморозки только потому, - что порт не работает.</para> - </answer> - </qandaentry> - - <qandaentry> - <question> - <para>Откуда я узнаю о начале периода заморозки?</para> - </question> - - <answer> - <para>Обычно за 2-3 недели до начала периода заморозки - кто-либо из группы порт-менеджеров посылает письмо с предупреждением об этом в - &a.ports; и &a.committers;. Точное время начала периода - заморозки определяется за несколько дней до собственно - релиза, поскольку фиксируемое дерево портов должно быть - синхронизировано с релизом, а точная дата выпуска - определяется по ходу дела.</para> - - <para>Разумеется, после начала периода заморозки в - &a.committers; будет отправлено еще одно предупреждение.</para> - </answer> - </qandaentry> - - <qandaentry> - <question> - <para>Как узнать, когда период заморозки портов закончился?</para> - </question> - - <answer> - <para>Завершение периода заморозки анонсируется группой порт-менеджеров - посылкой письма в &a.ports; и &a.committers; через несколько - часов после релиза. Отметим, что факт выпуска релиза не - означает автоматического завершения заморозки. Нам потребуется - убедиться, что в последние минуты не произошло ничего - непредвиденного, что заставило бы перевыпускать релиз.</para> - </answer> - </qandaentry> - </qandadiv> - - <qandadiv> - <title>Создание новой категории</title> - - <qandaentry> - <question> - <para>Какова процедура создания новой категории портов?</para> - </question> - - <answer> - <para>Разработчик, предлагающий новую категорию, должен - подготовить детальное обоснование ее создания, в том числе - описание причин, по которым текущий список категорий - недостаточен, а также список портов, переносимых в новую - категорию.</para> - - <para>Прежде чем отправлять запрос, помните, что процесс потребует - приложения немалых сил от многих участников, затронет всякого, - кто поддерживает актуальное состояние дерева портов целиком, и, - наконец, что подобные предложения неизбежно вызовут споры и - расхождения во мнениях.</para> - - <!-- XXX change to url.ru.books after merging 5.3.4 --> - <para>Обратитесь к разделу - <link xlink:href="&url.books.porters-handbook;/makefile-categories.html#PROPOSING-CATEGORIES"> - Proposing a New Category</link> Руководства по созданию портов. - После передачи PR группе &a.portmgr; решение о создании категории - остается за ней. В случае утверждения новой категории кто-либо - из &a.portmgr; делает следующее:</para> - - <procedure> - <step> - <para>Производит нужные репозиторные копирования.</para> - </step> - - <step> - <para>Обновляет определения <varname>VALID_CATEGORIES</varname> - в файле <filename>ports/Mk/bsd.port.mk</filename>. - </para> - </step> - - <step> - <para>Возвращает PR вам.</para> - </step> - </procedure> - </answer> - </qandaentry> - - <qandaentry> - <question> - <para>Как устроен процесс?</para> - </question> - - <answer> - <para>Процедура является надстройкой над уже описанной процедурой - репозиторного копирования отдельного порта.</para> - - <procedure> - <step> - <para>Обновите файлы <filename>Makefile</filename> для всех - перенесенных портов. Пока не добавляйте новую категорию - в процесс построения индекса.</para> - - <para>Для этого вам необходимо:</para> - <procedure> - <step> - <para>Сменить для всех портов значение переменной - <varname>CATEGORIES</varname> (это и было нашей - целью, не правда ли?) Новая категория должна быть - указано в списке <emphasis>первой</emphasis>, это - поможет проверить, правильно ли установлена - переменная <varname>PKGORIGIN</varname>.</para> - </step> - - <step> - <para>Выполните команду <command>make - describe</command>. Поскольку процедура построения - главного индекса <command>make index</command>, - которую вам предстоит выполнить несколько позже, - использует именно <command>make describe</command>, - обнаружение ошибок сейчас сэкономит вам немало - времени в будущем.</para> - </step> - - <step> - <para>Если вы хотите быть совсем честным, самое время - запустить &man.portlint.1;.</para> - </step> - </procedure> - </step> - - <step> - <para>Проверьте корректность переменных - <varname>PKGORIGIN</varname>. Система работы с портами - использует значение переменной - <varname>CATEGORIES</varname> для установки переменной - <varname>PKGORIGIN</varname>, которая затем используется - для связи установленных пакетов с каталогами дерева - портов. Если эта связь установлена неправильно, перестанут - правильно функционировать утилиты работы с портами, такие - как &man.pkg.version.1; и &man.portupgrade.1;.</para> - - <para>Для проверки следует использовать скрипт - <filename>chkorigin.sh</filename>: <command>env - PORTSDIR=<replaceable>/path/to/ports</replaceable> - sh -e <replaceable>/path/to/ports</replaceable>/Tools/scripts/chkorigin.sh - </command>. Эта команда проверит - <emphasis>каждый</emphasis> порт в дереве, в том числе и - те, что не включены в процесс сборки, так что ее можно - использовать сразу после репозиторного копирования. - Совет: не забудьте проверить <varname>PKGORIGIN</varname> - для зависимых от изменяемых вами портов!</para> - </step> - - <step> - <para>Протестируйте изменения локально, на вашей машине: - закомментируйте строки <varname>SUBDIR</varname> для - старых портов, затем разрешите обработку новой - категории в файле <filename>ports/Makefile</filename>. - Запустите <command>make checksubdirs</command> в - затрагиваемых категориях. Наконец, выполните в каталоге - <filename>ports/</filename> команду - <command>make index</command>. Ее выполнение может занять - до 40 минут даже на современной машине, однако, это - необходимые затраты для того, чтобы не создать проблем - для других.</para> - </step> - - <step> - <para>После завершения этой операции вы можете вносить в - репозиторий изменения <filename>ports/Makefile</filename> - для включения новой категории в процесс сборки, а также - производить коммит изменений <filename>Makefile</filename> - для старых категорий.</para> - </step> - - <step> - <para>Добавьте в файл <filename>CVSROOT-ports/modules</filename> - строку - <programlisting>ports_<replaceable>categoryname</replaceable> <replaceable>categoryname</replaceable></programlisting> - </para> - - <para>Поля должны быть разделены табуляцией.</para> - - <para>Если <replaceable>categoryname</replaceable> - содержит дефисы, замените их на подчеркивания.</para> - </step> - - <step> - <para>Поменяйте строки для затронутых модулей в файле - <filename>CVSROOT-ports/modules</filename>.</para> - </step> - - <step> - <para>Добавьте нужные строки в файл - <filename>ports/MOVED</filename>.</para> - </step> - - <step> - <para>Обновите инструкции для &man.cvsup.1;:</para> - - <itemizedlist> - <listitem> - <para> - Добавьте категорию в файл - <filename>distrib/cvsup/sup/README</filename> - </para> - </listitem> - - <listitem> - <para> - Добавьте в каталог - <filename>distrib/cvsup/sup/ports-<replaceable>categoryname</replaceable></filename> - два файла: - <filename>list.cvs</filename> и - <filename>releases</filename>.</para> - </listitem> - - <listitem> - <para> - Добавьте категорию в файл - <filename>src/share/examples/cvsup/ports-supfile</filename> - </para> - </listitem> - </itemizedlist> - - <para> - (Обратите внимание: эти - файлы расположены в репозитории src, а не ports). - Если вы не являетесь коммиттером src, вам потребуется - создать PR.</para> - </step> - - <step> - <para>Обновите список категорий, используемый в &man.sysinstall.8; - в <filename>src/usr.sbin/sysinstall</filename>.</para> - </step> - - <step> - <para>Обновите документацию:</para> - - <itemizedlist> - <listitem> - <para> - <link xlink:href="&url.books.porters-handbook;/makefile-categories.html#PORTING-CATEGORIES"> - Руководство FreeBSD по созданию портов</link></para> - </listitem> - - <listitem> - <para> - Файл <filename>www/en/ports/categories</filename>. - Обратите внимание, что строки в них сгруппированы по - категориям, описанным в файле - <filename>www/en/ports/categories.descriptions</filename>. - </para> - </listitem> - - <listitem> - <para>Раздел Руководства, перечисляющий - <link xlink:href="&url.books.handbook;/cvsup.html#CVSUP-COLLEC"> - cvsup коллекции</link>.</para> - </listitem> - </itemizedlist> - <para>(Внимание: все эти файлы находятся в репозитории - документации. Если вы не являетесь коммиттером в этой области, - создайте PR в категории документации (doc).</para> - </step> - - <step> - <para>Старые варианты портов могут быть удалены из - репозитория только после того, как все описанные процедуры - будут завершены, и никто не жалуется на новую структуру.</para> - </step> - </procedure> - - <para>Специально обновлять <link xlink:href="&url.base;/ports/index.html">веб-страницу портов</link> - при добавлении новой категории не нужно: изменение файла - <filename>www/en/ports/categories</filename> будет учтено при - ежедневной перестройке списка портов - (<filename>INDEX</filename>) автоматически. - </para> - </answer> - </qandaentry> - </qandadiv> - - <qandadiv> - <title>Прочие вопросы</title> - - <qandaentry> - <question> - <para>Как мне проверить, что мой порт корректно собирается?</para> - </question> - - <answer> - <para>В первую очередь проверьте свой порт по адресу - <uri xlink:href="http://pointyhat.FreeBSD.org/errorlogs/">http://pointyhat.FreeBSD.org/errorlogs/</uri>. - Там вы найдете журналы сборки пакетов на всех поддерживаемых - архитектурах для большинства последних ветвей разработки.</para> - - <para>Впрочем, отсутствие вашего порта среди журналов с ошибками - еще не значит, что он успешно собирается (например, может не - собираться один из зависимых портов). Необходимую информацию вы - можете найти на машине <systemitem>pointyhat</systemitem> в каталогах - <filename>/a/portbuild/<arch>/<major_version></filename>. - Каждая пара архитектуры и базовой версии содержит следующие - подкаталоги:</para> - -<programlisting>errors журналы ошибок последней сборки версии <major_version> на платформе <arch> -logs все журналы последней сборки версии <major_version> на платформе <arch> -packages свежесобранные пакеты для версии <major_version> на платформе <arch> -bak/errors журналы ошибок последней полной сборки версии <major_version> на платформе <arch> -bak/logs все журналы последней полной сборки версии <major_version> на платформе <arch> -bak/packages пакеты последней полной сборки версии <major_version> на платформе <arch></programlisting> - - <para>Общее правило: пакет, присутствующий в каталоге - <filename>packages</filename> или каталоге - <filename>logs</filename>, и при этом отсутствующий в - <filename>errors</filename>, собрался успешно. (Именно каталоги - <filename>errors</filename> вы видите на веб-сервере - <systemitem>pointyhat</systemitem>).</para> - </answer> - </qandaentry> - - <qandaentry> - <question> - <para>Я добавил новый порт. Нужно ли добавлять его в файл - <filename>INDEX</filename>?</para> - </question> - - <answer> - <para>Нет. <filename>INDEX</filename> больше не хранится - в CVS репозитории. Данный файл может быть сгенерирован - с помощью команды <command>make index</command> или - уже сгенерированная версия может быть загружена с помощью - <command>make fetchindex</command>.</para> - </answer> - </qandaentry> - - <qandaentry> - <question> - <para>Какие еще файлы я не должен трогать?</para> - </question> - - <answer> - <para>Любой файл в на верхнем уровне <filename>ports/</filename>, - а также все файлы в каталогах, имена которых начинаются с - прописной буквы (например, <filename>Mk/</filename>, - <filename>Tools/</filename> и т.п.). В частности, упаси вас - Бог трогать файлы <filename>ports/Mk/bsd.port*.mk</filename>, - если вы не хотите привести порт-менеджеров в ярость!</para> - </answer> - </qandaentry> - - <qandaentry> - <question> - <para>Каков корректный порядок обновления порта, когда его - исходный архив поменялся, но не сменил имя?</para> - </question> - - <answer> - <para>При возникновении ситуации, когда автор обновляет - дистрибутивный архив без изменения идентификатора версии, - сообщение о коммите должно содержать аннотацию различий между - предыдущим и обновленным состоянием архива, чтобы можно было - убедиться, что архив не испорчен и не подменен злоумышленником. - Если текущая версия порта существовала достаточное время, копии - архива будут доступны на ftp-серверах проекта; в противном - случае следует связаться с автором или мейнтейнером порта для - выяснения причин замены архива.</para> - </answer> - </qandaentry> - </qandadiv> - </qandaset> - </sect1> - - <sect1 xml:id="perks"> - <title>Пряники и прочие льготы</title> - - <para>Увы, льгот, возникающих от того, что вы являетесь коммиттером, - не так уж много. Пожалуй, единственным несомненным долговременным - преимуществом будет признание вас как компетентного специалиста. - Тем не менее, кое-какие льготы все же существуют:</para> - - <variablelist> - - <varlistentry> - <term>Прямой доступ к машине <systemitem>cvsup-master</systemitem></term> - - <listitem> - <para>Будучи коммиттером, вы можете обратиться к &a.kuriyama.email;, чтобы - получить доступ к машине - <systemitem class="fqdomainname">cvsup-master.FreeBSD.org</systemitem>, приложив - вывод команды <command>cvpasswd - <replaceable>yourusername</replaceable>@FreeBSD.org - freefall.FreeBSD.org</command>. Обратите внимание: в командной - строке вы должны указать <systemitem>freefall.FreeBSD.org</systemitem>, - хотя реальным сервером будет <systemitem>cvsup-master</systemitem>. - Доступом к <systemitem>cvsup-master</systemitem> не следует злоупотреблять: - это весьма загруженная машина.</para> - </listitem> - </varlistentry> - - <varlistentry> - <term>Бесплатная подписка на комплект из 4 CD или DVD</term> - - <listitem> - <para>Компания <link xlink:href="http://www.freebsdmall.com">FreeBSD Mall, - Inc.</link> предоставляет для всех коммиттеров FreeBSD возможность - бесплатной подписки на выпуски FreeBSD. Порядок подписки появляется - в списке рассылки <email>developers@FreeBSD.org</email> после - каждого релиза.</para> - </listitem> - </varlistentry> - - </variablelist> - </sect1> - - <sect1 xml:id="misc"> - <title>Прочие вопросы</title> - - <qandaset> - <qandaentry> - <question> - <para>Почему не следует вносить малозначимые изменения в ветви - разработчика (vendor branches)?</para> - </question> - - <answer> - <itemizedlist> - <listitem> - <para>После этого действия каждый новый релиз от разработчика - требует ручного приложения и объединения патчей.</para> - </listitem> - - <listitem> - <para>Что хуже, каждый новый релиз от разработчика требует - ручной <emphasis>проверки</emphasis> приложенных патчей.</para> - </listitem> - - <listitem> - <para>Опция CVS <option>-j</option> не всегда хорошо работает. - Можете спросить &a.obrien.email;, он расскажет вам жутких - историй.</para> - </listitem> - </itemizedlist> - </answer> - </qandaentry> - - <qandaentry> - <question> - <para>Как мне добавить файл в ветвь CVS?</para> - </question> - - <answer> - <para>Для добавления файла в ветви просто обновите исходные файлы - до нужной ветви, а затем используйте команду - <command>cvs add</command>. Например, если мы хотите перенести - файл <filename>src/sys/alpha/include/smp.h</filename> из ветви - HEAD в ветвь RELENG_6, в которой он пока не существует, можно - использовать следующую последовательность действий:</para> - - <example> - <title>MFC для нового файла</title> - - <screen>&prompt.user; <userinput>cd sys/alpha/include</userinput> -&prompt.user; <userinput>cvs update -rRELENG_6</userinput> -cvs update: Updating . -U clockvar.h -U console.h -... -&prompt.user; <userinput>cvs update -kk -Ap smp.h > smp.h</userinput> -=================================================================== -Checking out smp.h -RCS: /usr/cvs/src/sys/alpha/include/smp.h,v -VERS: 1.1 -*************** -&prompt.user; <userinput>cvs add smp.h</userinput> -cvs add: scheduling file `smp.h' for addition on branch `RELENG_6' -cvs add: use 'cvs commit' to add this file permanently -&prompt.user; <userinput>cvs commit</userinput> - </screen> - </example> - </answer> - </qandaentry> - - <qandaentry> - <question> - <para>Какую <quote>мета-информацию</quote> я должен включать в - сообщения для коммита?</para> - </question> - - <answer> - <para>Помимо информативного описания содержания коммита вам может - потребоваться включить в сообщение дополнительную - информацию.</para> - - <para>Она состоит из одной или нескольких строк вида: ключевое слово - или словосочетание, двоеточие, табуляции для форматирования, - собственно дополнительная информация.</para> - - <para>Ключевыми словами могут быть:</para> - - <informaltable frame="none" pgwide="1"> - <tgroup cols="2"> - <tbody> - <row> - <entry><literal>PR:</literal></entry> - <entry>Идентификатор сообщения об ошибке, затрагиваемого - (как правило, закрываемого) данным коммитом.</entry> - </row> - - <row> - <entry><literal>Submitted by:</literal></entry> - <entry>Имя и e-mail адрес приславшего исправление; для - коммиттеров — просто имя пользователя в - кластере FreeBSD.</entry> - </row> - - <row> - <entry><literal>Reviewed by:</literal></entry> - <entry>Имя и e-mail адрес того или тех, кто рецензировал - изменения; для коммиттеров — имя пользователя в - кластере FreeBSD. Если изменения были посланы в список - рассылки на рецензию и получили одобрение, имя списка - рассылки.</entry> - </row> - - <row> - <entry><literal>Approved by:</literal></entry> - <entry>Имя и e-mail адрес того или тех, кто одобрил - изменение; как и прежде, для коммиттеров просто имя - пользователя в кластере. Обычной практикой является - получение одобрения для коммитов в новые для вас области - дерева. Кроме того, в период перед каждым релизом все - коммиты <emphasis>должны</emphasis> быть одобрены группой - выпускающих инженеров. В случае ваших первых коммитов - вы должны получить одобрение на них у вашего ментора, и - упомянуть его в виде - <quote><replaceable>username-of-mentor</replaceable> - <literal>(mentor)</literal></quote>. - </entry> - </row> - - <row> - <entry><literal>Obtained from:</literal></entry> - <entry>Имя проекта, из исходного кода которого было взято - изменение.</entry> - </row> - - <row> - <entry><literal>MFC after:</literal></entry> - - <entry>Если вы хотите получать по почте напоминания об - <acronym>MFC</acronym>, укажите число дней, недель или - месяцев с момента изначального коммита, через которое - вы планируете произвести <acronym>MFC</acronym>.</entry> - </row> - - <row> - <entry><literal>Security:</literal></entry> - - <entry>Если ваши изменения затрагивают вопросы безопасности - или исправляют какие-либо уязвимости, укажите ссылки на - опубликованные отчеты или описание проблемы.</entry> - </row> - </tbody> - </tgroup> - </informaltable> - - <example> - <title>Сообщение для коммита, основанного на PR</title> - - <para>Вы собираетесь внести коммит, основанный на PR, присланном - John Smith и содержащим патч для исправления проблемы. Ваше - сообщение должно заканчиваться примерно такими строками:</para> - - <programlisting>... - -PR: foo/12345 -Submitted by: John Smith <John.Smith@example.com></programlisting> - </example> - - <example> - <title>Сообщение для коммита, требующего рецензии</title> - - <para>Вы собираетесь изменить подсистему работы с виртуальной - памятью. Вы опубликовали предполагаемые изменения в - соответствующем списке рассылки (в данном случае - <literal>freebsd-arch</literal>), и изменения были - одобрены.</para> - - <programlisting>... - -Reviewed by: -arch</programlisting> - </example> - - <example> - <title>Сообщение для коммита, требующего одобрения</title> - - <para>Вы намерены произвести коммит в область дерева, для которой - определен ведущий (MAINTAINER). Вы скоординировали усилия с - мейнтейнером, и он отреагировал <quote>Отлично. Производи - коммит.</quote></para> - - <programlisting>... - -Approved by: <replaceable>abc</replaceable></programlisting> - - <para>Где <replaceable>abc</replaceable> имя пользователя, - одобрившего ваш коммит.</para> - </example> - - <example> - <title>Сообщение для коммита, использующего код OpenBSD</title> - - <para>Вы собираетесь внести изменение, основанное на коде, - использованном проектом OpenBSD.</para> - - <programlisting>... - -Obtained from: OpenBSD</programlisting> - </example> - - <example> - <title>Сообщение для коммита, планирующего интеграцию из - &os.current; в &os.stable; через некоторое время</title> - - <para>Вы хотите внести изменения, которые должны быть интегрированы - из &os.current; в ветвь &os.stable; через две недели.</para> - - <programlisting>... - -MFC after: <replaceable>2 weeks</replaceable></programlisting> - - <para>Где <replaceable>2</replaceable> является количеством дней, - недель или месяцев, через которое вы планируете интегрировать - (<acronym>MFC</acronym>) в &os.stable;. В качестве - <replaceable>weeks</replaceable> может быть использовано - <literal>week</literal>, <literal>weeks</literal>, - <literal>month</literal>, <literal>months</literal>, либо - этот параметр может быть опущен (при этом подразумевается - <replaceable>X</replaceable> дней).</para> - </example> - - <para>В отдельных случаях вам потребуется комбинировать приведенные - примеры.</para> - - <para>Рассмотрим ситуацию, когда некто прислал сообщение об ошибке, - содержащее код из проекта NetBSD. Вы заинтересовались этим - случаем, но он расположен в той части дерева, в которой вы обычно - не работаете, так что вы решаете выдать изменения на рассмотрение - списка рассылки <literal>arch</literal>. Поскольку изменения были - достаточно сложны, вы решаете интегрировать их - (<acronym>MFC</acronym>) через месяц, чтобы обеспечить адекватное - время для тестирования.</para> - - <para>В описанном случае сообщения для коммита может выглядеть - примерно так:</para> - - <programlisting>PR: foo/54321 -Submitted by: John Smith <John.Smith@example.com> -Reviewed by: -arch -Obtained from: NetBSD -MFC after: 1 month</programlisting> - </answer> - </qandaentry> - - <qandaentry> - <question> - <para>Как мне получить доступ к <systemitem class="fqdomainname">people.FreeBSD.org</systemitem> для того чтобы разместить - там персональную информацию или информацию о моих проектах?</para> - </question> - - <answer> - <para><systemitem class="fqdomainname">people.FreeBSD.org</systemitem> — - синоним для <systemitem class="fqdomainname">freefall.FreeBSD.org</systemitem>. - Просто создайте каталог <filename>public_html</filename>. Все, - что вы разместите в нем, будет автоматически доступно по адресу - <uri xlink:href="http://people.FreeBSD.org/">http://people.FreeBSD.org/</uri>.</para> - </answer> - </qandaentry> - - <qandaentry> - <question> - <para>Где расположены архивы списков рассылки?</para> - </question> - - <answer> - <para>Списки рассылки архивируются в иерархию каталогов - <filename>/g/mail</filename>, видимую на всех машинах кластера как - <filename>/hub/g/mail</filename> (см. &man.pwd.1;).</para> - </answer> - </qandaentry> - - <qandaentry> - <question> - <para>Мне бы хотелось стать ментором для нового коммиттера. Какого - технологического процесса я должен придерживаться?</para> - </question> - - <answer> - <para>Обратитесь к документу <link xlink:href="http://www.freebsd.org/internal/new-account.html">Процедура - создания нового аккаунта</link>.</para> - </answer> - </qandaentry> - </qandaset> - </sect1> -</article> |