diff --git a/ru_RU.KOI8-R/articles/committers-guide/article.sgml b/ru_RU.KOI8-R/articles/committers-guide/article.sgml index 4937674f15..e3b1b72d7a 100644 --- a/ru_RU.KOI8-R/articles/committers-guide/article.sgml +++ b/ru_RU.KOI8-R/articles/committers-guide/article.sgml @@ -1,3197 +1,3270 @@ %articles.ent; ]>
Справочник коммиттера The FreeBSD Documentation Project Дмитрий Морозовский Перевод на русский язык: $FreeBSD$ 1999 2000 2001 2002 2003 2004 2005 The FreeBSD Documentation Project &tm-attrib.freebsd; &tm-attrib.cvsup; &tm-attrib.ibm; &tm-attrib.intel; &tm-attrib.sparc; &tm-attrib.general; Данный документ содержит информацию для сообщества коммиттеров FreeBSD. Все новые коммиттеры должны изучить его перед началом работы; прочим коммиттерам также рекомендуется время от времени просматривать его. Административные детали Хост основного репозитория ncvs.FreeBSD.org Способ авторизации &man.ssh.1;, только протокол 2 Основной корень репозитория (CVSROOT) ncvs.FreeBSD.org:/home/ncvs (см. также ). &a.cvsadm; &a.peter; и &a.markm;, а также &a.joe; и &a.marcus; для иерархии ports/ Списки рассылки &a.doc-developers;, &a.doc-committers;; &a.ports-developers;, &a.ports-committers;; &a.src-developers;, &a.src-committers;. (Каждому репозиторию проекта соответствуют отдельные списки рассылки с суффиксами -developers и -committers. Архивы этих списков хранятся в файлах /home/mail/repository-name-developers-archive и /home/mail/repository-name-committers-archive на машинах кластера FreeBSD.org). Отчеты Правления /home/core/public/monthly-report на машинах кластера FreeBSD.org. Наиболее значимые метки CVS RELENG_4 (ветвь 4.X-STABLE), RELENG_5 (ветвь 5.X-STABLE), + RELENG_6 (ветвь 6.X-STABLE), HEAD (ветвь -CURRENT) Для авторизации на машины проекта вы должны использовать протоколы &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;, загляните в раздел . Типы коммит битов CVS Репозиторий FreeBSD состоит из нескольких разделов, охватывающих исходные тексты базовой операционной системы, документацию, инфраструктуру построения внешних приложений (портов), а также различные служебные утилиты. Право записи в репозиторий (коммит бит) подразумевает указание области дерева, в которое оно может быть применено. Как правило, области напрямую связаны с группой, подтвердившей право коммиттера на бит. В дальнейшем, область действия коммит бита может быть расширена; в этом случае, коммиттер должен следовать стандартным правилам нового для коммиттера в данной области, в частности, получая подтверждения на каждый коммит и, возможно, в течение какого-то времени работу с ментором. Тип коммит бита Ответственные Области репозитория src core@ src/ и соответствующие части doc/ doc doceng@ doc/, www/, документация дерева src/ ports portmgr@ ports/ Биты, выделенные до разделения дерева на области могут использоваться во всех частях дерева. Однако, с точки зрения здравого смысла, коммиттер, не имеющий опыта работы в какой-либо части дерева, должен предоставлять предлагаемые изменения для рассмотрения другими коммиттерами, получать подтверждения от ответственных за различные части репозитория, а также, возможно, работать совместно с ментором. Поскольку правила ведения различных областей кода различаются, указанные нормы скорее направлены на благо коммиттера, не имеющего достаточного опыта работы в данной области. Вне зависимости от области приложения усилий, запросы коммиттеров на рассмотрение предлагаемых изменений в процессе разработки могут только приветствоваться. Правила для коммиттеров документации (<filename>doc/</filename>) при работе с деревом исходных текстов (<filename>src/</filename>) Коммиттеры документации могут самостоятельно изменять документацию к исходным текстам, например, страницы справочника, файлы README, базы данных утилиты fortune, календарей, а также исправлять комментарии в исходных текстах без дополнительного согласования с коммиттерами исходных текстов, при условии сохранения здравого смысла и манеры коммитов. Коммиттеры документации могут вносить незначительные изменения и исправления в исходные тексты (такие как исправления к процессу сборки, добавление малых дополнительных возможностей и т.п.) при наличии одобрения от коммиттера исходных текстов. Коммиттер документации может расширить область действия своего бита на область исходных текстов (и стать, таким образом, коммиттером исходных текстов), найдя себе ментора, который предложит это расширение Правлению (Core). После одобрения, строка с его именем пользователя вносится в файл 'access', и применяются обычные правила периода работы с ментором, подразумевающие получение одобрения на каждый коммит. Одобрение коммита ("Approved by") может производиться только "полновесным" (не работающим с ментором) коммиттером исходных текстов; последние могут рассматривать предлагаемые изменения и указываться в строке "Reviewed by". Работа с CVS Подразумевается, что вы уже имеете опыт базовой работы с CVS. &a.cvsadm; являются владельцами репозитория CVS и ответственны за все прямые его изменения (в целях чистки или исправления каких-либо вопиющих ошибок коммиттеров при работе с CVS). Если в результате ваших действий с частью репозитория произошел несчастный случай, например, после неверной операции cvs import или cvs tag, пошлите письмо соответствующей подгруппе &a.cvsadm; (см. следующую таблицу) и сообщите о проблеме. В наиболее серьезных случаях, касающихся не только какой-либо части репозитория, а дерева CVS в целом, вы можете написать &a.cvsadm;. Пожалуйста, не надо писать группе &a.cvsadm; по поводу репозиторного копирования и прочих вопросов, которые может решить соответствующая подгруппа. Напрямую изменять содержимое репозитория может только группа CVS-мастеров; для обеспечения этого, только CVS-мастера имеют учетные записи на машинах, поддерживающих основной репозиторий. Адреса, на которые следует посылать запросы, зависят от области репозитория, которую требуется поправить: ncvs@ - репозиторий /home/ncvs, основные исходные тексты pcvs@ - репозиторий /home/pcvs, порты dcvs@ - репозиторий /home/dcvs, документация projcvs@ - репозиторий /home/projcvs, прочие проекты Дерево CVS в настоящее время разделено на четыре независимых репозитория: doc, ports, projects и src. Для удобства работы пользователей при распространении через CVSup различные деревья комбинируются в одно, с одним служебным каталогом CVSROOT. Обратите внимание, что модуль www, содержащий исходные тексты веб-сайта FreeBSD, расположен в репозитории doc. В настоящее время, все репозитории CVS располагаются на одной машине, ncvs.FreeBSD.org, однако, для обеспечения возможности в будущем разнести их по физически различным машинам, для каждой поддерживается отдельное имя хоста. Их и следует использовать коммиттерам. Наконец, каждый репозиторий расположен в отдельном каталоге. В итоге, общая картина выглядит так: Репозитории CVS &os;, хосты и каталоги Репозиторий Хост Каталог doc dcvs.FreeBSD.org /home/dcvs ports pcvs.FreeBSD.org /home/pcvs projects projcvs.FreeBSD.org /home/projcvs src ncvs.FreeBSD.org /home/ncvs
Операции с CVS производятся удаленно, путем установки переменной окружения CVSROOT (она должна указывать на соответствующий хост и каталог верхнего уровня, например ncvs.FreeBSD.org:/home/ncvs), значения переменной CVS_RSH в ssh и последующего выполнения команд выгрузки и коммита. Многие коммиттеры определяют команды-синонимы, разворачивающиеся в запуск cvs с правильными параметрами. В частности, пользователи оболочки &man.tcsh.1; могут добавить следующие строки в свой скрипт начальной загрузки .cshrc: alias dcvs env CVS_RSH=ssh cvs -d user@dcvs.FreeBSD.org:/home/dcvs alias pcvs env CVS_RSH=ssh cvs -d user@pcvs.FreeBSD.org:/home/pcvs alias projcvs env CVS_RSH=ssh cvs -d user@projcvs.FreeBSD.org:/home/projcvs alias scvs env CVS_RSH=ssh cvs -d user@ncvs.FreeBSD.org:/home/ncvs Теперь все операции с CVS могут выполняться на локальной машине, а для внесения изменений в официальное дерево CVS следует использовать Если вам нужно добавить в проект что-либо совершенно новое (например, исходные тексты сторонних разработчиков), нужно использовать команду cvs import; обратитесь к странице справочника по &man.cvs.1; за подробностями. Пожалуйста, не используйте команды cvs checkout или cvs update для синхронизации ваших исходных текстов. Протокол CVS не оптимизирован для удаленной работы и требует значительных накладных расходов со стороны сервера. Пожалуйста, используйте метод синхронизации посредством cvsup, а основной хост используйте только для собственно коммитов. Наша распределенная сеть серверов cvsup достаточно развита. При необходимости синхронизации с самыми свежими изменениями вы можете пользоваться машиной cvsup-master, которая обладает достаточными ресурсами для удаленной работы с CVS; за нее отвечает &a.kuriyama;. Если вам нужно использовать команды CVS add и delete, так чтобы в реальности переместить часть исходных текстов подобно действию команды &man.mv.1;, нужно запросить операцию репозиторного копирования (repository copy). При этом кто-либо из CVS-мастеров скопирует необходимые файлы внутри репозитория на нужное место и даст вам знать об этом. Репозиторное копирование производится для сохранения истории (журналов изменения). Возможность отследить историю изменений очень ценна для всего проекта FreeBSD. Документация по CVS, учебные материалы и FAQ можно найти по адресу: . Очень полезна также книга Карла Фогеля (Karl Fogel) Open Source Development with CVS. Некоторая полезная информация о CVS на русском языке может быть найдена здесь. &a.des; написал такой мини-пример работы с CVS: Извлечение нужного модуля из репозитория: команда co или checkout. &prompt.user; cvs checkout shazam Эта команда извлечет копию модуля shazam. Если модуль с таким именем не существует (не описан в файле modules), будет произведена попытка извлечь директорию верхнего уровня shazam. Полезные опции команды <command>cvs checkout</command> Не создавать (точнее, удалить после завершения выполнения) пустые каталоги Извлекать один уровень каталогов (без подкаталогов) Извлечь ревизию, ветвь или тег rev для указанного модуля Извлечь состояние модуля в репозитории на момент date
Примеры в применении к FreeBSD: Извлечь модуль miscfs, расположенный в каталоге репозитория src/sys/miscfs: &prompt.user; cvs co miscfs После выполнения вы получите каталог miscfs, содержащий подкаталоги CVS, deadfs, devfs и т.д. Один из них (linprocfs) будет пустым. Извлечь те же файлы, но с полным путем: &prompt.user; cvs co src/sys/miscfs Теперь у вас есть каталог src, содержащий подкаталоги CVS и sys. Каталог src/sys содержит подкаталоги CVS и miscfs и т.д. Извлечь те же файлы, удалив при этом пустые подкаталоги: &prompt.user; cvs co -P miscfs Вы получите каталог miscfs с подкаталогами CVS, deadfs, devfs... однако без подкаталога linprocfs, поскольку он не содержит файлов. Извлечь каталог miscfs без подкаталогов: &prompt.user; cvs co -l miscfs Теперь в каталоге miscfs будет только один подкаталог CVS. Извлечь модуль miscfs из ветви 4.X: &prompt.user; cvs co -rRELENG_4 miscfs Теперь вы можете изменить исходные тексты и произвести коммит в эту ветвь. Извлечь модуль miscfs по состоянию на момент выхода 3.4-RELEASE: &prompt.user; cvs co -rRELENG_3_4_0_RELEASE miscfs В этом случае вы не сможете внести изменения в репозиторий, поскольку RELENG_3_4_0_RELEASE описывает момент времени, а не ветвь разработки. Извлечь модуль miscfs по состоянию на 15 января 2000 г: &prompt.user; cvs co -D'01/15/2000' miscfs Как и в предыдущем случае, изменения не могут быть записаны. Извлечь модуль miscfs, каким он был неделю назад: &prompt.user; cvs co -D'last week' miscfs И вновь, изменения не могут быть записаны. Обратите внимание, что мета-данные хранятся в подкаталогах CVS. Аргументы опций and сохраняются (являются клейкими, sticky), например, при последующем использовании команды cvs update. Проверка состояния извлеченных файлов: команда status. &prompt.user; cvs status shazam Эта команда покажет статус файла shazam или каждого файла в директории shazam. Для каждого из файлов статус может быть одним из: Up-to-date Файл соответствует репозиторию и не модифицировался Needs Patch Файл не изменялся, но репозиторий содержит обновленную версию Locally Modified Файл соответствует репозиторию, но был изменен локально Needs Merge Файл изменен локально; вместе с тем, файл изменен и в репозитории File had conflicts on merge После последнего обновления возникли конфликты, и они все еще не устранены Кроме того, будут показаны локальная версия и дата модификации, версия и дата последней из доступных (если вы применяли клейкие дату, тег или ветвь, последняя доступная версия может отличаться от вашей), а также клейкие теги, временные метки и опции. Обновление извлеченного модуля: команда update. &prompt.user; cvs update shazam Эта команда обновит состояние файла shazam или файлов в каталоге shazam до наиболее свежих версий выбранной вами при извлечении ветви. Если выбирался момент времени, не произойдет ничего, если только за истекшее время в репозитории не был перемещен тег или не произошло чего-нибудь еще непредвиденного. Полезные опции в дополнение к уже описанным для команды checkout: Извлечь вновь появившиеся или пропущенные ранее подкаталоги Обновиться до текущего состояния головной ветви магическая опция (см. ниже) Если вы извлекали модуль с опциями или , выполнение команды cvs update с другими параметрами или или с опцией приведет к выбору новой ветви, ревизии или даты. Использование опции удаляет использованные ранее клейкие свойства; опции и , наоборот, фиксируют их. Теоретически использование HEAD в качестве аргумента опции должно дать тот же результат, что и указание опции , однако это верно лишь в теории. Опция полезна, если: после извлечения вами модуля кем-либо еще в него были добавлены дополнительные каталоги; вы извлекали верхний уровень модуля при помощи опции , а в дальнейшем решили извлечь и подкаталоги; вы удалили какие-либо подкаталоги и теперь хотите вновь извлечь их. Обращайте внимание на вывод команды cvs update. Действие, произведенное с файлом, обозначается буквой перед его именем: U Файл был успешно обновлен. P Файл был успешно обновлен (произведен успешный патч из удаленного репозитория). M Файл был изменен, и при этом обновлен успешно. C Файл был изменен, и при объединении изменений возникли конфликты. Объединение (merging) производится, если вы выгрузили рабочую копию какого-то модуля, изменили его, затем кто-либо еще произвел коммит собственных изменений, и, наконец, вы выполняете команду cvs update. CVS знает, что производились локальные изменения, и пытается объединить ваши изменения с теми, что произошли в репозитории (от состоянии версии, которую вы выгружали, до версии, до которой вы пытаетесь обновиться). Если изменения происходили с различными частями файла, объединение почти всегда произойдет успешно (хотя результат при этом может не быть синтаксически или семантически корректным). CVS выводит букву M перед именем всех локально измененных файлов, даже если у них нет новых версий в репозитории, так что команда cvs update удобна для быстрого получения списка файлов, которые вы изменяли. Если в результате вы видите букву C, ваши изменения конфликтуют с изменениями, внесенными в репозиторий (изменения были в одних и тех же или рядом расположенных строках, либо вы изменили файл настолько, что при сравнении cvs не смогла удержать контекст и приложить изменения из репозитория). Вам необходимо устранить конфликты, вручную редактируя файл. Конфликтующие фрагменты помечаются строками из знаков <, = и >. В начале каждого из конфликтов присутствует строка из семи знаков < и имени файла, затем идет фрагмент, содержащий внесенные вами изменения, разделитель из семи знаков =, соответствующий фрагмент из версии файла, содержащейся в репозитории, и, наконец, строка из семи знаков > совместно с номером версии, до которой вы обновляли файл. Опция содержит некоторое количество черной магии. При ее наличии локальный файл обновляется до указанной версии так же, как и при использовании опции , но отслеживаемые номер версии или ветвь не изменяются. Эта опция умеет смысл лишь при парном использовании: при этом делается попытка применить изменения между двумя указанными версиями к локальной копии файла. К примеру, вы внесли изменения и произвели коммит в файл shazam/shazam.c в &os.current;, а позднее хотите перенести обновления в &os.stable; (Merge-From-Current, MFC). Версия, которая требует переноса — 1.15: Извлеките текущую версию модуля shazam для ветви &os.stable;: &prompt.user; cvs co -rRELENG_5 shazam Приложите изменения между версиями 1.14 и 1.15: &prompt.user; cvs update -j1.14 -j1.15 shazam/shazam.c Почти наверняка вы получите конфликт в строках, содержащих - идентификатор файла ($Id: article.sgml,v 1.11 2005-09-25 06:48:30 marck Exp $ или, в случае FreeBSD, + идентификатор файла ($Id: article.sgml,v 1.12 2006-02-05 17:55:22 marck Exp $ или, в случае FreeBSD, $FreeBSD$). Вам потребуется отредактировать файл для устранения конфликта (в данном случае достаточно убрать строки-разделители и вторую строку - $Id: article.sgml,v 1.11 2005-09-25 06:48:30 marck Exp $, оставив лишь строку с $Id: article.sgml,v 1.11 2005-09-25 06:48:30 marck Exp $ + $Id: article.sgml,v 1.12 2006-02-05 17:55:22 marck Exp $, оставив лишь строку с $Id: article.sgml,v 1.12 2006-02-05 17:55:22 marck Exp $ для &os.stable;). Просмотр изменение между локальной версией и версией из репозитория: команда diff. &prompt.user; cvs diff shazam Эта команда покажет все отличия локального состояния файла (или файлов модуля) shazam от состояния, сохраненного в репозитории. Полезные опции команды <command>cvs diff</command> Использовать унифицированный (unified) формат. Использовать контекстный (context) формат. Показывать отсутствующие или созданные файлы.
Всегда имеет смысл пользоваться опцией , поскольку унифицированный формат гораздо удобнее и лучше читаем, чем почти все другие (в некоторых случаях контекстный формат, генерируемый опцией может быть несколько лучше, но он гораздо более громоздок). Унифицированный формат различий состоит из серии фрагментов, каждый из которых начинается со строки, состоящей из двух символов @ и номеров строк, описывающих положение изменившегося участка. Затем следует группа строк: те, что начинаются с пробела, описывают контекст, начинающиеся с символа - определяют удаленные строки, наконец, начинающиеся с символа + — добавленные. Вы можете сравнивать текущее состояние с версией, отличающейся от той, с которой вы извлекали файл, указав опцию или подобно командам checkout и update, или даже получить список изменений между любыми двумя версиями (вне зависимости от того, что лежит в вашей локальной копии), указав две версии при помощи опций или . Просмотр журнала изменений: команда log. &prompt.user; cvs log shazam Если shazam является обычным файлом, эта команда выдаст на экран заголовок с информацией о файле, в частности, его местоположении в репозитории, какая версия соответствует текущему состоянию (HEAD), в каких ветвях разработки файл присутствует, а также перечислит теги, которыми он помечен. Затем, для каждой версии файла выводится соответствующее ей журнальное сообщение, включающее дату, время и автора коммита, количество добавленных и удаленных строк и собственно журнального сообщения, написанного коммиттером. Если shazam является каталогом, вышеописанная процедура выполняется для каждого файла в каталоге. Если при этом команде log не был указан флаг , процедура рекурсивно повторяется для всех подкаталогов. Команда log используется для просмотра истории одного или нескольких файлов в том виде, как она сохранена в репозитории CVS. Используя опцию , вы можете посмотреть журнальное сообщение к одной определенной версии: &prompt.user; cvs log -r1.2 shazam Эта команда покажет журнальное сообщение для версии 1.2 файла shazam (или для версий 1.2 каждого из файлов в каталоге shazam). Кто что делал: команда annotate. Эта команда показывает перед каждой строкой указанного файла (файлов) имя пользователя, вносившего последние изменения в эту строку. &prompt.user; cvs annotate shazam Добавление новых файлов: команда add. Создайте файл, выполните для него команду cvs add, затем произведите запись в репозиторий (коммит): cvs commit. Точно так же, новые каталоги добавляются в репозиторий путем создания и последующего выполнения команды cvs add. Заметьте, что выполнять коммит после добавления каталога не надо. Удаление устаревших файлов: команда remove. Удалите файл, затем выполните команду cvs rm с его именем в качестве параметра, наконец, выполните для него cvs commit. Внесение изменений в репозиторий: команда commit или checkin. Useful <command>cvs commit</command> options Форсировать внесение изменений для не модифицированного файла. Указать сообщение для журнала в командной строке (не запускать текстовый редактор).
Опцию следует использовать, если вы поняли, что забыли указать какую-либо важную информацию в журнале изменений. Хорошие журнальные сообщения очень важны. Они дают возможность другим узнать, зачем вы производили изменения, причем не только в момент их произведения, но и месяцы или годы спустя, когда кто-либо заинтересуется, почему выглядящий нелогично или неэффективно фрагмент кода попал в каши исходные тексты. Кроме того, это очень помогает в оценке того, нужно ли переносить соответствующий код в &os.stable; (MFC). Сообщения должны быть ясными, краткими, четкими, и представлять из себя разумную аннотацию, какие изменения были произведены и почему. Сообщения должны достаточно ясно показывать сторонним разработчикам, насколько их касаются изменения и нужно ли им исследовать изменения подробно. Избегайте внесения нескольких не связанных друг с другом изменений за один раз. Это затрудняет объединение изменений, а также, при обнаружении ошибок, усложняет поиск ответственного за ошибки участка. Избегайте смешивания в одном коммите изменений функциональности со стилистическими правками или исправлениями в пробелах. Это усложняет объединение, и, кроме того, затрудняет понимание того, какие именно функциональные изменения были внесены. В случае коммита в файлы документации, это затруднит работу групп поддержки перевода, поскольку становится сложнее отделить изменения, требующие перевода. Избегайте коммита большой группы файлов за один раз с одним общим и невнятным сообщением. Напротив, вносите изменения в отдельные файлы (или небольшие группы связанных файлов) с адекватными сообщениями для журналирования. Перед коммитом, обязательно: проверьте, что вы будете выполнять коммит в правильную ветвь, посредством команды cvs status. проверьте ваши изменения при помощи команды cvs diff Кроме того, ВСЕГДА указывайте, в какие именно файлы вы вносите изменения, так чтобы не включить в этот список лишних файлов. Команда cvs commit без аргументов включит все измененные файлы в текущем каталоге и всех подкаталогах. Еще несколько полезных советов: Часто используемые опции можно занести в файл ~/.cvsrc, например: cvs -z3 diff -Nu update -Pd checkout -P Для данного случая: всегда использовать компрессию уровня 3 для связи с удаленным сервером CVS. В случае медленного соединения это избавит вас от лишней головной боли. всегда использовать опции (показывать добавленные или удаленные файлы) и (унифицированный формат) для &man.diff.1;. всегда использовать опции (удалять пустые каталоги) и (добавлять новые каталоги) при обновлении. всегда использовать опцию (удалять пустые каталоги) при извлечении файлов и модулей. Пользуйтесь скриптом Эйвинда Эклунда (Eivind Eklund) cdiff для просмотра изменению унифицированного формата. Он является оберткой для &man.less.1;, добавляющей цветовые коды ANSI для выделения заголовком, добавленных и удаленных строк; прочие строки не модифицируются. Помимо этого, скрипт корректно разворачивает табуляции (которые часто выглядят неправильно в изменениях из-за дополнительного символа в начале строки). textproc/cdiff Просто используйте его вместо &man.more.1; или &man.less.1;: &prompt.user; cvs diff -Nu shazam | cdiff Помимо этого, некоторые текстовые редакторы, такие как &man.vim.1; (editors/vim5) поддерживают цветовую синтаксическую разметку многих типов файлов, в том числе файлов изменений и журналов CVS/RCS. &prompt.user; echo "syn on" >> ~/.vimrc &prompt.user; cvs diff -Nu shazam | vim - &prompt.user; cvs log shazam | vim - CVS — старая, загадочная и порой слабо предсказуемая в своем поведении программа. Ни один человек не способен удержать в голове все тонкости ее работы, так что не бойтесь спрашивать совета у Искусственного Интеллекта (а именно &a.cvsadm;). Не оставляйте компьютер в процессе работы команды cvs commit (в редакторе при написании журнального сообщения) слишком надолго (более чем на 2–3 минуты). Эта команда блокирует каталог репозитория, в котором она запущена, и не позволяет другим разработчикам изменять его содержимое. Если вам нужно написать длинное журнальное сообщение, подготовьте его заранее и вставьте в редакторе во время выполнения команды cvs commit, либо запишите его в файл и используйте опцию CVS : &prompt.user; vi logmsg &prompt.user; cvs ci -F logmsg shazam Это самый быстрый способ передать журнальное сообщение CVS; однако, вы должны быть внимательны при редактировании файла logmsg, поскольку при выполнении коммита у вас не будет шансов его поправить. Соглашения и традиции Став коммиттером, вы должны прежде всего произвести некоторые стандартные действия. Добавьте себя в список SGML сущностей авторов в файл doc/en_US.ISO8859-1/share/sgml/authors.ent; это изменение должно быть сделано прежде прочих, поскольку в противном случае следующий ваш коммит неизбежно разрушит процесс построения дерева doc/. Это довольно простая задача, но при этом она является неплохим первым тестом ваших навыков работы с CVS. Добавьте себя в раздел Разработчики статьи Участники проекта FreeBSD и удалите свою запись из раздела Прочие участники. Добавьте новость о новом коммиттере в файл www/en/news/news.xml. Используйте существующие записи вида Новый коммиттер как шаблон. Вам нужно добавить ваш PGP или GnuPG ключ в каталог doc/share/pgpkeys (а если у вас нет ключа, вам нужно его создать). Не забудьте изменить и произвести коммит в файл doc/share/pgpkeys/pgpkeys.ent. &a.des; написал скрипт для упрощения этого процесса. Дополнительную информацию можно прочесть в файле README. Очень важно, чтобы в Руководстве пользователя был записан актуальный PGP/GnuPG ключ, поскольку он может потребоваться для идентификации коммиттера (например, его будет проверять группа &a.admins; для аварийного восстановления учетной записи). Полный набор актуальных ключей пользователей домена FreeBSD.org можно найти по адресу http://www.FreeBSD.org/doc/pgpkeyring.txt. Некоторые коммиттеры добавляют информацию о своем местоположении в файл ports/astro/xearth/files/freebsd.committers.markers. Некоторые добавляют данные о дне своего рождения в файл src/usr.bin/calendar/calendars/calendar.freebsd. Представьтесь другим коммиттерам, иначе никто не будет знать, кто вы и чем занимаетесь. От вас не требуется писать подробное резюме или биографию: будут достаточны один-два абзаца о себе и областях FreeBSD, в которых вы планируете работать. Пошлите это письмо в &a.developers; — и все! Зайдите на машину hub.FreeBSD.org и создайте файл /var/forward/user (замените user на ваше имя пользователя). Этот файл должен содержать адрес электронной почты, на который будет переправляться вся почта на адрес yourusername@FreeBSD.org, в том числе сообщения о коммитах и другая почта на адреса &a.committers; и &a.developers;. Слишком большие почтовые ящики на машине hub могут быть нечаянно удалены или обрезаны без предупреждения, так что, чтобы не потерять почту, регулярно читайте ее либо перенаправьте куда-нибудь еще. Из-за ощутимой загрузки, возникающей на серверах, обрабатывающих списки рассылки, из-за большого количества незапрошенной почты (спама), сервер, принимающий почту для домена FreeBSD.org, производит некоторые основные проверки и на основании их отвергает некоторые письма. На настоящий момент единственным проверяемым параметром является корректность информации DNS для хоста, доставляющего почту, но в будущем список может вырасти. Эти проверки временами обвиняют в том, что они отвергают правильную почту. Если вы хотите отключить проверки для своего адреса, создайте файл ~/.spam_lover в своей домашней директории на машине freefall.FreeBSD.org. Если вы были подписаны на &a.cvsall;, вам, скорее всего, следует отписаться от него, чтобы не получать дубликатов каждого сообщения о коммитах. Все новые коммиттеры первоначально работают под руководством ментора. Ваш ментор отвечает за обучение вас правилам и соглашениям, принятым в проекте, и помогает вам сделать первые шаги в среде коммиттеров. Он(а) также персонально отвечает за ваши действия в этот начальный период. До тех пор, пока ваш ментор не решит (и не анонсирует это посредством форсированного коммита файла access), что вы достаточно освоились и готовы работать самостоятельно, перед любым коммитом вы должны получить одобрение (approval) ментора и указать это в журнальном сообщении коммита строкой Approved by:. Все коммиты в дерево src сначала должны производиться в ветвь &os.current; и лишь затем интегрироваться в &os.stable;. Никакие серьезные изменения, новые возможности или рискованные модификации не должны производиться напрямую в ветви &os.stable;. Предпочтительная лицензия для новых файлов В настоящее время Проект &os; считает предпочтительной формой лицензии на исходные тексты следующий текст: Copyright © <Year> <Author>. 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 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 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. Проект &os; крайне не рекомендует так называемый третий пункт, или пункт о рекламе в лицензии на новый исходный код. В связи с большим количеством участников проекта &os;, выполнение этого пункта большинством коммерческих производителей все более затруднительно. Если ваш код в дереве исходников содержит пункт о рекламе, рассмотрите возможность его удаления. На самом деле, рассмотрите возможность перехода на приведенную лицензию. Проект &os; не рекомендует использование полностью новых лицензий или вариаций стандартных лицензий. Новые лицензии перед использованием в репозитории проекта требуют утверждения группой core@FreeBSD.org. Большое число различных лицензий затрудняет использование кода, в основном из-за ненамеренных неверных выводов из плохо сформулированных формулировок лицензии. Взаимодействие между разработчиками Если вы работаете над собственным исходным кодом, либо в области, в которой вы уже определены как ответственная персона, вам, скорее всего, не потребуется согласовывать коммит с кем-либо еще из разработчиков. Те же правила действуют, если вы нашли ошибку в той части системы, которой явно давно никто не занимается (к нашему стыду, существует несколько таких областей). Если же вы собираетесь модифицировать что-либо активно поддерживаемое (по-хорошему, узнать это можно только исследуя архивы списка рассылки cvs-committers), стоит послать предполагаемый патч ответственному за этот участок кода, как вы бы поступали, пока не были коммиттером. В случае портов нужно обращаться по адресу, указанному в строке MAINTAINER в файле Makefile. Для других частей репозитория, в случае если вам не очевидно, кто ведет данный участок кода, может помочь исследование вывода команды cvs log. &a.fenner; написал отличный скрипт для определения разработчиков, наиболее активно производивших коммиты, выводящий для каждого из указанных файлов имя пользователя вместе с количеством произведенных им коммитов в данный файл. Скрипт можно найти на машине freefall в файле ~fenner/bin/whodid. Если найденная вами персона не отвечает на ваши вопросы или иным образом демонстрирует отсутствие интереса к проблеме, смело производите коммит самостоятельно. Если вы по каким-либо причинам не уверены в своих изменениях, предложите их для оценки в списке рассылки -hackers перед коммитом. Будет лучше, если вас обругают там и тогда, чем когда предлагаемое изменение уже будет частью репозитория. Если случилось так, что ваш коммит встретил сопротивление, возможно, стоит его откатить (back out) до тех пор, пока не будет достигнут консенсус. Помните — с помощью CVS всегда можно вернуться к предыдущему состоянию. Не принимайте в штыки мнения других разработчиков, с которыми вы не согласны. Если они предлагают иное решение проблемы чем вы, или даже иначе воспринимают проблему, это не значит, что они глупы, имеют сомнительное происхождение, хотят разрушить вашу работу, очернить ваше доброе имя, или развалить проект FreeBSD. Просто они смотрят на мир под иным углом. Различные взгляды — благо. Будьте честны в спорах. Оценивайте свою позицию по заслугам, честно относитесь к ее слабым сторонам и будьте готовы принять другие точки зрения и пути решения. Будьте открыты. Будьте терпимы, если вас поправляют. Все мы совершаем ошибки. Если вы ошиблись, извинитесь. Не обвиняйте ни себя, ни, тем более, других в ошибке. Не теряйте времени на смущение или упреки, просто исправьте ошибку и двигайтесь дальше. Спрашивайте и просите о помощи. Предлагайте ваши изменения для рассмотрения коллегам и рассматривайте их изменения. Одним из преимуществ программного обеспечения с открытыми исходными текстами является открытость разработки. Если никто не будет исследовать чужой код, это преимущество исчезнет. GNATS Для отслеживания ошибок и запросов на изменения проект FreeBSD использует GNATS. Если вы исправили ошибку или внесли изменения, описанные в одном из сообщений об ошибках (PR), не забудьте закрыть это сообщение, используя команду edit-pr pr-number на машине freefall. Хорошо будет, если вы потратите немного времени на поиск и закрытие других PR по этой теме. Вы и сами можете пользоваться &man.send-pr.1; для предложения изменений, которые, по вашему мнению, могут потребовать более подробного обсуждения с коллегами. Более подробно о GNATS можно прочитать по адресам: http://www.FreeBSD.org/support.html &man.send-pr.1; Вы можете пользоваться локальной копией GNATS, поддерживая ее синхронность при помощи CVSup. При этом вы можете использовать команды GNATS локально, а также пользоваться другими интерфейсами, такими как tkgnats, что позволит вам работать с базой сообщений об ошибках без соединения с Интернет. Использование локальной копии GNATS Если вы еще не поддерживаете зеркало дерева GNATS, добавьте в ваш supfile строку gnats release=current prefix=/usr Учтите, что эта строка должна предшествовать любым строкам, содержащим параметр tag=, поскольку дерево GNATS не находится под управлением CVS и не имеет символьных меток. После запуска cvsup в каталоге /usr/gnats будет создана копия дерева GNATS FreeBSD. Вы можете использовать файл refuse для копирования отдельных категорий. Например, если вас интересуют только сообщения категории docs, добавьте в файл /usr/local/etc/cvsup/sup/refuse Точный путь к файлу зависит от установок *default base в вашем файле supfile. строку gnats/[a-ce-z]* Прочие примеры в этом разделе подразумевают, что вы синхронизируете только категорию docs. Установите порт GNATS из ports/databases/gnats. После установки вы обнаружите различные служебные каталоги в дереве $PREFIX/share/gnats. Создайте символьные ссылки на синхронизированные каталоги GNATS в служебный каталог GNATS: &prompt.root; cd /usr/local/share/gnats/gnats-db &prompt.root; ln -s /usr/gnats/docs Проделайте эту операцию для всех синхронизируемых категорий. Обновите служебный файл GNATS categories, расположенный в каталоге $PREFIX/share/gnats/gnats-db/gnats-adm: # This category is mandatory pending:Category for faulty PRs:gnats-admin: # # FreeBSD categories # docs:Documentation Bug:freebsd-doc: Запустите $PREFIX/libexec/gnats/gen-index для создания индекса. Вывод этой команды должен быть перенаправлен в файл $PREFIX/share/gnats/gnats-db/gnats-adm/index. Эту операцию можно выполнять периодически при помощи &man.cron.8; или запускать &man.cvsup.1; из скрипта, который затем сгенерирует новый индекс: &prompt.root; /usr/local/libexec/gnats/gen-index \ > /usr/local/share/gnats/gnats-db/gnats-adm/index Протестируйте созданную конфигурацию запросом к базе данных GNATS. Следующая команда выведет список открытых сообщений об ошибках в категории docs: &prompt.root; query-pr -c docs -s open Другие интерфейсы, например, порт databases/tkgnats также должны работать. Выберите PR и закройте его. Описанная процедура позволяет вам выбирать и просматривать сообщения об ошибках локально. Для редактирования или закрытия вам потребуется зайти на машину freefall. Кто есть кто Помимо мастеров репозитория, существует еще несколько участников и групп проекта FreeBSD, с которыми вам как коммиттеру может потребоваться общаться. Краткий и ни в коем случае не полный список приводится ниже. &a.jhb; Джон возглавляет проект SMPng и отвечает за архитектуру, дизайн и реализацию перехода на многонитевое ядро. Джон также является редактором статьи "Архитектура SMPng". Если вы работаете с тонкими блокировками многопроцессорного ядра, координируйте свою работу с Джоном. Дополнительную информацию о проекте SMPng можно получить по адресу &a.jake;, &a.tmm; Джейк и Томас отвечают за портирование FreeBSD на архитектуру &sparc64;. &a.doceng; doceng — группа, отвечающая за инфраструктуру построения документации, прием новых коммиттеров документации и актуальность информации относительно CVS на веб-сайте и FTP-сайте FreeBSD. Эта группа не разбирает конфликты. Большая часть обсуждений, связанных с документацией, происходит в &a.doc;. Дополнительную информацию о деятельности группы можно найти в ее собственном документе. Коммиттеры, заинтересованные в обновлении документации, должны ознакомиться с Учебником по Проекту Документирования FreeBSD для новых участников. &a.ru; Руслан великолепно знает тонкости &man.mdoc.7;. Если вы пишете справочную страницу и нуждаетесь в совете по ее структуре или разметке, обратитесь к Руслану. &a.bde; Брюс занимается общим стилем кода проекта. Если ваш коммит мог бы быть лучше оформлен, Брюс укажет вам на это. Радуйтесь, что такой человек вообще есть. Брюс также является знатоком различных стандартов, применимых к FreeBSD. &a.gallatin; &a.mjacob; &a.dfr; &a.obrien; Эти коммиттеры являются основными разработчиками платформы DEC Alpha AXP. &a.dg; Дэвид следит за подсистемой виртуальных машин (VM). Если вы планируете изменять эту часть системы, координируйте ваши усилия с Дэвидом. &a.dfr; &a.marcel; &a.peter; &a.ps; Эта группа является основными разработчиками платформы Intel IA-64, официально именуемой &itanium; Processor Family (IPF). &a.murray; &a.dwhite; &a.rwatson; &a.jhb; &a.scottl; &a.kensmith; &a.hrs; Таков состав группы &a.re;. Эта группа отвечает за сроки и процесс выпуска релизов. В период заморозки кода, выпускающие инженеры принимают окончательные решения по поводу всех изменений системы в ветви, готовящейся к очередному релизу. Если вы хотите интегрировать какие-либо изменения из &os.current; в &os.stable; (какими бы они ни были в данный конкретный момент), вам предстоит общаться с этой группой. Хироки, кроме того, ведет раздел документации к релизам (src/release/doc/*). Если ваши изменения стоят того, чтобы быть упомянутыми в информации о релизе, сообщите об этом Хироки. Еще лучше, если вы пошлете патч с предлагаемыми изменениями к документу. &a.grehan; Питер является официальным ведущим порта &powerpc;. &a.brian; Брайан официально отвечает за /usr/sbin/ppp. &a.cperciva; Колин — FreeBSD Security Officer и отвечает за деятельность группы &a.security-officer;. &a.wollman; Если вам нужен совет по поводу темных мест сетевой части ядра, или вы не уверены в планируемом изменении сетевой подсистемы, мудрым решением будет обратиться к Гарретту. Помимо того, он хорошо разбирается в различных стандартах, применимых к FreeBSD. &a.committers; cvs-committers — адрес, используемый CVS для посылки сообщений о коммитах. Вы никогда не должны посылать письма напрямую на этот адрес; следует лишь отвечать на него, когда вам нужно послать короткие комментарии, непосредственно относящиеся к коммиту. &a.developers; Все коммиттеры подписаны на список рассылки -developers. Этот список создан для обсуждения вопросов, касающихся сообщества коммиттеров FreeBSD, таких как выборы Правления, анонсы и т.п. &a.developers; служит для только для использования FreeBSD коммиттерами. Коммиттеры должны иметь возможность публично обсуждать вещи, которые должны быть разрешены, перед тем, как они будут публично объявлены. Данные дискуссии не предназначены для широкой публики и могут нанести вред FreeBSD. Все FreeBSD коммиттеры должны соблюдать авторские права оригинального автора или авторов писем из этого списка рассылки. Не публикуйте и не пересылайте сообщения из &a.developers; вне подписчиков данного списка рассылки без согласия всех авторов. Нарушители авторских прав будут удалены из списка подписчиков &a.developers;, и будут приостановлены их коммиттерские привилегии. Повторяющиеся или вопиющие нарушения приведут к полному лишению коммиттерских прав. Этот список не предназначен для обсуждения кода, и не является заменой списков &a.arch; или &a.audit;. На самом деле, такое его использование вредит проекту, поскольку открытые обсуждения вопросов, касающихся всего сообщества пользователей FreeBSD в закрытом списке недопустимы. И, наконец: никогда, действительно никогда не пишите в &a.developers; с копией в другой список рассылки FreeBSD. Никогда не пишите в какой-либо другой список рассылки с копией в &a.developers;. Подобные действия серьезно подрывают смысл существования данного списка рассылки. SSH: быстрый старт Если вы используете FreeBSD версии 4.0 или более позднюю, OpenSSH включен в базовую поставку системы. Для более ранних версий необходимо установить один из портов SSH. Скорее всего вам потребуется порт OpenSSH (security/openssh). Возможно, вы захотите поставить оригинальный порт ssh1 (security/ssh), однако не забудьте обратить внимание на его лицензию. Отметим, что оба порта не могут быть установлены одновременно. Для тех, кто не хочет набирать свой пароль каждый раз при использовании &man.ssh.1; и использует для авторизации ключи RSA или DSA, удобной будет утилита &man.ssh-agent.1;. Если вы собираетесь использовать ее, убедитесь, что она запущена раньше прочих приложений. Пользователи X Window, например, обычно запускают ее из файлов .xsession или .xinitrc. Подробнее смотрите в справочной странице &man.ssh-agent.1;. Создайте пару ключей при помощи &man.ssh-keygen.1;. Ключи появятся в каталоге $HOME/.ssh/. Пошлите ваш публичный ключ (содержимое файла $HOME/.ssh/id_dsa.pub или $HOME/.ssh/id_rsa.pub) вашему будущему ментору, чтобы он мог быть помещен в файл yourlogin в каталоге /c/ssh-keys/ на машине freefall. Теперь вы можете пользоваться утилитой &man.ssh-add.1; для авторизации один раз за сессию. Утилита запросит кодовую фразу для вашего секретного ключа и затем сохранит ее в агенте авторизации (&man.ssh-agent.1;). Если вы хотите удалить сохраненный секретный ключ из агента, используйте команду ssh-add -d. Для теста используйте команду типа ssh freefall.FreeBSD.org ls /usr. За дополнительной информацией обращайтесь к security/openssh, &man.ssh.1;, &man.ssh-add.1;, &man.ssh-agent.1;, &man.ssh-keygen.1; и &man.scp.1;. Большой Список Правил Коммиттера FreeBSD Уважайте других коммиттеров. Уважайте других участников проекта. Обсудите любые значимые изменения до коммита. Уважайте существующих мейнтейнеров (указанных в поле MAINTAINER файлов Makefile или в файле MAINTAINER в корневом каталоге репозитория). Любое спорное изменение необходимо откатить (back out) в ожидании решения, если того требует мейнтейнер. Вопросы безопасности могут перекрывать мнение мейнтейнера, если так решит Security Officer. Изменения вносятся в ветвь &os.current; до &os.stable;, за исключением случаев, прямо разрешенных выпускающими инженерами или неприменимости изменения к &os.current;. Любое нетривиальное и не срочное изменение должно быть выдержано в &os.current; в течение по крайней мере 3 дней перед переносом, чтобы его могли адекватно протестировать. Выпускающие инженеры обладают той же властью в ветви &os.stable;, что и мейнтейнеры (см. правило 5). Не пререкайтесь с другими коммиттерами публично: это дурно выглядит. Если вам необходимо с чем-либо категорически не согласиться, делайте это личной почтой. Соблюдайте все периоды заморозки кода (core freeze), а также своевременно читайте списки рассылки committers и developers, чтобы быть в курсе расписания таких периодов. Если вы сомневаетесь в какой-либо процедуре, сначала спросите! Тестируйте свои изменения перед коммитом. Не производите коммит в деревья src/contrib, src/crypto и src/sys/contrib без прямого разрешения (approval) соответствующего мейнтейнера(ов). Невыполнение этих правил может служить основанием для приостановки или, в случае рецидивов, полного лишения коммиттерских прав. Члены Правления (Core) имеют право временно приостановить права коммиттера до момента, когда Правление в целом сможет решить вопрос. В аварийном случае (коммиттер разрушает репозиторий) такие права имеют также ответственные за репозиторий. Для приостановки прав коммиттера более чем на неделю или для полного лишения таковых прав требуется квалифицированное большинство (2/3) голосов Правления. Это правило существует не потому, что Правление состоит из злобных диктаторов, разбрасывающихся коммиттерами словно банками из-под колы, но ради предоставления проекту аварийного выключателя. Если кто-то выходит из-под контроля, важно иметь возможность справиться с ситуацией немедленно, а не быть втянутыми в дебаты. В любом случае, коммиттер, чьи права приостановлены, имеет право на слушания Правления, на которых определяется срок приостановки или лишения коммиттерских прав. Коммиттер, права которого приостановлены может запросить пересмотр своего вопроса через 30 дней и каждые последующие 30 дней (если общий период приостановки превышает 30 дней). Коммиттер, полностью лишенный прав, может запросить пересмотр по истечении 6 месяцев. Правила пересмотра являются полностью неформальными и во всех случаях Правление имеет право отвергнуть запрос на пересмотр, если считает свое первоначальное решение верным. Во всех прочих аспектах деятельности проекта, Правление является подмножеством коммиттеров и ограничено теми же правилами. Само по себе членство в Правлении не дает права преступать описанные правила. Правление обладает особой силой только в случае деятельность как целое, а не на индивидуальной основе. Члены Правления — в первую очередь коммиттеры. Подробности Уважайте других коммиттеров. Вы должны относиться к другим коммиттерам как к коллегам по разработке (кем они и являются). Несмотря на возникающие временами попытки утверждать обратное, никто не стал коммиттером по своей или чьей-либо еще глупости, и мало что обижает сильнее, чем подобные обвинения от коллег. Вне зависимости от того, всегда ли мы чувствуем уважение друг к другу или нет (у каждого бывают не лучшие дни), мы всегда должны выказывать уважение к другим коммиттерам, как в публичных форумах, так и в личной почте. Способность совместной работы в течение длительного времени — одно из главных достижений проекта, много более важное, чем любой набор изменений в коде, и никакие аргументы относительно кода не стоят потерь в возможности гармонично работать вместе. Чтобы не противоречить этому правилу, никогда не посылайте писем, когда вы злы или каким-либо иным образом можете спровоцировать других на конфронтацию. Сначала успокойтесь, затем подумайте о том, как наиболее эффективно убедить оппонента(ов) в правильности ваших аргументов; не подливайте масла в огонь ради краткого мига злорадства, если ценой будет долгая ругань. Это не просто крайне энергетически неэффективно: повторяющиеся прецеденты публичной агрессии, влияющие на нашу способность работать вместе, будут всерьез рассмотрены лидерами проекта, и могут привести к приостановке или потере прав коммиттера. Во внимание будут приниматься как публичные высказывания, так и личная переписка; это не означает, что Правление будет требовать раскрытия тайны переписки, однако, все предоставленные затронутыми коммиттерами материалы будут рассмотрены. Описанные процедуры никого не могут порадовать даже в малом, однако целостность проекта превыше всего. Никакой объем кода не стоит потери целостности. Уважайте других участников проекта. Вы не всегда были коммиттером. В свое время вы были простым сторонним участником (contributor). Помните об этом все время. Помните, сколь важно было добиться внимания и помощи. Не забывайте, насколько ваше участие было важным для вас. Помните свои ощущения. Не препятствуйте другим участникам и не унижайте их. Относитесь к ним с уважением. Возможно, они наши будущие коммиттеры, и они настолько же важны для проекта, как и коммиттеры. Их вклад в проект настолько же ценен и важен, как и ваш. В конце концов, вам пришлось приложить немало усилий для проекта, чтобы стать коммиттером. Всегда помните об этом. Обдумайте первое правило и применяйте его и к другим участникам проекта. Обсудите любые значимые изменения до коммита. Репозиторий CVS — не место для анонса изменений или обсуждения их. Все изменения должны обсуждаться в списках рассылки, и лишь после достижения консенсуса вносится в репозиторий. Это не означает, что вы должны спрашивать разрешения на исправление очевидной синтаксической ошибки в коде или опечатки в странице справочника. Вы должны ощутить, когда предполагаемое изменение требует предварительного обсуждения и обратной связи. Как правило, никто не станет возражать против обширных изменений, если результат очевидно лучше предыдущего состояния, однако никто не любит, когда эти изменения неожиданны. Лучший способ убедиться, что вы на правильном пути — дать ваш код просмотреть кому-либо еще из коммиттеров. Если вы сомневаетесь, просите отзыва! Уважайте существующих мейнтейнеров. Многие части кода FreeBSD не являются чьей-либо собственностью: ситуация, когда некто подпрыгнет и завопит, если вы внесете изменения в его код, редка; однако, всегда стоит предварительно проверить. Одним из используемых соглашений было добавление строки MAINTAINER в файл Makefile пакета или части дерева, которая активно поддерживается одним или несколькими коммиттерами; см. также соответствующий раздел Руководства разработчика. В случае, если какой-то участок системы имеет несколько мейнтейнеров, изменение его одним из них должно быть одобрено по крайней мере одним из других. В случаях, когда принадлежность кода неясна, вы можете взглянуть на историю коммитов, чтобы понять, кто наиболее активно либо в последнее время работал в этой области. Отдельные области FreeBSD попадают под контроль коммиттеров, занимающихся поддержкой целых категорий на пути эволюции FreeBSD, таких как локализация или сетевая подсистема. Для дополнительной информации смотрите http://www.FreeBSD.org/doc/en_US.ISO8859-1/articles/contributors/staff-who.html Любое спорное изменение необходимо откатить в ожидании решения, если того требует мейнтейнер. Вопросы безопасности могут перекрывать мнение мейнтейнера, если так решит Security Officer. Это может быть нелегко, особенно в период конфликта (когда каждый участник уверен, что прав именно он). К счастью, CVS дает возможность, вместо того чтобы вести бушующую перебранку, просто откатить внесенные изменения, успокоиться всем участникам конфликта, а затем попробовать найти взаимоприемлемый путь. Если в конце концов окажется, что изменение стоит того, оно может быть легко применено вновь. В противном случае, пользователям не придется жить с неправильным состоянием дерева исходных текстов, пока стороны заняты выяснением отношений. Запросы на откаты возникают редко, поскольку обсуждение обычно выявляет неверные или спорные моменты до коммита; однако, если такой запрос все же возник, он должен быть безусловно удовлетворен, чтобы мы могли спокойно выяснить, было изменение неверным или нет. Изменения вносятся в ветвь &os.current; до &os.stable;, за исключением случаев, прямо разрешенных выпускающими инженерами или неприменимости изменения к &os.current;. Любое нетривиальное и не срочное изменение должно быть выдержано в &os.current; в течение по крайней мере 3 дней перед переносом, чтобы его могли адекватно протестировать. Выпускающие инженеры обладают той же властью в ветви &os.stable;, что и мейнтейнеры (см. правило 5). Это еще одно не обсуждаемое правило: выпускающий инженер безусловно отвечает за последствия, если выясняется что внесенные изменения неверны. Уважайте эти права, и помогайте группе выпуска релизов в работе с ветвью &os.stable;. На первый взгляд может показаться, что ветвь &os.stable; развивается чересчур консервативно. Не забывайте, однако, что разумный консерватизм — отличительное свойство &os.stable;, и что эта ветвь развивается по законам, отличным от законов &os.current;. Кроме того, нет смысла тестировать изменения в &os.current;, если они немедленно переносятся в &os.stable;. Разработчики &os.current; должны иметь возможность протестировать внесенные изменения, так что оставьте время для такого тестирования, если только речь не идет о критическом исправлении или о чем-либо очевидно не требующем тестирования (например, исправления опечаток в страницах справочника, очевидных ошибок или опечаток в исходных текстах и т.п.) Иными словами, исходите из соображений здравого смысла. Изменения в ветви поддержки безопасности (security branches, например, RELENG_4_5) должны быть одобрены членом группы &a.security-officer; или, в некоторых случаях, одним из выпускающих инженеров (&a.re;). Не пререкайтесь с другими коммиттерами публично: это дурно выглядит. Если вам необходимо с чем-либо категорически не согласиться, делайте это личной почтой. Для всех участников проекта очень важно поддержание его публичного образа; особенно это важно, если мы хотим продолжать привлекать новых участников. Случается, что, несмотря на все усилия по сохранению власти над собой, люди срываются и грубят друг другу. Лучшее, что здесь можно сделать — минимизировать эффект, пока все участники не успокоятся. Следовательно, вы не должны озвучивать свою ярость публично, а равно и пересылать частную переписку в общедоступные списки рассылки. Выражения, употребляющиеся в переписке один на один зачастую гораздо менее сдержанны, чем те, которые каждый участник употребил бы публично, так что подобной переписке нет места в публичных рассылках: это лишь усугубит и без того неприятную ситуацию. Если кто-либо, говорящий вам нелицеприятные слова, делает это в частной переписке, соблюдайте приличия и вы: отвечайте приватно. Если, по вашему мнению, кто-либо из разработчиков поступает с вами нечестно, и это настолько мучит вас, обратитесь к Правлению, а не выносите конфликт наружу. Правление приложит все силы к разрешению ситуации, выступая в роли третейского судьи. В случаях, когда спор затрагивает какие-либо части кода, и участники не могут прийти к взаимно приемлемому соглашению, Правление может привлечь независимого участника для разрешения вопроса. В этом случае все участники конфликта должны согласиться принять решение, вынесенное третьей стороной. Соблюдайте все периоды заморозки кода (core freeze), а также своевременно читайте списки рассылки committers и developers, чтобы быть в курсе расписания таких периодов. Внесение не одобренных изменений в период заморозки кода является довольно большой ошибкой. Коммиттеры должны быть в курсе событий, прежде чем внести 10 мегабайт изменений после долгого отсутствия. Нарушающие это правило будут подвергаться заморозке коммиттерского бита до прохождения курса в Счастливом Лагере Повышения Квалификации FreeBSD, который организован в Гренландии. Если вы сомневаетесь в какой-либо процедуре, сначала спросите! Множество ошибок совершается, когда кто-либо совершает поспешные действия, думая, что поступает правильно. Делая что-либо впервые, вы, скорее всего, не знаете принятых мелочей и тонкостей, и лучше всего будет сначала спросить, не то вы имеете шансы выставить себя не в лучшем свете. Не стоит стыдиться спросить Как, черт возьми, это надо делать? Мы и так знаем, что вы умны: иначе вы не стали бы коммиттером. Тестируйте свои изменения перед коммитом. Это правило может показаться очевидным. Впрочем, если бы оно действительно было очевидно для всех, мы не так часто сталкивались со случаями явного его нарушения. Если ваши изменения затрагивают ядро, убедитесь, что после него нормально собираются ядра GENERIC и LINT. Если вы изменяете другую часть исходного кода, убедитесь, что код собирается (успешно завершается make buildworld). Если вы изменяете код в какой-либо ветви, убедитесь, что вы тестируете его на машине, которая работает именно на этой ветви кода. Если ваши изменения могут затронуть другие архитектуры, проверьте его на всех поддерживаемых архитектурах. Список доступных ресурсов можно найти на странице . По мере расширения списка поддерживаемых платформ в кластер будут добавляться соответствующие машины для тестирования. Не производите коммит в деревья src/contrib, src/crypto и src/sys/contrib без прямого разрешения (approval) соответствующего мейнтейнера(ов). Описанные деревья содержат исходный код сторонних производителей, который, как правило, импортируется в соответствующие ветви. Любой коммит, даже не выводящий файл из ветви производителя, может стать головной болью для ответственных за эту часть проекта разработчиков. Так что, если у вас нет прямого разрешения от мейнтейнера, ничего не делайте с этой частью репозитория (если, конечно, вы не поддерживаете этот код сами). Отметим, что только что сказанное вовсе не означает, что вы не должны пытаться улучшить упомянутый код, наоборот, этому будут только рады. Лучше всего, если вы передадите ваши исправления вендору. Если изменения специфичны для FreeBSD, обсудите вопрос с мейнтейнером, возможно, он посчитает разумным применить их локально. Тем не менее, что бы вы ни делали, не производите коммит сами! Если вы хотите стать ответственным за ничей участок дерева исходников, свяжитесь с &a.core;. Правила работы с различными архитектурами Начиная с версии 5.0 проект FreeBSD начал поддерживать несколько новых вычислительных архитектур, и более не является &i386;-центричным. Для упрощения поддержки FreeBSD на базе всех этих платформ Правлением было сформулировано следующее заявление:
Основной 32-битной платформой разработки является i386; основная 64-битная платформа — Sparc64. Крупные изменения в дизайне (в том числе основные изменения в API и ABI) до попадания в репозиторий должны быть отлажены по крайней мере на одной 32 и одной 64-битной платформе, желательно на основных поддерживаемых платформах.
Платформы i386 и Sparc64 были выбраны по причине широкой распространенности доступности для разработчиков; кроме того, они представляют принципиально разные подходы к дизайну процессора и системы в целом: порядок байт в слове, организация регистров, реализация DMA, кэша, страничной адресации и т.д. Процессор Alpha, конечно, является 64-битным, однако он представляет более традиционный дизайн и потому не может служить достаточно хорошей тестовой платформой для отработки тонкостей, с которыми разработчик может столкнуться на других 64-битных платформах. Платформа ia64 во многом сложна так же, как и Sparc64, однако ее доступность для разработчиков пока оставляет желать лучшего. Мы будем переформулировать эти правила по мере того, как будут меняться цены и доступность 64-битных платформ. Кроме того, разработчики должны быть в курсе наших правил классов поддержки (Tier Policy) различных аппаратных архитектур. Эти правила предназначены для общего описание процесса разработки, и потому отличаются от вышеописанных требований к возможностям и архитектурам. Правила классов поддержки на период выпуска релизов много жестче, чем ограничения на изменения в процессе разработки. Другие рекомендации Перед коммитом в области документации используйте какие-либо средства проверки орфографии. Для документов SGML, кроме того, при помощи команды make lint следует проверить корректность форматирования. Для страниц справочника, при помощи утилиты из коллекции портов manck проверяйте корректность перекрестных ссылок и ссылок на файлы, а также наличие всех необходимых ссылок на синонимы (переменная MLINK). Не смешивайте функциональные изменения со стилистическими (не изменяющими функциональных свойств кода). Такое смешивание затрудняет вычленение изменений при использовании команды cvs diff и, таким образом, может скрыть появившиеся ошибки. Не смешивайте в коммите в деревья doc/ и www/ изменения текста и переформатирование: это затрудняет работу переводчиков. Производите все стилистические изменения или переформатирования отдельными коммитами, и четко обозначайте их как таковые в журнальных сообщениях к коммиту. Удаление возможностей При необходимости удаления какой-либо функциональной возможности из утилит базовой системы следует использовать следующую схему действий: В странице справочника и, возможно, в комментариях к релизу опция, утилита или интерфейс объявляются устаревающими и не рекомендованными к использованию (deprecated); их использование выводит предупреждение. Опция, утилита или интерфейс сохраняются до очередного основного релиза (релиз X.0). Опция, утилита или интерфейс удаляются, в том числе из документации: теперь они являются устаревшими. Как правило, об этом стоит упомянуть в комментариях к релизу. Поддержка различных архитектур FreeBSD является хорошо портируемой операционной системой и предназначена для работы на самых разнообразных аппаратных архитектурах. Важной частью процесса обеспечения гибкости в поддержке современных тенденций развития оборудования является деление кода на машинно-зависимый (Machine Dependent, MD) и машинно-независимый (Machine Independent, MI), а также, по возможности, минимизация машинно-зависимой части кода. Каждая новая аппаратная архитектура, которую начинает поддерживать FreeBSD, ощутимо увеличивает работу по поддержке кода, инструментария и процесса выпуска релизов. Кроме того, становится значительно сложнее эффективно тестировать изменения в коде ядра. Все это делает необходимым введение различных классов поддержки для различных архитектур, при сохранении максимальной стабильности малого числа "основных платформ". Основные намерения Проект FreeBSD предназначен для работы на рабочих станциях, серверах и высокопроизводительных встроенных системах. Сохраняя ориентир на малое количество архитектур в интересах таких систем, проект FreeBSD остается способен поддерживать высокий уровень надежности, стабильности и производительности, а также уменьшить нагрузку на различные группы поддержки проекта, такие как группы поддержки портов, документации, безопасности и выпуска релизов. Разнообразие поддерживаемых аппаратных платформ расширяет область применимости FreeBSD за счет поддержки новых возможностей (например, поддержка 64-битных процессоров, использование во встроенных системах и т.п.); тем не менее, расширение этого списка всегда должно быть тщательно оценено с позиций увеличения затрат на поддержку дополнительной аппаратной платформы. Проект FreeBSD делит различные аппаратные платформы на 4 класса. Для каждого класса описывается набор требований, необходимых для присвоения платформе данного класса, и обязательства разработчиков по отношению к платформе. Кроме того, определяется порядок смены класса для архитектуры. Класс 1: Полностью поддерживаемые архитектуры Платформы 1 класса полностью поддерживаются группой безопасности, группой выпуска релизов и мейнтейнерами инструментария. Новые возможности, добавляемые в код системы, должны быть полностью функциональны для всех архитектур первого класса для каждого из релизов (исключением могут быть архитектурно-зависимые возможности, такие как драйвера аппаратуры). Как правило, все платформы 1 класса должны поддерживаться системами сборки либо расположенными непосредственно в кластере FreeBSD.org, либо легко доступными для всех разработчиков. Архитектуры первого класса должны быть готовыми к эксплуатации под управлением FreeBSD во всех аспектах, включая процесс установки и среду разработки. В настоящее время платформами 1 класса являются i386, Sparc64, AMD64, and PC98. Класс 2: Архитектуры для разработчиков Платформы 2 класса не поддерживаются группами безопасности и выпуска релизов. Поддержка инструментария оставляется на усмотрение его мейнтейнеров. Новые возможности, реализуемые в FreeBSD, должны быть реализуемы на этих платформах, однако непосредственная реализация на момент добавления кода в дерево исходных текстов не требуется. Реализация порта на архитектуру 2 класса может быть добавлена в репозиторий, если она не входит в противоречие с текущим состоянием систем первого класса и не влияет в существенной степени на прочие платформы 2 класса. Для добавления архитектуры 2 класса в дерево исходных текстов FreeBSD система должна быть способна загрузиться хотя бы в однопользовательский режим на реальной аппаратуре. Некоторые исключения из последнего правила могут быть сделаны для новой аппаратуры, находящейся в состоянии разработки и временно не доступной для проекта. Обычно архитектурами 2 класса являются те, которые планируются к переходу в 1 класс, но пока находятся в состоянии разработки. Также во втором классе могут находится платформы, перешедшие из 1 класса по причине потери актуальности, по мере того как уменьшается количество ресурсов, доступных для поддержки системы в состоянии готовности к промышленной эксплуатации. В настоящее время платформами 2 класса являются Alpha, PowerPC и ia64. Класс 3: Экспериментальные архитектуры Платформы 3 класса не поддерживаются группами безопасности и выпуска релизов. Поддержка инструментария оставляется на усмотрение его мейнтейнеров. Архитектурами третьего класса могут быть: те, для которых нет и в ближайшее время не предвидится доступного проекту оборудования; имеющие менее трех активных разработчиков; не способные загрузиться в однопользовательский режим на реальной аппаратуре (или под управлением эмулятора, если реальная аппаратура недоступна); наконец, системы, которые оцениваются как исчезающие, чья дальнейшая распространенность сомнительна. Поддержка систем 3 класса не вносится в основное дерево исходных текстов FreeBSD, однако работа над такими архитектурами может производиться в репозитории Perforce FreeBSD, для облегчения контроля версий и дальнейшей интеграции с основной массой кода. В настоящее время единственной платформой 3 класса является &s390;. Класс 4: не поддерживаемые архитектуры Системы 4 класса никак не поддерживаются проектом. К 4 классу относятся все архитектуры, не перечисленные выше. Правила смены класса для архитектуры Для переноса платформы из класса в класс требуется решение, утвержденное Правлением, которое, в свою очередь, согласует его с группами безопасности, выпуска релизов и поддержки инструментария. FAQ по работе с портами Добавление нового порта Как добавить новый порт? Для начала прочитайте раздел, посвященный репозиторному копированию. Самым простым будет использовать скрипт addport на машине freefall. Он добавит порт из указанного вами каталоге, определив нужную категорию из файла Makefile, добавит строку в файл CVSROOT/modules и в файл Makefile для нужной категории. Скрипт был написан &a.mharo; и &a.will;; вопросы и исправления по поводу addport следует отправлять Уиллу, как текущему мейнтейнеру. Что еще следует сделать, добавляя новый порт? Проверьте его. Желательно убедиться в том, что порт и соответствующий пакет корректно собираются. Рекомендуемая последовательность действий такова: &prompt.root; make install &prompt.root; make package &prompt.root; make deinstall &prompt.root; pkg_add имя собранного пакета &prompt.root; make deinstall &prompt.root; make reinstall &prompt.root; make package Более подробные инструкции можно найти в Руководстве FreeBSD по созданию портов. Пользуйтесь &man.portlint.1; для проверки корректности порта. Не обязательно добиваться полного отсутствия предупреждений, но по крайней мере исправьте простейшие из них. Если новый порт прислал человек, еще не упомянутый в Списке прочих участников, добавьте его имя туда. Закройте PR, если новый порт пришел в виде PR. Для этого воспользуйтесь командой edit-pr PR# на машине freefall и измените значение в строке state с open на closed. Затем опишите причину смены статуса, и на это работа закончена. Репозиторное копирование Когда требуется репозиторное копирование? При необходимости добавления порта, имеющего отношение к другому, уже находящемуся в репозитории в другом каталоге, необходимо произвести репозиторное копирование. В данном случае имеющий отношение означает другую версию или небольшую модификацию. Примерами могут служить различные версии print/ghostscript* и английская и локализованные версии x11-wm/windowmaker*. Другим примером является необходимость перенести порт из одного подкаталога в другой, или переименовать каталог, когда автор меняет имя своей программы. Когда репозиторное копирование не требуется? Если нет истории, которую стоило бы сохранять. Для порта, добавленного в неправильную категорию и сразу же перемещенного, будет вполне достаточно выполнить команды cvs remove для старого варианта и addport для нового. Что нужно делать? Создайте в GNATS PR, описав причины репозиторного копирования. Поменяйте ответственного на portmgr и установите статус (state) в состояние repocopy. Если ваш запрос будет одобрен группой &a.portmgr;, он будет переадресован на pcvs. &a.portmgr; может произвести копирование каталогов самостоятельно; в противном случае группа &a.pcvs; произведет собственно копирование и вернет вам ваш PR. После этого, вам необходимо проделать следующее: После репозиторного копирования порта: Обновите новый вариант порта до новой версии (не забудьте изменить строку PORTNAME, чтобы не получить двух портов с одним именем). Добавьте новый каталог в список SUBDIR в родительском файле Makefile. Для проверки вы можете воспользоваться командой make checksubdirs. Если порт менял категорию, измените строку CATEGORIES в файле Makefile. Добавьте строку для нового модуля. Добавьте строку в файл ports/MOVED. При удалении порта: Тщательно проверьте коллекцию на предмет портов, зависящих от удаляемого и обновите их при необходимости. Выполнение команды grep по содержимому файла INDEX недостаточно, поскольку некоторые порты могут быть сконфигурированы на этапе сборки. Рекомендуется использовать полный поиск при помощи команды grep -r. Удалите старый порт, запись SUBDIR и строку, описывающую модуль. Добавьте строку в файл ports/MOVED. После репозиторного перемещения (операции переименования, когда после копирования старый вариант удаляется): Используйте процедуры из предыдущих двух пунктов для активации нового порта и удаления старого. Заморозка портов Что такое заморозка портов? Перед выпуском релиза для сохранения целостности различных частей системы требуется на некоторое время ограничить коммиты в дерево портов. Этот процесс и называется заморозкой портов. За дополнительной информацией по поводу правил поведения во время заморозки обращайтесь к документу Задачи контроля качества для Группы управления портами. Сколько длится заморозка? Обычно неделю или две. Что это значит для меня? Во время заморозки вы не можете производить какие-либо коммиты в дерево портов без прямого разрешения группы порт-менеджеров. Прямое разрешение здесь означает, что вы послали свой патч группе порт-менеджеров и получили ответ Вперед, производите коммит. В период заморозки не все изменения могут быть внесены в дерево. За подробностями обращайтесь к документу Задачи контроля качества для Группы управления портами. Отметим, что у вас нет подразумеваемого разрешения исправлять неработающий порт в период заморозки только потому, что порт не работает. Откуда я узнаю о начале периода заморозки? Обычно за 2-3 недели до начала периода заморозки кто-либо из группы порт-менеджеров посылает письмо с предупреждением об этом в &a.ports; и &a.committers;. Точное время начала периода заморозки определяется за несколько дней до собственно релиза, поскольку фиксируемое дерево портов должно быть синхронизировано с релизом, а точная дата выпуска определяется по ходу дела. Разумеется, после начала периода заморозки в &a.committers; будет отправлено еще одно предупреждение. Как узнать, когда период заморозки портов закончился? Завершение периода заморозки анонсируется группой порт-менеджеров посылкой письма в &a.ports; и &a.committers; через несколько часов после релиза. Отметим, что факт выпуска релиза не означает автоматического завершения заморозки. Нам потребуется убедиться, что в последние минуты не произошло ничего непредвиденного, что заставило бы перевыпускать релиз. Создание новой категории Какова процедура создания новой категории портов? Разработчик, предлагающий новую категорию, должен подготовить детальное обоснование ее создания, в том числе описание причин, по которым текущий список категорий недостаточен, а также список портов, переносимых в новую категорию. Прежде чем отправлять запрос, помните, что процесс потребует приложения немалых сил от многих участников, затронет всякого, кто поддерживает актуальное состояние дерева портов целиком, и, наконец, что подобные предложения неизбежно вызовут споры и расхождения во мнениях. + + + Обратитесь к разделу + + Proposing a New Category Руководства по созданию портов. + После передачи PR группе &a.portmgr; решение о создании категории + остается за ней. В случае утверждения новой категории кто-либо + из &a.portmgr; делает следующее: + + + + Производит нужные репозиторные копирования. + + + + Обновляет определения VALID_CATEGORIES + в файле ports/Mk/bsd.port.mk. + + + + + Возвращает PR вам. + + Как устроен процесс? Процедура является надстройкой над уже описанной процедурой репозиторного копирования отдельного порта. - Создайте в GNATS PR с описанием - причин для создания новой категории. Желательно, чтобы запрос - содержал патчи к файлам Makefile - переносимых портов, их старых категорий, а также к определению - списка VALID_CATEGORIES в файле - ports/Mk/bsd.port.mk. Передайте PR группе - &a.portmgr; (portmgr). Если порт-менеджер - одобрит изменения, он передаст PR группе &a.cvsadm; - (cvs), один из членов которой выполнит - копирование и вернет PR вам. В завершение вам нужно произвести - следующие действия: - Обновите файлы Makefile для всех перенесенных портов. Пока не добавляйте новую категорию в процесс построения индекса. Для этого вам необходимо: Сменить для всех портов значение переменной CATEGORIES (это и было нашей целью, не правда ли?) Новая категория должна быть указано в списке первой, это поможет проверить, правильно ли установлена переменная PKGORIGIN. Выполните команду make describe. Поскольку процедура построения главного индекса make index, которую вам предстоит выполнить несколько позже, использует именно make describe, обнаружение ошибок сейчас сэкономит вам немало времени в будущем. Если вы хотите быть совсем честным, самое время запустить &man.portlint.1;. Проверьте корректность переменных PKGORIGIN. Система работы с портами использует значение переменной CATEGORIES для установки переменной PKGORIGIN, которая затем используется для связи установленных пакетов с каталогами дерева портов. Если эта связь установлена неправильно, перестанут правильно функционировать утилиты работы с портами, такие как &man.pkg.version.1; и &man.portupgrade.1;. Для проверки следует использовать скрипт chkorigin.sh: env PORTSDIR=/path/to/ports sh -e /path/to/ports/Tools/scripts/chkorigin.sh . Эта команда проверит каждый порт в дереве, в том числе и те, что не включены в процесс сборки, так что ее можно использовать сразу после репозиторного копирования. Совет: не забудьте проверить PKGORIGIN для зависимых от изменяемых вами портов! Протестируйте изменения локально, на вашей машине: закомментируйте строки SUBDIR для старых портов, затем разрешите обработку новой категории в файле ports/Makefile. Запустите make checksubdirs в затрагиваемых категориях. Наконец, выполните в каталоге ports/ команду make index. Ее выполнение может занять до 40 минут даже на современной машине, однако, это необходимые затраты для того, чтобы не создать проблем для других. После завершения этой операции вы можете вносить в репозиторий изменения ports/Makefile для включения новой категории в процесс сборки, а также производить коммит изменений Makefile для старых категорий. + + Добавьте в файл CVSROOT-ports/modules + строку + ports_categoryname   categoryname + + + Поля должны быть разделены табуляцией. + + Если categoryname + содержит дефисы, замените их на подчеркивания. + + Поменяйте строки для затронутых модулей в файле CVSROOT-ports/modules. Добавьте нужные строки в файл ports/MOVED. - Обновите список коллекций для &man.cvsup.1; в файле - distrib/cvsup/sup/README и добавьте - два файла в каталог - cvsup/sup/ports-categoryname: - list.cvs и - releases. (Обратите внимание: эти - файлы расположены в репозитории src, а не ports). + Обновите инструкции для &man.cvsup.1;: + + + + + Добавьте категорию в файл + distrib/cvsup/sup/README + + + + + + Добавьте в каталог + distrib/cvsup/sup/ports-categoryname + два файла: + list.cvs и + releases. + + + + + Добавьте категорию в файл + src/share/examples/cvsup/ports-supfile + + + + + + (Обратите внимание: эти + файлы расположены в репозитории src, а не ports). + Если вы не являетесь коммиттером src, вам потребуется + создать PR. - Создайте PR в категории документации (doc) для - добавления новой категории портов в Обновите документацию: + + + + + - Руководстве FreeBSD по созданию портов и в файл - www/en/ports/categories. + Руководство FreeBSD по созданию портов + + + + + Файл www/en/ports/categories. + Обратите внимание, что строки в них сгруппированы по + категориям, описанным в файле + www/en/ports/categories.descriptions. + + + + + Раздел Руководства, перечисляющий + + cvsup коллекции. + + + (Внимание: все эти файлы находятся в репозитории + документации. Если вы не являетесь коммиттером в этой области, + создайте PR в категории документации (doc). Старые варианты портов могут быть удалены из репозитория только после того, как все описанные процедуры будут завершены, и никто не жалуется на новую структуру. Специально обновлять веб-страницу портов при добавлении новой категории не нужно: изменение файла www/en/ports/categories будет учтено при ежедневной перестройке списка портов (INDEX) автоматически. Прочие вопросы Как мне проверить, что мой порт корректно собирается? В первую очередь проверьте свой порт по адресу . Там вы найдете журналы сборки пакетов на всех поддерживаемых архитектурах для большинства последних ветвей разработки. Впрочем, отсутствие вашего порта среди журналов с ошибками еще не значит, что он успешно собирается (например, может не собираться один из зависимых портов). Необходимую информацию вы можете найти на машине pointyhat в каталогах /a/portbuild/<arch>/<major_version>. Каждая пара архитектуры и базовой версии содержит следующие подкаталоги: 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> Общее правило: пакет, присутствующий в каталоге packages или каталоге logs, и при этом отсутствующий в errors, собрался успешно. (Именно каталоги errors вы видите на веб-сервере pointyhat). Я добавил новый порт. Нужно ли добавлять его в файл INDEX? Нет. INDEX больше не хранится в CVS репозитории. Данный файл может быть сгенерирован с помощью команды make index или уже сгенерированная версия может быть загружена с помощью make fetchindex. Какие еще файлы я не должен трогать? Любой файл в на верхнем уровне ports/, а также все файлы в каталогах, имена которых начинаются с прописной буквы (например, Mk/, Tools/ и т.п.). В частности, упаси вас Бог трогать файлы ports/Mk/bsd.port*.mk, если вы не хотите привести порт-менеджеров в ярость! Каков корректный порядок обновления порта, когда его исходный архив поменялся, но не сменил имя? При возникновении ситуации, когда автор обновляет дистрибутивный архив без изменения идентификатора версии, сообщение о коммите должно содержать аннотацию различий между предыдущим и обновленным состоянием архива, чтобы можно было убедиться, что архив не испорчен и не подменен злоумышленником. Если текущая версия порта существовала достаточное время, копии архива будут доступны на ftp-серверах проекта; в противном случае следует связаться с автором или мейнтейнером порта для выяснения причин замены архива. Пряники и прочие льготы Увы, льгот, возникающих от того, что вы являетесь коммиттером, не так уж много. Пожалуй, единственным несомненным долговременным преимуществом будет признание вас как компетентного специалиста. Тем не менее, кое-какие льготы все же существуют: Прямой доступ к машине cvsup-master Будучи коммиттером, вы можете обратиться к &a.kuriyama;, чтобы получить доступ к машине cvsup-master.FreeBSD.org, приложив вывод команды cvpasswd yourusername@FreeBSD.org freefall.FreeBSD.org. Обратите внимание: в командной строке вы должны указать freefall.FreeBSD.org, хотя реальным сервером будет cvsup-master. Доступом к cvsup-master не следует злоупотреблять: это весьма загруженная машина. Бесплатная подписка на комплект из 4 CD или DVD Компания FreeBSD Mall, Inc. предоставляет для всех коммиттеров FreeBSD возможность бесплатной подписки на выпуски FreeBSD. Порядок подписки появляется в списке рассылки developers@FreeBSD.org после каждого релиза. Прочие вопросы Почему не следует вносить малозначимые изменения в ветви разработчика (vendor branches)? После этого действия каждый новый релиз от разработчика требует ручного приложения и объединения патчей. Что хуже, каждый новый релиз от разработчика требует ручной проверки приложенных патчей. Опция CVS не всегда хорошо работает. Можете спросить &a.obrien;, он расскажет вам жутких историй. Как мне добавить файл в ветвь CVS? Для добавления файла в ветви просто обновите исходные файлы до нужной ветви, а затем используйте команду cvs add. Например, если мы хотите перенести файл src/sys/alpha/include/smp.h из ветви HEAD в ветвь RELENG_4, в которой он пока не существует, можно использовать следующую последовательность действий: MFC для нового файла &prompt.user; cd sys/alpha/include &prompt.user; cvs update -rRELENG_4 cvs update: Updating . U clockvar.h U console.h ... &prompt.user; cvs update -kk -Ap smp.h > smp.h =================================================================== Checking out smp.h RCS: /usr/cvs/src/sys/alpha/include/smp.h,v VERS: 1.1 *************** &prompt.user; cvs add smp.h cvs add: scheduling file `smp.h' for addition on branch `RELENG_4' cvs add: use 'cvs commit' to add this file permanently &prompt.user; cvs commit Какую мета-информацию я должен включать в сообщения для коммита? Помимо информативного описания содержания коммита вам может потребоваться включить в сообщение дополнительную информацию. Она состоит из одной или нескольких строк вида: ключевое слово или словосочетание, двоеточие, табуляции для форматирования, собственно дополнительная информация. Ключевыми словами могут быть: PR: Идентификатор сообщения об ошибке, затрагиваемого (как правило, закрываемого) данным коммитом. Submitted by: Имя и e-mail адрес приславшего исправление; для коммиттеров — просто имя пользователя в кластере FreeBSD. Reviewed by: Имя и e-mail адрес того или тех, кто рецензировал изменения; для коммиттеров — имя пользователя в кластере FreeBSD. Если изменения были посланы в список рассылки на рецензию и получили одобрение, имя списка рассылки. Approved by: Имя и e-mail адрес того или тех, кто одобрил изменение; как и прежде, для коммиттеров просто имя пользователя в кластере. Обычной практикой является получение одобрения для коммитов в новые для вас области дерева. Кроме того, в период перед каждым релизом все коммиты должны быть одобрены группой выпускающих инженеров. В случае ваших первых коммитов вы должны получить одобрение на них у вашего ментора, и упомянуть его в виде username-of-mentor (mentor). Obtained from: Имя проекта, из исходного кода которого было взято изменение. MFC after: Если вы хотите получать по почте напоминания об MFC, укажите число дней, недель или месяцев с момента изначального коммита, через которое вы планируете произвести MFC. Security: Если ваши изменения затрагивают вопросы безопасности или исправляют какие-либо уязвимости, укажите ссылки на опубликованные отчеты или описание проблемы. Сообщение для коммита, основанного на PR Вы собираетесь внести коммит, основанный на PR, присланном John Smith и содержащим патч для исправления проблемы. Ваше сообщение должно заканчиваться примерно такими строками: ... PR: foo/12345 Submitted by: John Smith <John.Smith@example.com> Сообщение для коммита, требующего рецензии Вы собираетесь изменить подсистему работы с виртуальной памятью. Вы опубликовали предполагаемые изменения в соответствующем списке рассылки (в данном случае freebsd-arch), и изменения были одобрены. ... Reviewed by: -arch Сообщение для коммита, требующего одобрения Вы намерены произвести коммит в область дерева, для которой определен ведущий (MAINTAINER). Вы скоординировали усилия с мейнтейнером, и он отреагировал Отлично. Производи коммит. ... Approved by: abc Где abc имя пользователя, одобрившего ваш коммит. Сообщение для коммита, использующего код OpenBSD Вы собираетесь внести изменение, основанное на коде, использованном проектом OpenBSD. ... Obtained from: OpenBSD Сообщение для коммита, планирующего интеграцию из &os.current; в &os.stable; через некоторое время Вы хотите внести изменения, которые должны быть интегрированы из &os.current; в ветвь &os.stable; через две недели. ... MFC after: 2 weeks Где 2 является количеством дней, недель или месяцев, через которое вы планируете интегрировать (MFC) в &os.stable;. В качестве weeks может быть использовано week, weeks, month, months, либо этот параметр может быть опущен (при этом подразумевается X дней). В отдельных случаях вам потребуется комбинировать приведенные примеры. Рассмотрим ситуацию, когда некто прислал сообщение об ошибке, содержащее код из проекта NetBSD. Вы заинтересовались этим случаем, но он расположен в той части дерева, в которой вы обычно не работаете, так что вы решаете выдать изменения на рассмотрение списка рассылки arch. Поскольку изменения были достаточно сложны, вы решаете интегрировать их (MFC) через месяц, чтобы обеспечить адекватное время для тестирования. В описанном случае сообщения для коммита может выглядеть примерно так: PR: foo/54321 Submitted by: John Smith <John.Smith@example.com> Reviewed by: -arch Obtained from: NetBSD MFC after: 1 month Как мне получить доступ к people.FreeBSD.org для того чтобы разместить там персональную информацию или информацию о моих проектах? people.FreeBSD.org — синоним для freefall.FreeBSD.org. Просто создайте каталог public_html. Все, что вы разместите в нем, будет автоматически доступно по адресу . Где расположены архивы списков рассылки? Списки рассылки архивируются в иерархию каталогов /g/mail, видимую на всех машинах кластера как /hub/g/mail (см. &man.pwd.1;).
diff --git a/ru_RU.KOI8-R/articles/cvs-freebsd/article.sgml b/ru_RU.KOI8-R/articles/cvs-freebsd/article.sgml index 4ca9059830..50a7cc89e0 100644 --- a/ru_RU.KOI8-R/articles/cvs-freebsd/article.sgml +++ b/ru_RU.KOI8-R/articles/cvs-freebsd/article.sgml @@ -1,734 +1,734 @@ %articles.ent; ]>
Настройка хранилища CVS - подход FreeBSD Stijn Hoop
stijn@win.tue.nl
 2001 2002 2003 Stijn Hoop $FreeBSD$ &tm-attrib.freebsd; &tm-attrib.general; В этой статье описаны шаги, которые я предпринял для настройки хранилища CVS, использующего те же самые скрипты, что используются в проекте FreeBSD в их настройке. Это имеет некоторые преимущества перед стандартной настройкой CVS, в том числе более точный контроль доступа к дереву исходных текстов и посылку содержательных сообщений электронной почты при каждом коммите. Введение Большинство программных проектов с открытым кодом используют CVS в качестве системы управления исходным кодом. Хотя CVS весьма хороша в этом качестве, у неё есть свои неудобства и недостатки. Одним из них является то, что совместное использование дерева исходных текстов с другими разработчиками может быстро привести к кошмарным проблемам при администрировании, особенно если кто-то захочет защитить части дерева от общедоступности. FreeBSD является одним из проектов, использующим CVS. Здесь также имеет большое количество разработчиков, разбросанных по всему миру. Они разработали некоторые скрипты, облегчающие управление хранилищем. Недавно эти скрипты были пересмотрены и приведены в порядок Джозефом Картаузером (Joseph Karthauser), в целях облегчения их использования в других проектах. В этой статье описан один из методов использования новых скриптов. Чтобы извлечь максимум информации из этой статьи, вы должны владеть основными методами работы с CVS. Первоначальная настройка Наверное, лучше сначала выполнить эту процедуру с пустым тестовым хранилищем, чтобы понять все последствия ваших действий. Как обычно в таких случаях, у вас должны иметься свежие читаемые резервные копии! Инициализация хранилища Первым делом при настройке нового хранилища необходимо его инициализировать, для чего выдать CVS такую команду: &prompt.user; cvs -d path-to-repository init - Разультатом ее выполнения будет созданный + Результатом ее выполнения будет созданный CVS служебный - каталог CVSROOT, в котором выполняется вся + каталог CVSROOT, в котором выполняется вся настройка. Группа пользователей хранилища Теперь мы создадим группу, которая будет владеть хранилищем. В этой группе должны присутствовать все коммиттеры, для того, чтобы они могли писать в хранилище. Для этой группы мы примем стандартное для FreeBSD название ncvs. &prompt.root; pw groupadd ncvs Затем вы должны при помощи команды &man.chown.8; сменить владельца и группу для только что добавленного каталога: &prompt.root; chown -R :ncvs path-to-your-repository Это нужно для того, чтобы никто не мог записывать в хранилище, не являясь членом группы. Получение исходных текстов - Теперь вам нужно получить каталог CVSROOT из + Теперь вам нужно получить каталог CVSROOT из хранилища FreeBSD. Проще всего это делается извлечением с анонимного зеркала CVS FreeBSD. Обратитесь к соответствующей главе Руководства для получения дополнительной информации. Мы будем полагать, что исходные тексты хранятся в подкаталоге - CVSROOT-freebsd текущего каталога. + CVSROOT-freebsd текущего каталога. Копирование скриптов FreeBSD Теперь мы скопируем исходные тексты FreeBSD из - CVSROOT в наше хранилище. Если вы знакомы с + CVSROOT в наше хранилище. Если вы знакомы с CVS, то для вас может иметь смысл попытаться импортировать скрипты, чтобы облегчить синхронизацию с последующими версиями. Однако при этом оказывается, что CVS имеет в этой области недостаток: при - импортировании исходных текстов в каталог CVSROOT + импортировании исходных текстов в каталог CVSROOT она не будет обновлять необходимые административные файлы. Чтобы в этом убедиться, вам нужно проверить каждый файл после импортирования, при этом смысл cvs import теряется. Поэтому рекомендуемым методом является простое копирование скриптов. Не имеет значения, как вы относитесь к предыдущему параграфу—результат один и тот же. Просто поместите ваш - CVSROOT и скопируйте файлы FreeBSD поверх ваших + CVSROOT и скопируйте файлы FreeBSD поверх ваших локальных (неизмененных) копий: &prompt.user; cvs -d path-to-your-repository checkout CVSROOT &prompt.user; cd CVSROOT &prompt.user; cp ../CVSROOT-freebsd/* . &prompt.user; cvs add * Заметим, что вы, скорее всего, получите несколько предупреждений о том, что некоторые каталоги не были скопированы; это нормально, вам они не нужны. Скрипты Теперь у вас есть рабочий каталог и точная копия скриптов, которые используются в проекте FreeBSD для работы с хранилищем. Далее следует краткое описание назначения каждого файла. access - по умолчанию при стандартной настройке этот файл не используется. Он применяется в специфичных для проекта FreeBSD настройках, где он управляет доступом к хранилищу. Вы можете удалить этот файл, если вы не собираетесь использовать такую настройку. avail - этот файл управляет доступом к хранилищу. В нем вы можете указать группы людей, которым разрешен доступ к хранилищу, а также запретить коммиты на уровне каталогов. Вы должны поднастроить его так, чтобы он содержал группы и каталоги, имеющиеся в вашем хранилище. cfg.pm - этот файл анализирует вашу конфигурацию и содержит настройки по умолчанию. Вы не должны изменять этот файл. Вместо этого размещайте ваши изменения в конфигурации в файле cfg_local.pm. cfg_local.pm - этот файл содержит все настраиваемые параметры системы. Вы должны настраивать все параметры здесь, например, куда посылается почта при коммите, с каких хостов можно выполнять коммиты, и прочее. Ниже дается более полная информация об этом. checkoutlist - эти файлы перечисляют все файлы, управляемые CVS в этом каталоге. Вы должны отредактировать его для удаления некоторых специфичных для FreeBSD файлов. commit_prep.pl - этот скрипт выполняет различные проверки перед выполнением коммита, в зависимости от того, включили ли вы их в cfg_local.pm. Вам не нужно его трогать. commitcheck - этот скрипт вызывается непосредственно из CVS. Сначала он проверяет, с использованием cvs_acls.pl, имеет ли коммитер доступ к указанной части дерева, а затем запускает commit_prep.pl для выполнения различных проверок перед коммитом. Если они выполнились нормально, то CVS позволит выполнить коммит. Вам не нужно трогать этот файл. commitinfo - этот файл используется в CVS для определения того, какой скрипт запускать перед коммитом—в данном случае commitcheckl. Вам не нужно трогать этот файл. config - конфигурационный файл для этого хранилища. Вы должны изменять его при необходимости, но большинство администраторов могут оставить все настройки по умолчанию. Дополнительную информацию о параметрах, которые могут быть здесь заданы, можно найти в руководстве по CVS. cvs_acls.pl - этот скрипт идентифицирует пользователя и то, имеет ли он доступ к дереву. Это делается на основе информации в файле avail. Вам не нужно трогать этот файл. cvsignore - этот файл перечисляет файлы, которые CVS не должна помещать в хранилище. Вы можете отредактировать его по своему усмотрению. Более полная информация об этом файле находится в руководстве по CVS. cvswrappers - этот файл используется в CVS для включения или выключения расширения ключевых слов, или должен ли файл считаться бинарным. Вы можете редактировать его по своему усмотрению. Более полная информация об этом файле находится в руководстве по CVS. Имейте ввиду, что опции CVS -t и -f некорректно работают в режиме клиент/сервер. edithook - этот файл больше не используется, но оставлен по историческим причинам. Вы можете спокойно удалить этот файл. editinfo - CVS использует этот файл для настройки редактора. FreeBSD не использует эту функциональность, так как обработка сообщений для журнала выполняется в файлах verifymsg и logcheck. Это происходит по той причине, что editinfo некорректно работает в режиме клиент/сервер, или в случаях когда используются опции -m или -F. Вам не нужно трогать этот файл. exclude - в этом файле перечислены регулярные выражения, используемые commit_prepl.pl для выделения файлов, в которых могут не содержаться заголовки с номером версии. В настройке FreeBSD все файлы содержащиеся в хранилище должны иметь заголовок с версией (типа $FreeBSD$). Все файлы с именами, которые соответствуют одной из строк этого файла, исключаются из проверки. Вы должны добавить выражения в этот файл, если вы помещаете в хранилище файлы, которые не могут иметь заголовки с версиями. Для целей установки скриптов лучшим - решением может оказаться исключение CVSROOT/ + решением может оказаться исключение CVSROOT/ из проверки заголовков. log_accum.pl - это скрипт, который принимает журнальное сообщение в виде, данном скриптом logcheck, и добавляет его к файлу журнала в хранилище для хранения резервной копии. Он также отрабатывает посылку сообщения по электронной почте на адрес, который вы зададите (в файле cfg_local.pm). Он подключается к CVS через loginfo. Вам не нужно трогать этот файл. logcheck - при коммите этот файл анализирует сообщение для журнала, которое составляют коммиттеры, и пытается его некоторым образом улучшить. Он подключается к CVS через logcheck. Вам не нужно трогать этот файл. Этот скрипт зависит от ряда локальных модификаций CVS, сделанный во FreeBSD: эта версия читает журнальное сообщение повторно после того, как этот скрипт его модифицирует. Стандартная версия CVS этого не делает, что делает этот скрипт бесполезным, так как он не может модифицировать журнальное сообщение, хотя может проверить его на предмет правильности синтаксиса. CVS версии 1.11.2 и выше может быть настроен, чтоб иметь поведение подобное FreeBSD, путем установки опции RereadLogAfterVerify=always в файле config. loginfo - этот файл используется CVS для управления того, куда посылается протокольная информация. С помощью этого файла подключается log_accum.pl. Вам не нужно трогать этот файл. modules - этот файл сохраняет своё традиционное назначение в CVS. Вы должны удалить модули FreeBSD из стандартной версии. Вы можете редактировать этот файл по своему усмотрению. Более полная информация об этом файле находится в руководстве по CVS. notify - этот файл используется в CVS в том случае, если кто-то задаст отслеживание файла. Это не используется в хранилище FreeBSD. Вы можете редактировать его по своему усмотрению. Более полная информация об этом файле находится в руководстве по CVS. options - этот файл специфичен для версии CVS от FreeBSD, но также поддерживается версией для Debian. Он содержит ключевое слово для расширения в заголовках версий. Вы должны заменить это на ключевое слово, которое вы задали в файле cfg_local.pm (если вы используете эту возможность, которая в настоящее время специфична для FreeBSD). rcsinfo - этот файл отображает каталоги в хранилище на файлы шаблонов, как например rcstemplate. По умолчанию FreeBSD использует один шаблон для всего хранилища. Вы можете добавлять другие к этому файлу по своему усмотрению. rcstemplate - этот файл является актуальным файлом шаблона, который видят коммиттеры, когда помещают что-то в хранилище. Вы должны отредактировать его для описания различных дополнительных параметров, которые вы определили в cfg_local.pm. tagcheck - эти файлы управляют доступом к созданию меток в хранилище. Стандартная для FreeBSD версия не позволяет создавать метки с именами типа RELENG* из-за пересечения с процессом создания релизов. Вы должны отредактировать этот файл по вашему усмотрению. taginfo - этот файл ставит в соответствие операции с метками над каталогами хранилища скриптам управления доступом, например tagcheck. Вам не нужно трогать этот файл. unwrap - этот скрипт нужен для автоматической обратной обработки (unwrap) двоичных файлов (посмотрите cvswrappers) при извлечении. Это не используется в текущей настройке FreeBSD по причине того, что не работает с конфигурацией клиент/сервер. Вам не нужно трогать этот файл. verifymsg - этот файл ставит в соответствие каталогам хранилища скрипты вторичной обработки журнальных сообщений, например logcheck. Вам не нужно трогать этот файл. wrap - этот скрипт может быть использован для автоматической обработки (wrap) двоичных файлов (посмотрите cvswrappers) при помещении в хранилище. Это не используется в текущей настройке FreeBSD, по причине того, что не работает с конфигурацией клиент/сервер. Вам не нужно трогать этот файл. Настройка скриптов Следующим шагом является настройка скриптов так, чтобы они работали в ваших условиях. Вы должны просмотреть все файлы в каталоге и выполнить ваши настройки. В частности, вы может потребоваться отредактировать следующие файлы: Если вы не хотите использовать специфичные для FreeBSD возможности скриптов, то вы можете без последствий удалить файл access: &prompt.user; cvs rm -f access Отредактируйте avail так, чтобы он содержал различные каталоги хранилища, доступом к которым вы хотите управлять. Обязательно сохраните строчку avail||CVSROOT, иначе вы заблокируете сами себя на следующем шаге. Другими параметрами, которые вы можете добавить в этот файл, являются группы коммиттеров. По умолчанию FreeBSD использует файл access для перечисления всех коммиттеров, но вы можете использовать любой файл. Вы можете также добавить группы, если хотите (синтаксис описан в начале файла cvs_acls.pl). Отредактируйте файл cfg_local.pm так, чтобы он содержал параметры, которые вы хотите. В частности, вы должны взглянуть на такие пункты настройки: %TEMPLATE_HEADERS - они обрабатываются скриптами ведения протокола, и вставляются ниже почтового сообщения, если они присутствуют и не являются пустыми в сообщении при коммите. Вы можете, наверное, удалить строки PR и MFC after. И, конечно, вы можете добавить свои собственные. $MAIL_BRANCH_HDR - если вы хотите в каждое сообщение при коммите вставлять заголовок, описывающий ветку, в которую был выполнен коммит, задайте это в соответствии с вашим окружением. Или оставьте это пустым, если не хотите иметь такой заголовок. @COMMIT_HOSTS - задайте здесь список хостов, с которых можно выполнять коммиты. $MAILADDRS - задайте здесь адрес администратора или списка, в который должны направляться почтовые сообщения при коммите. @LOG_FILE_MAP - измените этот массив по своему усмотрению - каждое регулярное выражение сравнивается с каталогом коммита, и протокольное сообщение при коммите - сохраняется в подкаталоге commitlogs + сохраняется в подкаталоге commitlogs в указанном файле. $COMMITCHECK_EXTRA - если вы не хотите использовать специфичные для FreeBSD проверки доступа, то вы должны удалить определения $COMMITCHECK_EXTRA из этого файла. Изменение параметра $IDHEADER гарантированно работает только на платформах FreeBSD; это зависит от специфичных для FreeBSD модификаций в CVS. Вы можете проверить cfg.pm на предмет того, какие другие параметры могут быть изменены, но перечисленное выше является достаточным подмножеством. Отредактируйте exclude для удаления специфичных для FreeBSD записей (например, всех строк, которые начинаются с ^ports/ и так далее). Более того, закомментируйте строки, начинающиеся с ^CVSROOT/, и добавьте одну строку только с ^CVSROOT/. После установки обработчика (wrapper) вы можете добавить свои заголовки к файлам в каталоге - CVSROOT и восстановить эти строки, но теперь + CVSROOT и восстановить эти строки, но теперь они будут иметь смысл, только когда вы попытаетесь выполнить коммит позже. Отредактируйте файл modules и удалите всё, что относится к FreeBSD. Добавьте собственные модули, если хотите. Этот шаг необходим, если только вы задали значение для $IDHEADER в cfg_local.pm (что работает только при использовании модифицированной во FreeBSD версии CVS). Отредактируйте файл options так, чтобы он соответствовал метке, которую вы задали в cfg_local.pm. Глобальный поиск и замена FreeBSD на вашу метку должны сработать. Отредактируйте файл rcstemplate так, чтобы он содержал те же самые ключевые слова, что заданы в cfg_local.pm. Опционально удалите проверки FreeBSD из tagcheck. Вы можете просто добавить exit 0 в начало файла, чтобы запретить все проверки при установке метки. Последним действием, которое нужно сделать перед тем, как закончить работу, является проверка того, что протоколы коммитов могут сохраняться. По умолчанию они сохраняются в хранилище, в - подкаталоге commitlogs каталога - CVSROOT. Этот каталог должен быть создан, так + подкаталоге commitlogs каталога + CVSROOT. Этот каталог должен быть создан, так что выполните следующее: &prompt.user; mkdir commitlogs &prompt.user; cvs add commitlogs А теперь, после тщательной проверки, вы должны выполнить коммит ваших изменений. Убедитесь, что вы дали сами себе доступ к каталогу - CVSROOT в вашем avail до + CVSROOT в вашем avail до того, как его делать, так как в противном случае вы заблокируете сами себя. Так что убедитесь, что всё именно так, как вы и предполагали, а затем выполните следующее: &prompt.user; cvs commit -m '- Initial FreeBSD scripts commit' Тестирование настройки Вы готовы к первому тестированию: принудительному коммиту в файл avail, чтобы убедиться, что всё работает так, как ожидалось. &prompt.user; cvs commit -f -m 'Forced commit to test the new CVSROOT scripts' avail Если всё работает, поздравляем! Теперь у вас имеется работающая настройка скриптов FreeBSD для вашего хранилища. Если CVS всё ещё о чём-то сообщает, вернитесь и проверьте, все ли вышеупомянутые шаги были выполнены правильно. Специфичная для FreeBSD настройка Проект FreeBSD сам по себе использует несколько другую настройку, в которой также используются файлы из подкаталога freebsd каталога FreeBSD - CVSROOT. Проект использует их из-за большого + CVSROOT. Проект использует их из-за большого количества коммиттеров, которые все должны быть в одной и той же группе. Поэтому был написан простой обработчик, проверяющий, что люди имеют правильные права на выполнение коммита, а затем устанавливающий идентификатор группы, соответствующий идентификатору хранилища. Если вашему хранилищу это тоже нужно, то шаги для выполнения этого описаны ниже. Но сначала обзор связанных с этим файлов. Файлы, используемые в настройке FreeBSD access - этот файл управляет информацией о доступе. Вы должны отредактировать этот файл для включения всех участников вашего проекта. freebsd/commitmail.pl - этот файл больше не используется, но оставлен по историческим причинам. Вам не нужно трогать этот файл. freebsd/cvswrap.c - это исходный текст обработчика CVS, который вам нужно установить, чтобы проверки доступа реально заработали. Дополнительная информация об этом ниже. Вы должны отредактировать маршруты в макросах ACCESS и REALCVS так, чтобы они соответствовали вашей настройке. freebsd/mailsend.c - этот файл нужен в настройке FreeBSD для списков рассылки. Вам не нужно трогать этот файл. Процедура Отредактируйте файл access так, чтобы он содержал только ваше имя пользователя. Отредактируйте cvswrap.c так, чтобы он содержал правильный маршрут для вашей настройки. Это определено в макросе по имени ACCESS. Вы должны также изменить расположение реального выполнимого файла cvs, если оно не подходит к вашей ситуации. Для стандартного cvswrap.c предполагается, что он заменит общесистемную команду cvs, которая будет перемещена в /usr/bin/ncvs. В моём экземпляре cvswrap.c помещено следующее: #define ACCESS "/local/cvsroot/CVSROOT/access" #define REALCVS "/usr/bin/ncvs" Следующим шагом является установка обработчика для того, чтобы проверить правильность установки группы при выполнении коммита. Исходные тексты для этого размещены в cvswrap.c из вашего - CVSROOT. + CVSROOT. Откомпилируйте исходные тексты, которые вы редактировали для включения правильных путей: &prompt.user; cc -o cvs cvswrap.c А затем установите их (для этого вы должны быть пользователем root): &prompt.root; mv /usr/bin/cvs /usr/bin/ncvs &prompt.root; mv cvs /usr/bin/cvs &prompt.root; chown root:ncvs /usr/bin/cvs /usr/bin/ncvs &prompt.root; chmod o-rx /usr/bin/ncvs &prompt.root; chmod u-w,g+s /usr/bin/cvs При этом обработчик будет установлен по умолчанию как команда cvs, что гарантирует всеми, использующими хранилище, получение правильных уровней доступа. Теперь вы можете убрать всех из вашей группы хранилища. Всё управление доступом выполняется вашим обработчиком, и он будет устанавливать правильную группу для доступа. Тестирование настройки Теперь ваш обработчик должен быть установлен. Конечно, вы можете протестировать его, выполнив принудительный коммит в файл access: &prompt.user; cvs commit -f -m 'Forced commit to test the new CVSROOT scripts' access И снова, если это не сработает, проверьте, правильно ли были выполнены все вышеперечисленные шаги.
diff --git a/ru_RU.KOI8-R/articles/portbuild/article.sgml b/ru_RU.KOI8-R/articles/portbuild/article.sgml index a23a29f4e0..49ded79573 100644 --- a/ru_RU.KOI8-R/articles/portbuild/article.sgml +++ b/ru_RU.KOI8-R/articles/portbuild/article.sgml @@ -1,725 +1,742 @@ %articles.ent; ]>
Процесс построения пакетов Группа поддержки портов &os; $FreeBSD$ 2003 2004 + 2005 + 2006 Группа поддержки портов &os; &tm-attrib.freebsd; &tm-attrib.intel; &tm-attrib.sparc; &tm-attrib.general; Введение Для того, чтобы подготовить предкомпилированные версии поддерживаемых приложений для &os;, на одном из Кластеров сборки пакетов регулярно производится сборка полного дерева портов. В настоящее время существует два таких кластера: pointyhat.FreeBSD.org и dosirak.kr.FreeBSD.org. Большая часть магии процесса сборки сосредоточена в дереве каталогов /var/portbuild. Если не оговаривается иное, все пути указаны относительно этого каталога. ${arch} используется для указания на архитектуру платформы сборки (&i386;, alpha, &sparc64;, ia64 или amd64); ${branch} описывает ветвь построения - (4, 5, 4-exp). + (4, 4-exp, 5, 5-exp, 6, 7). Конфигурация машин-клиентов Клиенты архитектур &i386;, alpha, amd64 и два из &sparc64; клиентов загружаются по сети с pointyhat; прочие sparc64 клиенты и машины для сборки ia64 загружаются самостоятельно. Так или иначе, все они в процессе загрузки подготавливаются к сборке пакетов. В серии последних обновлений была добавлена поддержка несвязанных (disconnected) узлов кластера. Несвязанный узел не монтирует мастер-машину кластера по NFS, и может, таким образом, быть достаточно удален от центра. Мастер-машина копирует - нужные данные (иерархии портов, исходных текстов системы и документации, + нужные данные (иерархии портов, исходных текстов системы, архивы системы, скрипты и т.п.) при помощи rsync на этапе начальной конфигурации узлов. Затем, каталог portbuild монтируется как nullfs для сборок пакетов. Псевдо-пользователь ports-${arch} может выполнить команду &man.ssh.1; от имени root на любую клиентскую машину архитектуры ${arch}. Скрипт scripts/allgohans используется для выполнения команд на всех клиентах архитектуры ${arch}. Скрипт scripts/checkmachines отслеживает уровень загрузки узлов кластера и распределяет, какой из узлов будет строить очередной порт. Этот скрипт не слишком умен и время от времени умирает. Лучше всего запускать его при загрузке основной машины кластера (pointyhat или dosirak) в цикле &man.while.1;. Подготовка ограниченной среды сборки Пакеты собираются в ограниченной (chroot) среде, которая разворачивается скриптом portbuild из архива ${arch}/${branch}/tarballs/bindist.tar. Этот архив создается при помощи скрипта mkbindist, конфигурация которого описывается файлом ${arch}/${branch}/mkbindist.conf. Скрипт должен запускаться с правами пользователя root и следующими параметрами: /var/portbuild&prompt.root; scripts/mkbindist ${arch} ${branch} При указании в файле mkbindist.conf параметра ftp=1 с адреса ftp://${ftpserver}/${ftpurl}/${rel} будет загружен предварительно собранный релиз. Если указано ftp=0 и buildworld=1, скрипт mkbindist выполнит makeworld для того, чтобы собрать релиз на месте [XXX Эта часть в настоящее время не работает]. Если оба параметра равны нулю (ftp=0 и buildworld=0), то mkbindist будет использовать существующее на момент запуска состояние дерева ${worlddir} для создания bindist.tar. На практике это означает, что вы должны предварительно установить систему в ${worlddir}, что обычно делается при помощи скрипта makeworld: /var/portbuild&prompt.root; scripts/makeworld ${arch} ${branch} [-nocvs] Эта команда соберет систему на базе исходных текстов в дереве ${arch}/${branch}/src и установит ее в ${worlddir}. Исходные тексты будут обновлены, если не указан параметр -nocvs. Содержимое архива bindist.tar будет распаковано на каждом клиенте в период загрузки, а также на старте каждого прохода скрипта dopackages. Запуск сборки Для сборки пакетов используются скрипты scripts/dopackages*. Наиболее полезными являются: + + dopackages.4 - собирает пакеты для версии 4.X + + + + + dopackages.4-exp - производит сборку ветви + для версии 4.X с экспериментальными изменениями (ветвь 4-exp) + + + dopackages.5 - собирает пакеты для версии 5.X - dopackages.4 - собирает пакеты для версии 4.X + dopackages.5-exp - производит сборку ветви + для версии 5.X с экспериментальными изменениями (ветвь 5-exp) - dopackages.4-exp - производит сборку ветви - для версии 4.X с экспериментальными изменениями (ветвь 4-exp) + dopackages.6 - собирает пакеты для версии 6.X + + + dopackages.7 - собирает пакеты для версии 7.X + + + Все они вызывают универсальный скрипт dopackages, и являются символьными ссылками на dopackages.wrapper. Для создания скрипта для сборки пакетов новой ветви достаточно создать символическую ссылку dopackages.${branch}, указывающую на dopackages.wrapper. Могут быть указаны многочисленные параметры, например: dopackages.5 ${arch} [-options] [-options] может быть произвольным набором из следующих опций: -nofinish - Не производить пост-обработку по завершении сборки. Полезно, если процесс сборки потребуется рестартовать. В обычных ситуациях эту опцию следует использовать всегда. -finish - Произвести пост-обработку (и только: собственно сборку не производить). -restart - Рестартовать прерванный (или незавершенный, т.е. запущенный без флага -finish) процесс сборки с самого начала. При этом порты, попытка сборки которых на предыдущем проходе завершилась неудачно, будут пересобраны. -continue - Продолжить прерванный (или незавершенный) процесс сборки. Порты, не прошедшие сборку, не пересобираются. -incremental - Сравнить необходимые поля в текущем файле INDEX с его предыдущим состоянием, удалить пакеты и журналы их сборки для обновившихся портов и пересобрать их. Этот ключ позволяет существенно сократить время сборки, поскольку нет необходимости пересобирать каждый раз не изменившиеся порты. -cdrom - Текущая сборка предназначена для помещения на CD-ROM, поэтому исходные архивы и пакеты портов, помеченных NO_CDROM должны быть удалены при пост-обработке. -nobuild - Произвести первоначальную подготовку, не запуская собственно процесс сборки пакетов. -noindex - Не перестраивать файл INDEX в ходе препроцессинга. -noduds - Не перестраивать файл duds (список портов, которые не будут строиться, например, помеченные признаками IGNORE, NO_PACKAGE и т.п.) перед процессом сборки. -trybroken - Пытаться собрать порты, помеченные как BROKEN (по умолчанию выключено, поскольку кластер архитектуры &i386; довольно быстр, и при инкрементальной сборке больше времени тратится на пересборку того, что все равно не сможет собраться. С другой стороны, кластеры других архитектур достаточно медленны, так что пытаться собирать на них порты с флагом BROKEN было бы напрасной тратой времени. -nocvs - Не выполнять обновление (cvs update) дерева исходных текстов (src) на этапе препроцессинга. -noportscvs - Не обновлять (cvs update) дерево портов (ports) на этапе препроцессинга. -nodoccvs - Не обновлять (cvs update) дерево документации - (doc) в ходе препроцессинга. + (doc) в ходе препроцессинга. (устаревшая опция) -norestr - Не пытаться компилировать порты, помеченные как RESTRICTED. -plistcheck - Считать ошибкой оставление лишних файлов после деинсталляции порта. -distfiles - Собрать архивы исходных файлов (distfiles) для дальнейшего их переноса на ftp-master. Эту опцию следует использовать изредка, поскольку она требует очень много места. Исходные архивы следует удалить после загрузки их на ftp-master. -fetch-original - Загружать исходные архивы с оригинальных сайтов, определенных переменными MASTER_SITES, а не с ftp-master. Убедитесь, что процесс сборки пакетов для архитектуры ${arch} запускается от имени пользователя ports-${arch}; в противном случае ошибки неизбежны. Сборка пакетов производится в два идентичных прохода. Иногда временные проблемы, такие как ошибки NFS или недоступность FTP-сайтов, могут прервать сборку. Дублирование попыток позволяет обойти подобные проблемы. Проверьте, чтобы ports/Makefile не ссылался на пустые подкаталоги. В особенности это важно для сборки ветви 4-exp. Если процесс сборки обнаруживает пустой каталог, обе фазы сборки вскоре остановятся. При этом в файлы ${arch}/${branch}/make.[0|1] будет записано сообщение об ошибке примерно такого вида: don't know how to make dns-all(continuing) Для исправления ситуации просто закомментируйте или удалите строчки SUBDIR, указывающие на пустые подкаталоги. После этого вы можете перезапустить сборку командой dopackages, добавив ей параметр -restart. Процесс сборки Полный процесс сборки без каких-либо ключей, начинающихся с -no, выполняет следующую последовательность операций: Извлечение из CVS-репозитория текущего дерева ports [*] - - Извлечение из CVS-репозитория текущего дерева - doc [*] - - - Извлечение из CVS-репозитория дерева src необходимой ветви [*] Проверка файлов Makefile на отсутствие строк SUBDIR [*] Создание файла duds, содержащего список портов, которые не надо пытаться собирать [*] [+] Генерация нового файла INDEX [*] [+] Начальная подготовка узлов, которые будут участвовать в сборке [*] [+] Построение списка портов ограниченного распространения (restricted) [*] [+] Сборка пакетов (фаза 1) [++] Повторная установка узлов сборки [+] Сборка пакетов (фаза 2) [++] [*] Результаты выполнения этих шагов записываются в файл ${arch}/${branch}/build.log, а также в стандартный вывод для ошибок консоли, с которой запускался скрипт dopackages. [+] При неудачном завершении любого из этих шагов процесс прекращается. [++] Результаты выполнения пишутся в файл ${arch}/${branch}/make.[0|1], где make.0 соответствует первой, а make.1 второй фазе сборки. Журналы сборки отдельных портов записываются в файлы ${arch}/${branch}/logs, а журналы портов, собравшихся неудачно, в ${arch}/${branch}/errors. + + Ранее из репозитория извекалось также дерево документации; + в настоящий момент это считается ненужным. + Прерывание процесса сборки Для прерывания процесса сборки обычно достаточно послать сигнал HUP процессам dopackages* или вызванным ими процессам make. Процессы, запущенные на узлах сборки, завершатся самостоятельно в течение нескольких минут (их наличие следует проверять командой ps x). Обычно достаточно следующей команды: &prompt.user; killall -HUP sh ssh make Удалите файл ${arch}/lock перед тем, как перезапустите сборку. Слежение за процессом Команда scripts/stats ${branch} показывает количество собранных на настоящий момент пакетов. Команда cat /var/portbuild/*/loads/* покажет текущую загрузку клиентских машин и количество процессов сборки, запущенных на них. Выполнение tail -f ${arch}/${branch}/build.log продемонстрирует общее состояние процесса сборки. В случае, если порт не собирается, и из логов не понятны причины этого, вы можете сохранить рабочий каталог сборки (WRKDIR) для последующего анализа. Для этого создайте файл .keep в каталоге порта. При следующей сборке порта кластером архив WRKDIR будет помещен в файл ${arch}/${branch}/wrkdirs. Следите за выводом команды &man.df.1;. Если файловая система, содержащая /var/portbuild, переполнится, будет Очень Плохо. Сборка пакетов для релизов При сборке пакетов для включения в релиз может потребоваться ручное обновление иерархий ports и src до нужного тэга, а также использование опций -nocvs и -noportscvs. Для подготовки комплекта пакетов для помещения на CD-ROM используйте параметр -cdrom при запуске dopackages. Если на кластере достаточно дискового пространства, можно применить ключ -distfiles для выкачивания дистрибутивных архивов. Первая сборка должна быть произведена с параметром -distfiles. По завершении первого процесса сборки перезапустите его с параметрами -restart -distfiles -fetch-original, для того чтобы выкачать обновленные дистрибутивы. Затем, на этапе финальной обработки, соберите список файлов при помощи команды &prompt.user; cd ${arch}/${branch} &prompt.user; find distfiles > distfiles-${release} Этот файл обычно копируют в каталог i386/${branch} главной машины кластера. Данная процедура помогает чистить комплект дистрибутивных архивов, располагающийся на ftp-master. Если дисковое пространство заканчивается, можно сохранить архивы для свежих релизов, а прочие — удалить. После копирования дистрибутивов (см. ниже) надо создать окончательный комплект пакетов для релиза. Для полного спокойствия, запустите скрипт ${arch}/${branch}/cdrom.sh вручную, чтобы быть уверенным, что все пакеты ограниченного распространения и их исходные архивы удалены. Затем скопируйте каталог ${arch}/${branch}/packages в ${arch}/${branch}/packages-${release}. После того, как пакеты переложены в надежное место, свяжитесь с группой &a.re; и сообщите им расположение финального комплекта пакетов. Помните о необходимости координации с группой &a.re; по поводу времени и статуса сборки пакетов для релизов. Загрузка пакетов для раздачи После завершения сборки пакеты и/или их исходные архивы могут быть загружены на ftp-master для раздачи по сети зеркал FTP. Если сборка велась с ключом -nofinish, не забудьте произвести пост-обработку при помощи команды dopackages -finish (будут удалены пакеты, помеченные как RESTRICTED и NO_CDROM, а также пакеты, отсутствующие в файле INDEX, из файла INDEX будут удалены ссылки на не собравшиеся пакеты, и, наконец, будет создан файл CHECKSUM.MD5 с контрольными суммами собранных пакетов; кроме того, эта фаза переместит исходные архивы из каталога distfiles/.pbtmp в distfiles/, а также удалит исходные архивы для портов, помеченных как RESTRICTED и NO_CDROM). Хорошей идеей является запустить вручную скрипты restricted.sh и/или cdrom.sh после завершения работы dopackages просто для собственного спокойствия. Скрипт restricted.sh запускается перед копированием на ftp-master; затем, перед подготовкой финального набора пакетов для релиза выполните cdrom.sh. Пакеты можно копировать во временную область на ftp-master примерно такой командой: &prompt.root; cd /var/portbuild/${arch}/${branch} &prompt.root; tar cfv - packages/ | ssh portmgr@ftp-master tar xfC - w/ports/${arch}/tmp/${branch} Затем, на машине ftp-master, убедитесь, что набор пакетов скопирован корректно, удалите старый набор (из каталога ~/w/ports/${arch}), и переместите новый на его место. Некоторые каталоги на ftp-master на самом деле являются символьными ссылками. Убедитесь, что вы перемещаете новый набор пакетов в реальный каталог, а не на место расположения одной из ссылок. Дистрибутивные архивы копируются при помощи команды rsync: &prompt.root; cd /var/portbuild/${arch}/${branch} &prompt.root; rsync -r -v -l -p -c -n distfiles/ portmgr@ftp-master:w/ports/distfiles/ | tee log ВСЕГДА для начала используйте ключ -n команды rsync и проверяйте ее вывод. Если все выглядит нормально, перезапустите rsync без опции -n. Экспериментальная сборка Время от времени для тестирования новых возможностей или исправлений общей инфраструктуры портов (bsd.port.mk), а также для тестирования крупных обновлений, затрагивающих существенную часть пакетов, проводится сборка с экспериментальными патчами. Текущей - экспериментальной веткой является 4-exp в архитектуре + экспериментальной веткой является 5-exp в архитектуре &i386;. В целом, экспериментальная сборка производится так же, как и обычная. Основное отличие: перед запуском скрипта dopackages нужно применить к дереву портов необходимые изменения. Хорошей идеей будет сохранить копии всех изменяемых файлов, а также их список. К списку вы сможете вернуться перед произведением окончательного коммита. Для создания контрольного экземпляра для сравнения следует сначала произвести сборку той ветви архитектуры &i386;, на которой основана экспериментальная ветвь (в настоящее время это ветвь - 4). Перед экспериментальной сборкой выгрузите + 5). Перед экспериментальной сборкой выгрузите деревья src и ports на момент произведения контрольной сборки. В этом случае вы можете быть уверены, что сравниваете яблоки с яблоками. Два кластера сборки могут производить контрольную и экспериментальную сборку одновременно. Это может ощутимо сэкономить общее время сборки. По завершении сборки сравните результаты контрольной и экспериментальной сборок примерно такой командой (предполагается, что - контрольной является ветка 4, а - экспериментальной — 4-exp): + контрольной является ветка 5, а + экспериментальной — 5-exp): - &prompt.user; cd /var/portbuild/i386/4-exp/errors -&prompt.user; find . -name \*.log\* | sort > /tmp/4-exp-errs -&prompt.user; cd /var/portbuild/i386/4/errors -&prompt.user; find . -name \*.log\* | sort > /tmp/4-errs + &prompt.user; cd /var/portbuild/i386/5-exp/errors +&prompt.user; find . -name \*.log\* | sort > /tmp/5-exp-errs +&prompt.user; cd /var/portbuild/i386/5/errors +&prompt.user; find . -name \*.log\* | sort > /tmp/5-errs Если с момента завершения одной из сборок прошло достаточно много времени, журналы сборки могут быть автоматически архивированы bzip2. В этом случае используйте sort | sed 's,\.bz2,,g'. - &prompt.user; comm -3 /tmp/4-errs /tmp/4-exp-errs | less + &prompt.user; comm -3 /tmp/5-errs /tmp/5-exp-errs | less Результатом работы последней команды будет отчет, состоящий из двух столбцов. В первой колонке будут перечислены порты, сборка которых не удалась в контрольном, но не в экспериментальном случае; второй столбец описывает противоположную ситуацию. Причины, по которым порт может оказаться в первом списке, включают: Порт был исправлен с момента последнего контрольного запуска, или обновлен до более свежей версии, которая также не собирается (порт с новой версией появится во втором столбце) Сборка порта исправлена патчами экспериментальной версии Порт не собирается экспериментальной сборкой из-за ошибок в зависимых портах Во втором столбце порт может оказаться по следующим причинам: Порт не собирается с экспериментальными изменениями [1] Порт был обновлен с момента контрольной сборки и стал несобираемым [2] Порт не собрался по причине временных ошибок (недоступный FTP сайт, ошибка ввода-вывода на клиенте и т.п.) Перед коммитом экспериментальных обновлений необходимо изучить содержимое обоих столбцов. Чтобы отличить ситуации [1] и [2], можно пересобрать соответствующие пакеты в контрольной ветке: - &prompt.user; cd /var/portbuild/i386/4/ports + &prompt.user; cd /var/portbuild/i386/5/ports Не забудьте обновить дерево портов до той же даты, что и дерево экспериментальной сборки. Для подготовки контрольной ветви используйте команду: - &prompt.user; /var/portbuild/scripts/dopackages.4 -noportscvs -nobuild -nocvs -nofinish + &prompt.user; /var/portbuild/scripts/dopackages.5 -noportscvs -nobuild -nocvs -nofinish Сборка должна производиться из каталога packages/All. Изначально этот каталог должен быть пуст, за исключением символьной ссылки Makefile. Если этой ссылки нет, создайте ее: - &prompt.user; cd /var/portbuild/i386/4/packages/All + &prompt.user; cd /var/portbuild/i386/5/packages/All &prompt.user; ln -sf ../../Makefile . &prompt.user; make -k -j<#> <список пакетов для сборки> <#> описывает уровень параллелизма сборки. Обычно, это сумма весов клиентских машин, указанных в /var/portbuild/i386/mlist, если у вас нет причин проводить более тяжелую или, наоборот, облегченную сборку. <список пакетов для сборки> представляет собой список имен пакетов (включая их версии) в том виде, как они представлены в файле INDEX. Суффикс PKGSUFFIX (.tgz or .tbz) является необязательным. Будут собраны только указанные пакеты, а также их зависимые порты. Процесс сборки можно контролировать так же, как и стандартную сборку. После того, как все ошибки исправлены, вы можете произвести коммит комплекта исправлений. Является хорошим тоном отправить письмо с темой HEADS UP в списки рассылки ports@FreeBSD.org и ports-developers@FreeBSD.org с информацией о внесенных изменениях. Краткая аннотация изменений также должна быть добавлена в файл /usr/ports/CHANGES.