| Каталог документации / Раздел "Руководства по FreeBSD на русском" / Оглавление документа |
| |
|
$FreeBSD$
FreeBSD is a registered trademark of Wind River Systems, Inc. This is expected to change soon.
CVSup is a registered trademark of John D. Polstra.
Intel, Celeron, EtherExpress, i386, i486, Itanium, Pentium, and Xeon are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries.
XFree86 is a trademark of The XFree86 Project, Inc.
Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this document, and the FreeBSD Project was aware of the trademark claim, the designations have been followed by the ``™'' or the ``®'' symbol.
В этой статье описывается подход, который используется группой подготовки релизов FreeBSD для создания качественных версий Операционной Системы FreeBSD. В ней детально описывается методология, используемая для официальных релизов FreeBSD и рассказывается об инструментах, доступных тем, кто интересуется созданием модифицированных релизов FreeBSD для тиражирования внутри организации или в коммерческих целях.
Разработка FreeBSD представляет собой весьма открытый процесс. FreeBSD составляется в результате общих усилий тысяч людей по всему миру. Проект FreeBSD предоставляет анонимный публичный доступ по протоколу CVS[1], так что любой может получить доступ к журналу изменений, разницам (патчам) между ветками разработки и другим продвинутым возможностям, которые даёт строгое управление исходным кодом. Это сильно помогает в привлечении к FreeBSD всё большего количества талантливых разработчиков. Однако, и я думаю, что все со мной согласятся, наступит хаос, если доступ по записи будет открыт всем в Internet. Поэтому только ``избранная'' группа примерно из 300 человек имеет доступ по записи в CVS-хранилище. Эти коммиттеры[6] отвечают в целом за разработку FreeBSD. Выбираемая из самых заслуженных разработчиков группа правления[7] обеспечивает некоторый уровень управления проектом.
Темп разработок, ведущихся во FreeBSD, оставляет мало времени на тщательную доводку системы до качества продуктивного релиза. Для решения этой проблемы разработка ведётся в два параллельных потока. Основной веткой разработки является HEAD, она же основная линия нашего дерева CVS, известная также под именем ``FreeBSD-CURRENT'' или, для краткости, ``-CURRENT''.
Поддерживается и более стабильная ветка, известная как ``FreeBSD-STABLE'' или, для краткости, ``-STABLE''. Обе ветки находятся в основном CVS-хранилище в Калифорнии и реплицируются при помощи CVSup[2] на зеркала по всему миру. FreeBSD-CURRENT[8] является ``передним краем'' работ над FreeBSD, через который попадают все изменения в системе. FreeBSD-STABLE является веткой разработки, из которой создаются основные релизы. В эту ветку изменения попадают разными путями, и предполагается, что сначала они попали в FreeBSD-CURRENT, где были тщательно протестированы сообществом наших пользователей.
В промежутке между релизами машинами Проекта FreeBSD, выделенными для построения системы, каждую ночь автоматически собираются снэпшоты, которые доступны для сгрузки по адресу ftp://stable.FreeBSD.org/. Общедоступность снэпшотов бинарных релизов, а также желание сообщества наших пользователей отслеживать работу над -STABLE при помощи CVSup и ``make world''[8] помогает поддержать весьма хорошее качество FreeBSD-STABLE, даже до выполнения мероприятий проверки качества, предваряющих выпуск основных релизов.
В процессе выпуска релиза пользователи постоянно присылают сообщения об ошибках и пожелания по расширению функциональности. Сообщения о проблемах попадают в наду базу данных GNATS[9] по электронной почте, посредством утилиты send-pr(1) или через Web-интерфейс, доступный по адресу http://www.FreeBSD.org/send-pr.html. Кроме множества различных технических списков рассылки о FreeBSD, по адресу Список рассылки, посвящённый контролю качества FreeBSD можно найти форум для обсуждения улучшений в ``процессе выпуска релизов''.
Для удовлетворения наших самых консервативно настроенных пользователей, начиная с FreeBSD 4.3, появились ветки для отдельных релизов. Эти ветки создаются вскоре после того, как выпускается окончательный релиз. После его выхода в ветку релиза помещаются только самые критичные исправления и добавления, касающиеся безопасности. Кроме обновлений исходных текстов посредством CVS, для систем веток RELENG_X_Y имеются и бинарные наборы патчей.
В Section 2 обсуждаются различные этапы процесса подготовки релиза вплоть до построения актуальной системы, а Section 3 описывает сам процесс сборки. Section 5 описывает, как базовый релиз может быть расширен третьими сторонами, а Section 6 проясняет некоторые из уроков, полученных при выпуске релиза FreeBSD 4.4. Наконец, в Section 7 описывается будущие направления работ.
Новые релизы FreeBSD выпускаются из ветки -STABLE с интервалом примерно в четыре месяца. Процесс выпуска релизов FreeBSD начинается за 45 дней до предполагаемой даты релиза с того, что ответственный за релиз посылает сообщение по электронной почте в адрес списков рассылки для разработчиков, чтобы напомнить последним о наличи всего лишь 15 дней на внемение новых изменений до момента заморозки кода. В этот период многие разработчики выполняют действия, известные как ``MFC-переносы''. MFC означает ``Merge From CURRENT'' (перенос из CURRENT) и описывает процесс переноса протестированных изменений из нашего дерева разработки -CURRENT в наше дерево -STABLE.
За тридцать дней до предполагаемого релиза хранилище исходных текстов переводится в
режим ``стабилизации кода''. В этот период все изменения в дереве -STABLE должны
подтверждаться Release Engineering Team <[email protected]>. В этот 15-дневный период
разрешены следующие типы изменений:
Исправления ошибок.
Обновление документации.
Исправления любого характера, касающиеся безопасности.
Незначительные исправления в драйверах устройств, такие, как, например, добавление новых ID устройств.
Любые другие изменения, которые одобряет группа подготовки релиза, с учётом потенциального риска.
После первых 15 дней стабилизации кода выпускается предварительный релиз, предначенный для широкого тестирования, а код переводится в состояние ``заморозки'', когда становится гораздо труднее доказывать необходимость внесения новых изменений в систему, если они не касаются исправления серьёзных ошибок или информационной безопасности. Во время заморозки кода каждую неделю выпускается не менее одной предварительной версии релиза, до тех пор, пока не будет готов окончательный вариант релиза. В дни, предшествующие выпуску окончательного релиза, группа его подготовки работает в постоянном контакте со службой безопасности и людьми, поддерживающими документацию и порты, чтобы обеспечить доступность всех компонентов, необходимых для успешного выпуска релиза.
После того, как для широкого тестирования было выпущено несколько предварительных релизов и все основные проблемы были решены, может начаться процесс ``шлифовки'' окончательного релиза.
Как сказано во вводной части, ветка RELENG_X_Y является сравнительно новым добавлением в нашей методологии подготовки релизов. Первым шагом в создании этой ветки является проверка того, что вы работаете с самой последней версией исходных текстов RELENG_X, из которой вы хотите создать новую ветку.
/usr/src# cvs update -rRELENG_4 -P -d
Следующим шагом является создание тэга точки ответвления, чтобы диффы облегчили работу с началом ветки в CVS:
/usr/src# cvs rtag -rRELENG_4 RELENG_4_8_BP src
После этого создаётся тэг новой ветки по команде:
/usr/src# cvs rtag -b -rRELENG_4_8_BP RELENG_4_8 src
Note: Использование тэгов RELENG_* разрешено только менеджерам CVS и участникам группы по выпуску релизов.
Перед тем, как окончательный релиз будет помечен, построен и выпущен, необходимо модифицировать следующие файлы, отразив в них корректную версию FreeBSD:
doc/en_US.ISO8859-1/books/handbook/mirrors/chapter.sgml
doc/en_US.ISO8859-1/books/porters-handbook/book.sgml
doc/share/sgml/freebsd.ent
src/Makefile.inc1
src/UPDATING
src/gnu/usr.bin/groff/tmac/mdoc.local
src/release/Makefile
src/release/doc/en_US.ISO8859-1/share/sgml/release.dsl
src/release/doc/share/examples/Makefile.relnotesng
src/release/doc/share/sgml/release.ent
src/share/examples/cvsup/standard-supfile
src/sys/conf/newvers.sh
src/sys/sys/param.h
src/usr.sbin/pkg_install/add/main.c
www/en/docs.sgml
www/en/cgi/ports.cgi
ports/Tools/scripts/release/config
Новый релиз должен быть также отражён в файлах замечаний к релизу и информации о замеченных ошибках (в ветке релиза), а файлы соответствующим образом обрезаны (в ветке stable/current):
src/release/doc/en_US.ISO8859-1/relnotes/common/new.sgml
src/release/doc/en_US.ISO8859-1/errata/article.sgml
Утилита sysinstall должна быть обновлена и указывать количество доступных портов и объём дискового пространства, требуемого для Колллекции Портов. На данный момент эта информация хранится в файле src/release/sysinstall/dist.c.
После построения релиза для оповещения мирового сообщества о выпусек релиза необходимо обновить некоторые файлы.
www/share/sgml/includes.release.sgml
www/share/sgml/includes.release.xsl
www/en/releases/*
www/en/releng/index.sgml
www/en/news/news.xml
src/share/misc/bsd-family-tree
При готовности окончательного релиза следующая команда создаст тэг RELENG_4_8_0_RELEASE.
/usr/src# cvs rtag -rRELENG_4_8 RELENG_4_8_0_RELEASE src
Менеджеры документации и портов отвечают за внесение тэга в соответствующие ветки с тэгом RELEASE_4_8_0.
Иногда в последний момент, уже после создания последних тэгов может потребоваться внесение исправлений. На практике это не является проблемой, так как CVS позволяет выполнять манипуляции с тэгами по команде cvs tag -d tagname filename. Очень важно, чтобы все последние изменения были помечены соответствующим тэгом, как часть релиза. Релизы FreeBSD должны быть всегда повторяемыми. Локальные изменения в параметры окружения выпускающего релиз недопустимы.
``Релизы'' FreeBSD могут быть построены любым человеком, имеющим быстродействующую машину и доступ к хранилищу исходных текстов. (Это должен быть любой, так как мы предоставляем анонимный доступ к CVS! Обратитесь к Руководству для прояснения деталей.) Единственнным особым требованием является наличие устройства vn(4). (В -CURRENT это устройство было заменено на новый драйвер дисков в памяти md(4).) Если устройтво в вашем ядре не подгружено, то модуль ядра должен быть подгружен автоматически при выполнении команды vnconfig(8) на этапе создания носителя для загрузки. Все инструменты, необходимые для построения релиза, доступны из хранилища CVS в каталоге src/release. Эти инструменты предоставляют единый метод построения релизов FreeBSD. Полный релиз может быть реально построен при помощи лишь одной команды, включая создание ISO-образов, подходящих для записи на CDROM, установочных дискет и установочного каталога FTP. Эта команда называется соответствующим образом, make release.
Для успешного построения релиза вы должны сначала заполнить каталог /usr/obj, запустив команду make world или просто make buildworld. Цель, выполняемая для построения релиза, требует корректного задания нескольких переменных, используемых при его сборке:
CHROOTDIR - Каталог, используемый в среде с изменённой корневой файловой системой при построении полного релиза.
BUILDNAME - Наименование строящегося релиза.
CVSROOT - Местонахождение CVS-хранилища.
RELEASETAG - Тэг CVS, соответствующий релизу, который вы собираетесь строить.
Если у вас ещё нет доступа к локальному CVS-хранилищу, то вы можете зеркалировать одно из них при помощи CVSup. Поставляемый sup-файл, /usr/share/examples/cvsup/cvs-supfile, может служить хорошей отправной точкой для зеркалирования хранилища CVS.
Если RELEASETAG опущен, то релиз будет строиться из ветки HEAD (известной как -CURRENT). Релизы, строящиеся из этой ветки обычно называют ``снэпшотами -CURRENT''.
Для настройки построения релиза существует много других переменных Большинство из этих переменных описаны в начале файла src/release/Makefile. Точная команда, служащая для построения официального релиза FreeBSD 4.7 (x86) такова:
make release CHROOTDIR=/local3/release \
BUILDNAME=4.7-RELEASE \
CVSROOT=/host/cvs/usr/home/ncvs \
RELEASETAG=RELENG_4_7_0_RELEASE
Makefile для релиза может быть разбит на несколько различных шагов.
Создание чистого системного окружения в отдельной иерархии каталогов по команде ``make installworld''.
Выгрузка из CVS чистой версии исходных текстов системы, документации и портов в иерархию для построения релиза.
Создание копии /etc и /dev в окружении с извенённым корнем файловой системы.
Смена корневой файловой системы на иерархию построения релиза, чтобы избежать влияния внешнего окружения на построение.
Выполнение make world в окружении с изменённой корневой файловой системой.
Построение бинарных файлов для работы с Kerberos.
Построение ядра GENERIC.
Создание промежуточного дерева каталогов, где будут строиться бинарные файлы и формироваться дистрибутивы.
Построение и установка инструментов для работы с документацией, необходимых для преобразования исходных текстов документации (SGML) в формат HTML и текстовые документы, которые сопутствуют релиз.
Построение и установка актуальной документации (руководства пользователей, учебники, замечания к релизу, перечень аппаратной совместимости и так далее.)
Построение ``свёрнутых'' бинарных файлов, используемых на установочных дискетах.
Подготовка дистрибутивных архивов бинарных файлов и исходных текстов.
Создание загрузочного носителя и ``fixit''-дискеты.
Создание иерархии для установки при помощи FTP.
(опционально) Создание образов ISO для носителей CDROM/DVD.
Для получения более полной информации об инфраструктуре построения релизов, пожалуйста, обратитесь к справочной странице по release(7).
XFree86™ является важным компонентом для многих пользователей настольных систем. До выхода FreeBSD 4.6-RELEASE в релизах по умолчанию использовалась XFree86 3.X. Самым простым способом построения этих версий является использование скрипта src/release/scripts/X11/build_x.sh. Он требует, чтобы на хост, выполняющий построение, уже были установлены XFree86 и Tcl/Tk. После компиляции необходимых X-серверов, скрипт преобразует все файлы в архивные, которые sysinstall(8) ожидает найти в каталоге XF86336 на установочном носителе.
Начиная с FreeBSD 4.6-RELEASE, sysinstall(8) по умолчанию устанавливает XFree86 4.X, как набор ``обычных'' пакаджей. Это могут быть как пакаджи, созданные в процессе работы кластера построения портов, так и пакаджи, построенные из соответствующим образом помеченного дерева портов.
Note: Важно, чтобы из файла /etc/make.conf были удалены все установки, специфичные для конкретного хоста. К примеру, будет глупо распространять бинарные файлы, построенные на системе с переменной CPUTYPE, указывающей на определённый тип процессора.
Коллекция портов FreeBSD
содержит более 10,000 программных пакетов сторонних разработчиков, которые доступны для
FreeBSD. За поддержку целостности дерева портов, которое может использоваться для
создания бинарных пакаджей, поставляемых с официальными релизами FreeBSD, отвечает Ports
Management Team <[email protected]>.
Рассмотрение работ с нашей коллекцией пакетов сторонних разработчиков при подготовке релизов выходит за рамки этого документа. Этот вопрос глубоко рассмотрен в отдельной статье, The Release Engineering of Third Party Packages.
Начиная с FreeBSD 4.4, Проект FreeBSD принял решение распространять все четыре образа ISO, ранее продаваемые через BSDi/Wind River Systems/FreeBSD Mall как ``официальные'' дистрибутивы на CDROM. Каждый из четырёх дисков должен содержать файл README.TXT, описывающий содержимое диска, файл CDROM.INF, в котором находятся мета-данные о диске для того, чтобы sysinstall(8) мог проверять и использовать содержимое, а также файл filename.txt, содержащий перечень содержимого на диске. Этот перечень может быть создан простой командой:
/stage/cdrom# find . -type f | sed -e 's/^\.\///' | sort > filename.txt
Специфичные требования для каждого CD описываются ниже.
Первый диск практически полностью создаётся командой make release. Единственным изменением, которое нужно внести в каталог disc1, является добавление подкаталогов tools и XFree86, а также перенос максимально возможного количества программных пакетов сторонних разработчиков, которые поместятся на диск. Каталог tools содержит программное обеспечение, позволяющее пользователям создавать установочные дискеты из других операционных систем. Этот диск нужно сделать загрузочным, чтобы пользователям современных ПК не нужно было создавать установочные дискеты.
Если предоставляется другая версия XFree86, до должны быть обновлены утилита sysinstall(8), отражающая новое местоположение, и инструкции по установке. Соответствующий код находится в каталоге src/release/sysinstall в ветке -STABLE или в src/usr.sbin/sysinstall в ветке -CURRENT. Должны быть обновлены конкретно файлы dist.c, menus.c и config.c.
Второй диск также в основном создаётся по команде make release. Он содержит ``живую файловую систему'', которую можно использовать из sysinstall(8) для исправления процесса установки FreeBSD. Этот диск должен быть загрузочным и содержать также упакованную копию хранилища CVS в каталоге CVSROOT и демонстрационные версии коммерческого программного обеспечения в каталоге commerce.
Оставшиеся два диска содержат дополнительные программные пакеты для FreeBSD. Они должны быть объединены в группы (кластеры), чтобы отдельный пакет и все его зависимости находились на одном и том же диске. Дополнительная информация о создании этих дисков находится в статье The Release Engineering of Third Party Packages.
После того, как релиз был тщательно протестирован и подготовлен к распространению, должен быть обновлён главный FTP-сервер. Все официальные общедоступные серверы FTP-серверы FreeBSD являются зеркалами главного сервера, открытого только другим серверам FTP. Этот сервер известен под именем ftp-master. Когда релиз готов, на сервере ftp-master должны быть изменены следующие строки:
Установочный каталог FTP, получаемый по команде make release.
Полный комплект построенных пакаджей для этого релиза.
Символическая ссылка на ../../../tools.
Символическая ссылка на ../../../ports/arch/packages-X.Y-release.
ISO-образы. Здесь ``*'' это disc1, disc2 и так далее. Только если здесь есть disc1 и альтернативный первый установочный CD (например, обрезанная установка без оконной системы), то здесь может быть также и mini.
Для получения дополнительной информации о системе зеркальных FTP-серверов FreeBSD, пожалуйста, прочтите статью о Зеркалировании FreeBSD.
Может пройти от нескольких часов до двух дней между тем, как обновится ftp-master, и на основной массе FTP-серверов 1-го уровня появится новое программное обеспечение, в зависимотси от того, в тоже самое ли время пакадж был загружен. Обязательно, чтобы выпускающие релиз координировали свои действия с Администраторы зеркальных сайтов FreeBSD до того, как объявлять об общедоступности нового программного обеспечения с серверов FTP. В идеальном случае набора пакаджей к релизу должне быть загружен по крайней мере за четыре дня до момента выпуска релиза. Релиз должне быть загружен в промежутке от 24 до 48 часов до момента выхода запланированного релиза с выключенными полномочиями ``other''. Это позволит зеркалирующим серверам сгрузить его, но никто не сможет получить его с зеркальных серверов. В момент выхода релиза должно быть послано сообщение в адрес Администраторы зеркальных сайтов FreeBSD, говорящее о том, что релиз выпущен и наступило время для открытия доступа на зеркальных серверах. Обязательно вместе со временем укажите и часовой пояс, например, относительно GMT.
Вскоре появится: Советы по передаче ISO-образов FreeBSD на тиражирование и применяемые меры по контролю качества.
Хотя FreeBSD представляет собой законченную операционную систему, ничего не заставляет вас использовать систему только в том виде, который приготовлен нами для распространения. Мы попытались спроектировать систему максимально расширяемой, чтобы она могла выполнять роль платформы, на основе которой можно строить другие коммерческие продукты. Единственным ``правилом'', которое мы налагаем, является настоятельная рекомендация документировать улучшения, вносимые вами в дистрибутив FreeBSD с нетривиальными изменениями! Сообщество FreeBSD может помогать только пользователям того программного обеспечения, которое распространяем мы. Мы определённо приветствуем улучшения в форме, например, инструментов установки и администрирования, но не можем отвечать на вопросы о них.
Во многих местах имеются сложные условия, которые требуют размещения дополнительных модулей ядра или пользовательских инструментов на установочные дискеты. ``Быстрым и неаккуратным'' способом сделать это является изменение промежуточного каталога в существующей иерархии при выполнении make release:
Примените патчи или добавьте дополнительные файлы в каталог построения релиза с изменённых корнем файловой системы.
rm ${CHROOTDIR}/usr/obj/usr/src/release/release.[59]
перестройте sysinstall(8), ядро и остальные части системы, которые коснулись ваши изменения.
chroot ${CHROOTDIR} ./mk floppies
Дискеты нового релиза будут находиться в ${CHROOTDIR}/R/stage/floppies.
Либо может быть вызвана цель boot.flp построения или скрипт создания файловой системы, src/release/scripts/doFS.sh, которые может быть вызван напрямую.
Локальные патчи могут быть также приложены к построению релиза при помощи задания переменной LOCAL_PATCH при выполнении make release.
Инструмент установки и настройки системы FreeBSD, sysinstall(8), может работать по сценарию, полезному для автоматизированной установке в больших компаниях. Эта функциональность может использоваться совместно с технологией Intel® PXE[13] для первоначальной установки систем из сети, или с модифицированными загрузочными дискетами со скриптами sysinstall. Пример скрипта для sysinstall доступен в дереве CVS в виде файла src/release/sysinstall/install.cfg.
Формально процесс подготовки релиза для 4.4 начался 1 августа 2001 года. После этой
даты все без исключения изменения в ветке RELENG_4 FreeBSD
подтверждались Release Engineering Team <[email protected]>. Первый предварительный релиз
для архитектуры x86 был выпущен 16 августа, за ним выходило ещё 4 предварительных релиза,
и всё закончилось 18 августа выпуском окончательного релиза. Руководитель службы
безопасности очень плотно занимался процессом выпуска в последнюю неделю, так как в
предыдущих предварительных релизах были найдены проблемы, касающиеся информационной
безопасности. Чуть более чем за месяц в адрес Release Engineering Team <[email protected]>
поступило более 500 писем.
Сообщество наших пользователей весьма чётко показало, что безопасность и стабильность релиза FreeBSD не должна приноситься в жертву любым назначенным срокам окончания работ или планируемым датам выхода релиза. Проект FreeBSD за время своего существования значительно вырос, и никогда ранее необходимость в стандартизации процедур подготовки релизов не стояла так остро. Это стало ещё более важно, когда FreeBSD была перенесена на новые аппаратные платформы.
Нашим работам по подготовке релизов жизненно важно расти вместе с увеличением количества пользователей системы. Вместе с этим мы очень плотно работаем над документированием действий, выполняемых при выпуске релизов.
Параллелизм - некоторые этапы построения релиза на самом деле выполнять параллельно ``затруднительно''. Большинство выполняемых задач весьма интенсивно работают с I/O, так что для ускорения процесса make release наличие нескольких высокоскоростных дисков гораздо более важно, чем использование нескольких процессоров. Если для различных иерархий в chroot(2)-окружении используется несколько дисков, то извлечение из CVS деревьев ports и doc может выполняться одновременно с командой make world на другом диске. Использование RAID-решений (аппаратных или программных) может значительно сократить общее время построения.
Кроссплатформенное построение релизов - Построить релиз для IA-64 или Alpha на x86-оборудовании? make TARGET=ia64 release.
Тестирование - Нам нужна улучшенная автоматизированная система тестирования корректности для FreeBSD.
Инструменты установки - Наша программа установки давно пережила свой век. В разработке находятся несколько проектов, которые должны дать улучшенную технологию установки. Одним из самых многообещающих из них является проект libh[5], целью которого является создание новой интеллектуальной технологии работы с пакаджами и программы установки с GUI.
Я рад поблагодарить Джордана Хаббарда (Jordan Hubbard) за то, что он дал мне
возможность взять под свою ответственность некоторые части процесса подготовки релиза
FreeBSD 4.4, а также за все годы его работы, сделавшие FreeBSD такой, какой она является
сейчас. Конечно, релиз не был бы возможен без той работы, которую проделали Satoshi Asami
<[email protected]>, Steve Price <[email protected]>,
Bruce A. Mah <[email protected]>, Nik Clayton <[email protected]>,
David O'Brien <[email protected]>, Kris Kennaway <[email protected]>,
John Baldwin <[email protected]> и остальные члены
сообщества разработчиков FreeBSD. Я также рад выразить благодарность Rodney Grimes <[email protected]> и Poul-Henning Kamp
<[email protected]>, а также остальным,
работавшим над инструментами подготовки релизов в первые годы существования FreeBSD. Эта
статья была также написана под впечатлением документации по подготовке релизов от
CSRG[14], NetBSD Project[11] и замечаний Джона Балдвина (John Baldwin) по предлагаемому
процессу подготовки релизов[12].
[1] CVS - Concurrent Versions System http://www.cvshome.org
[2] CVSup - The CVS-Optimized General Purpose Network File Distribution System http://www.polstra.com/projects/freeware/CVSup
[4] Коллекция портов FreeBSD http://www.FreeBSD.org/ports
[5] Проект libh http://www.FreeBSD.org/projects/libh.html
[9] GNATS: The GNU Bug Tracking System http://www.gnu.org/software/gnats
[10] Статистика FreeBSD PR http://www.FreeBSD.org/prstats/index.html
[11] NetBSD Developer Documentation: Release Engineering http://www.NetBSD.org/developers/releng/index.html
[12] John Baldwin's FreeBSD Release Engineering Proposal http://people.FreeBSD.org/~jhb/docs/releng.txt
[14] Marshall Kirk McKusick, Michael J. Karels, and Keith Bostic: The Release Engineering of 4.3BSD
Этот, и другие документы, могут быть скачаны с ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/.
По вопросам связанными с FreeBSD, прочитайте документацию прежде чем писать в <[email protected]>.
По вопросам связанным с этой документацией, пишите <[email protected]>.
По вопросам связанным с русским переводом документации, пишите <[email protected]>.
|
Закладки на сайте Проследить за страницей |
Created 1996-2024 by Maxim Chirkov Добавить, Поддержать, Вебмастеру |