os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Initial import, synchronized with English 1.20

Browse source
This commit is contained in:
Andrey Zakhvatov 2004-01-07 09:24:58 +00:00
parent 2194b439bc
commit bd16d25bd6
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=19512
1 changed files with 759 additions and 0 deletions

759
ru_RU.KOI8-R/articles/5-roadmap/article.sgml Normal file
View file

@ -0,0 +1,759 @@
<!--
The FreeBSD Russian Documentation Project
$FreeBSDru: frdp/doc/ru_RU.KOI8-R/articles/5-roadmap/article.sgml,v 1.2 2004/01/06 18:28:30 andy Exp $
Original revision: 1.20
-->
<!DOCTYPE article PUBLIC "-//FreeBSD//DTD DocBook V4.1-Based Extension//EN" [
<!ENTITY % man PUBLIC "-//FreeBSD//ENTITIES DocBook Manual Page Entities//EN">
%man;
<!ENTITY % freebsd PUBLIC "-//FreeBSD//ENTITIES DocBook Miscellaneous FreeBSD Entities//EN">
%freebsd;
<!ENTITY % authors PUBLIC "-//FreeBSD//ENTITIES DocBook Author Entities//EN">
%authors;
<!ENTITY % teams PUBLIC "-//FreeBSD//ENTITIES DocBook Team Entities//EN">
%teams;
<!ENTITY % mailing-lists PUBLIC "-//FreeBSD//ENTITIES DocBook Mailing List Entities//RU">
%mailing-lists;
<!ENTITY % trademarks PUBLIC "-//FreeBSD//ENTITIES DocBook Trademark Entities//EN">
%trademarks;
<!ENTITY t.releng.3 "<literal>RELENG_3</literal>">
<!ENTITY t.releng.4 "<literal>RELENG_4</literal>">
<!ENTITY t.releng.5 "<literal>RELENG_5</literal>">
<!ENTITY t.releng.5.1 "<literal>RELENG_5_1</literal>">
<!ENTITY t.releng.5.2 "<literal>RELENG_5_2</literal>">
<!ENTITY t.releng.5.3 "<literal>RELENG_5_3</literal>">
<!ENTITY t.releng.head "<literal>HEAD</literal>">
]>
<article>
<articleinfo>
<title>Направления работ в 5-STABLE</title>
<authorgroup>
<corpauthor>The &os; Release Engineering Team</corpauthor>
</authorgroup>
<pubdate>$FreeBSD$</pubdate>
<copyright>
<year>2003</year>
<holder role="mailto:re@FreeBSD.org">The &os; Release
Engineering Team</holder>
</copyright>
<legalnotice id="trademarks" role="trademarks">
&tm-attrib.freebsd;
&tm-attrib.ieee;
&tm-attrib.intel;
&tm-attrib.sparc;
&tm-attrib.sun;
&tm-attrib.opengroup;
&tm-attrib.general;
</legalnotice>
</articleinfo>
<sect1 id="intro">
<title>Введение и информация общего характера</title>
<para>В январе 2003 года, после примерно трёх лет работы, была выпущена
&os; 5.0. Такие её возможности, как технология GEOM, мандантный контроль
доступа, ACPI, поддержка архитектур &sparc64; и ia64, работа с
мгновенными копиями UFS, фоновая проверка целостности файловой системы и
64-разрядная размерность узлов файловой системы делают эту операционную
систему привлекательной как для корпоративного, так и персонального
использования. Однако работа над некоторыми важными возможностями ещё
не завершена. Программная основа для высокоточной блокировки и
вытесняемости задач в ядре уже имеется, однако предстоит сделать ещё
больше. Производительность и стабильность по сравнению с &os;
4.<replaceable>X</replaceable> несколько снизилась, однако эти
характеристики должны быть восстановлены и даже улучшены.</para>
<para>Это несколько напоминает ситуацию, с которой &os; сталкивалась в
линейке 3.<replaceable>X</replaceable>. Работа над 3-CURRENT
затягивалась до бесконечности, и наконец было принято решение
<quote>просто выпустить её</quote>, а доработать позже. Такое решение
привело к тому, что качество релизов 3.0 и 3.1 не могло удовлетворить
большинство пользователей, и так было до версии 3.2, когда линейка была
признана <quote>стабильной</quote>. Хуже того, ветка &t.releng.3; была
создана на основе релиза 3.0. а ветка &t.releng.head; должна была вести к
4-CURRENT. В результате ветки &t.releng.head; и &t.releng.3; стали
сильно отличаться, что значительно осложнило поддержку ветки
&t.releng.3;. &os; 2.2.8 была оставлена как последняя версия &os;,
подходящая для продуктивной эксплуатации.</para>
<para>Нашей задачей является недопущение повторения такого сценария во
&os; 5.x. Откладывание ветки &t.releng.5; до момента, когда она станет
стабильной и достигнет качества продукта, готового к реальной
эксплуатации, обеспечит будущую поддержку этой ОС и объективную причину
перехода с версии 4.<replaceable>X</replaceable>, Для этого мы должны
определить слабые места и наметить способы их устранения. В этом
документе описаны те моменты, которые мы, как группа по подготовке
релизов, считаем значительными и те вопросы, которые должны быть решены
до создания ветки &t.releng.5;. Здесь не определяются все аспекты работы
над &os;, и мы готовы к дальнейшему обсуждению. Ничего из того, что
написано далее, не является инсинуациями против какой бы то ни было
персоны или группы, целью не является упрощение никакой сделанной кем-то
работы. Однако имеются некоторые важные вопросы, которые требуют
решительных и беспристрастных действий.</para>
</sect1>
<sect1 id="major-issues">
<title>Основные вопросы</title>
<para>Успех линейки 5.<replaceable>X</replaceable> зависит от возможности
предоставить высокоточное управление потоками выполнения и повторяемость
вызовов в ядре (что известно как SMPng), а также поддержки на уровне ядра
POSIX-потоков выполнения пользовательского уровня, не жертвуя при этом
общей стабильностью или производительностью системы.</para>
<sect2 id="SMPng">
<title>SMPng</title>
<para>Работам над SMPng и блокировками на уровне ядра уделяется самое
большое внимание для 5.<replaceable>X</replaceable>. На текущий момент
было выпущено несколько версий системы с глобальными семафорами на всё
ядро, известными как <quote>Giant</quote>. Страница о состоянии работ
над SMP по адресу <ulink url="http://www.FreeBSD.org/smp"></ulink>
содержит исчерпывающую информацию об общем состоянии SMPng. Информация
по конкретно работам над SMPng в драйверах устройств может быть найдена
на странице <ulink
url="http://www.FreeBSD.org/projects/busdma"></ulink>. В целом:</para>
<itemizedlist>
<listitem>
<para>VM: Функция ядра malloc изолирована и освобождена
от Giant. Распределитель зон UMA также не использует Giant.
Изоляция vm_object находится в работе и является важным шагом в
исключении Giant из работы с буферами/кэшем. Изоляция pmap ещё
не реализовывалась.</para>
</listitem>
<listitem>
<para>GEOM: Уровень блоков GEOM был разработан с учётом работы без
Giant и он позволяет работать модулям GEOM и низлежащим драйверам
блочных устройств без Giant. На данный момент только драйверы
&man.ata.4; и &man.aac.4; разделены и работают без
Giant. Работа над остальными драйверами блочных устройств ведётся.
Изоляция CAM-подсистемы требует отказа от использования Giant
практически во всех драйверах SCSI; работа над этим ещё не
начиналась.</para>
<para>Кроме того, в GEOM имеется опасность снижения
производительности из-за обработки ею вышестоящих и нижестоящих
потоков данных в потоках выполнения ядра. В решении этой проблемы
может помочь улучшение и упрощение технологии переключения
контекстов выполнения.</para>
</listitem>
<listitem>
<para>Сеть: Работа по переводу на изоляцию сетевого стека была
начата заново. Изначально целями были таблицы маршрутизации, ARP,
функции моста, IPFW, Fast-Forward, TCP, UDP, IP, Fast IPSEC и
уровни интерфейсов, а также некоторые драйверы устройств Ethernet.
Позже были поставлены цели по изоляции уровней сокетов, IPv6 и
других сетевых протоколов. Основной задачей этой работы является
восстановление производительности, достигнутой во &os;
4.<replaceable>X</replaceable>. Затраты на переключение контекстов
на ithreads и netisr в драйверах устройств всё ещё сильно влияют на
производительность.</para>
</listitem>
<listitem>
<para>VFS: Начата предварительная подготовка.</para>
</listitem>
<listitem>
<para>буфер/кэш: Закончена начальная работа по изоляции
буферов.</para>
</listitem>
<listitem>
<para>Proc: Начальное изоляция proc уже есть, во &os; 5.2 ожидается
ещё больший прогресс.</para>
</listitem>
<listitem>
<para>CAM: На уровне CAM SCSI значительной работы не
проделано.</para>
</listitem>
<listitem>
<para>Newbus: была проделана некоторая работа по изоляции структуры
device_t.</para>
</listitem>
<listitem>
<para>Pipes: завершено</para>
</listitem>
<listitem>
<para>Файловые дескрипторы: завершено.</para>
</listitem>
<listitem>
<para>Process accounting: jails, credentials, MAC labels и
планировщик не используют Giant.</para>
</listitem>
<listitem>
<para>Технология MAC: завершено</para>
</listitem>
<listitem>
<para>Timekeeping: завершено</para>
</listitem>
<listitem>
<para>kernel encryption: криптографические драйверы и ядро технологии
&man.crypto.4; не используют Giant. KAME IPsec не
отделяются.</para>
</listitem>
<listitem>
<para>Аудио-подсистема: завершено, однако остаются проблемы с
обратным порядком изоляций.</para>
</listitem>
<listitem>
<para>вытесняемость ядра: включена вытесняемость для потоков
выполнения прерываний. Однако несогласованность из-за того, что
Giant используется в большинстве кода ядра и подпрограммах
обработки прерываний драйверов устройств, вызывает множество
лишних переключений контекста и может на самом деле сказаться на
производительности. Ведётся работа по выяснению того, как сделать
вытесняемость условной.</para>
</listitem>
</itemizedlist>
</sect2>
<sect2 id="interrupts">
<title>Задержки на прерывания и их обработка</title>
<para>В SMPng появилась концепция выделенных потоков выполнения ядра,
известных под названием ithreads, для обслуживания прерываний. С ними
подпрограммы обслуживания прерываний от устройств могут создавать
блокировки для выставления семафоров, выделения памяти и так далее.
Хотя это облегчает написание драйверов, при этом понижается
реактивность системы из-за того, что для обслуживания ithread должно
быть выполнено полное переключение контекста процесса. Это
усугубляется значительным использованием ядром семафора Giant, и часто
приводит к множеству пауз и переключений контекстов для обслуживания
прерывания. Драйверы, которые зарегистрировали свои прерывания как
INTR_MPSAFE, меньше всего почувствуют этот эффект, однако потери на
переключение контекста останутся. Подпрограммы обслуживания
прерываний, зарегистрированные как INTR_FAST, работают непосредственно
из контекста прерывания, и на них вовсе не сказываются эти проблемы.
Однако указание свойства INTR_FAST заставляет линию прерываний стать
эксклюзивной; её нельзя использовать одновременно с чем-то. Большое
количество совместно используемых прерываний на PC-системах делает это
нежелательным.</para>
<para>Для помощи в решении этой проблемы были предложены несколько
идей:</para>
<itemizedlist>
<listitem>
<para>Возможно, особый случай облегчённых ithread. При этом может,
придётся уменьшить количество сохраняемых данных контекста для
ithread, заимствовать стек из другого kthread и/или содавать
новый быстрый способ обхода подпрограммы mi_switch().</para>
</listitem>
<listitem>
<para>Можно ввести новую модель обработки прерываний, которая
позволит драйверам регистрировать 'фильтр прерываний' вместе с
обычной процедурой обработки. Это будет похоже на используемую
сейчас в Mac OS X модель. Процедуры фильтрации прерываний позволят
драйверу определять, должен ли он участвовать в обработке
прерывания, позволят ему подавлять источник прерываний и, возможно,
определять и планировать действия по его обработке. Она будет
работать в том же самом контексте, что и низкоуровневая процедура
обслуживания прерывания, так что паузы будут жёстко запрещены.
Если требуются действия, которые приводят к паузам или блокировке
на долгий период, фильтр будут сигнализировать об этом вызывающей
стороне, что должна быть запланирована обычная
ithread-процедура.</para>
</listitem>
</itemizedlist>
</sect2>
<sect2 id="KSE">
<title>Потоки приложений, поддерживаемые ядром</title>
<para>В процессе работы над FreeBSD 5.1 пакет KSE был доведён до весьма
пригодного к использованию состояния. Также появился THR,
альтернативный пакет по управлению потоками выполнения, основанный на
некоторых примитивах KSE уровня ядра, но реализующий исключительно
подход планирования задач 1:1, также находится в подобном
экспериментальном, но пригодном к работе состоянии. Пользователи могут
менять эти две библиотеки со старой библиотекой libc_r посредством
перекомпоновки своих приложений или при помощи новой техники libmap
компоновщика времени выполнения. Такой значительный прогресс в ходе
работ должен привести к их завершению до момента появления ветки
&t.releng.5;, так что пакет libc_r может оказаться ненужным.</para>
<itemizedlist>
<listitem>
<para>Компоненты уровня ядра и пользовательского уровня для KSE и THR
должны быть созданы для все платформ уровня Tier-1. Решение о том,
какой пакет реализации потоков выполнения будет использоваться по
умолчанию, будет, скорее всего, приниматься для каждой платформы
отдельно, в зависимости от стабильности и завершённости каждого
пакета.</para>
<para>
<table id=KSETable>
<title>Состояние KSE</title>
<tgroup cols="4">
<thead>
<row>
<entry>Платформа</entry>
<entry>Уровень ядро</entry>
<entry>Пользовательский уровень</entry>
<entry>Работает?</entry>
</row>
</thead>
<tbody>
<row>
<entry>i386</entry>
<entry>ДА</entry>
<entry>ДА</entry>
<entry>ДА</entry>
</row>
<row>
<entry>alpha</entry>
<entry>НЕТ</entry>
<entry>ДА</entry>
<entry>НЕТ</entry>
</row>
<row>
<entry>sparc64</entry>
<entry>ДА</entry>
<entry>НЕТ</entry>
<entry>НЕТ</entry>
</row>
<row>
<entry>ia64</entry>
<entry>ДА</entry>
<entry>ДА</entry>
<entry>ДА</entry>
</row>
<row>
<entry>amd64</entry>
<entry>ДА</entry>
<entry>ДА</entry>
<entry>ДА</entry>
</row>
</tbody>
</tgroup>
</table>
<table id=THRTable>
<title>Состояние THR</title>
<tgroup cols="4">
<thead>
<row>
<entry>Платформа</entry>
<entry>Уровень ядра</entry>
<entry>Пользовательский уровень</entry>
<entry>Работает?</entry>
</row>
</thead>
<tbody>
<row>
<entry>i386</entry>
<entry>ДА</entry>
<entry>ДА</entry>
<entry>ДА</entry>
</row>
<row>
<entry>alpha</entry>
<entry>ДА</entry>
<entry>ДА</entry>
<entry>ДА</entry>
</row>
<row>
<entry>sparc64</entry>
<entry>ДА</entry>
<entry>ДА</entry>
<entry>НЕТ</entry>
</row>
<row>
<entry>ia64</entry>
<entry>ДА</entry>
<entry>ДА</entry>
<entry>ДА</entry>
</row>
<row>
<entry>amd64</entry>
<entry>НЕТ</entry>
<entry>НЕТ</entry>
<entry>НЕТ</entry>
</row>
</tbody>
</tgroup>
</table>
</para>
</listitem>
<listitem>
<para>KSE должен пройти набор тестов ACE на всех платформах статуса
Tier-1. Чтобы убедиться в том, что все библиотеки на самом деле
работоспособны, необходимо выполнить дополнительное тестирование
на реальных задачах. Как минимум, должны быть протестированы
следующие пакеты:</para>
<itemizedlist>
<listitem><para>OpenOffice</para></listitem>
<listitem><para>KDE Desktop</para></listitem>
<listitem><para>Apache 2.x</para></listitem>
<listitem><para>BIND 9.2.x</para></listitem>
<listitem><para>MySQL</para></listitem>
<listitem><para>&java; 1.4.x</para></listitem>
</itemizedlist>
</listitem>
</itemizedlist>
</sect2>
</sect1>
<sect1 id="goals">
<title>Требования к 5-STABLE</title>
<para>Ветка &t.releng.5 должна дать пользователям такую же стабильность и
проивзодительность, которая сейчас достигнута в ветке &t.releng.4;. Хотя
целью работ над SMPng является значительное повышение производительности
по сравнению с имеющейся в &t.releng.4; и родственных вариантах BSD,
получение хотя бы ранее достигнутой производительности является самой
важной задачей. Ветка должна быть достаточно готовой, чтобы избежать
изменений в ABI и API, но позволять решать потенциальные проблемы.</para>
<sect2 id="API">
<title>Стабильность ABI/API/инфраструктуры</title>
<para>Инфраструктура должна быть достаточно подготовленной и устоявшейся,
чтобы исправления из ветки &t.releng.head; можно было легко и
безболезненно переносить в &t.releng.5;. Кроме того, мы должны
определиться, какие подсистемы должны работать с блокировками при
переходе к 5-STABLE.</para>
<itemizedlist>
<listitem>
<para>KSE: И компоненты уровня ядра, и компоненты пользовательского
уровня должны достичь одинакового уровня функциональности во всех
платформах уровня Tier-1 в UP и SMP конфигурациях. Опеределение
того, что является <quote>платформами ранга Tier-1</quote>, можно
найти в <ulink
url="http://www.FreeBSD.org/doc/en_US.ISO8859-1/articles/committers-guide/archs.html">
</ulink>. При приближении к выпуску ветки &t.releng.5; должно
продолжиться тестирование на пакете тестов ACE. В KSE не должно
допускаться уменьшение функциональности для будущей программы
сертификации &java;. Распространённые прикладные и серверные
приложения должны работать в KSE без проблем. Должна быть
определена политика относительно того, на каких платформах KSE
будет использоваться в качестве стандартного пакета для организации
потоков выполнения, как пользователь может переключаться между
такими пакетами и как пакеты сторонних разработчиков должны
отслеживать такие изменения.</para>
</listitem>
<listitem>
<para>интерфейс и драйверы busdma: такие архитектуры, как PAE/&i386;
и sparc64, в которых отсутствует прямое отображение адресного
пространства хоста в адресное пространство плат расширения, требуют
исключения функции vtophys() и ей подобных. Интерфейс busdma был
создал для решения именно этой проблемы, однако многие драйверы
его ещё не используют. Проект busdma на странице <ulink
url="http://www.FreeBSD.org/projects/busdma"></ulink> отслеживает
ход этих работ и это моэно использовать для определения того, какие
драйверы должны быть преобразованы для &t.releng.5;, а какие можно
оставить. В дереве исходных текстов &os; не должно быть новых
драйверов для устройств хранения или сетевых драйверов. Исключения
для других классов драйверов нужно согласовывать в открытом
обсуждении.</para>
</listitem>
<listitem>
<para>распределение ресурсов PCI: соответствие спецификации PC2003
требует, что системы x86 не конфигурировали устройства PCI из
системной BIOS, оставляя эту задачу исключительно ОС. Во &os;
должна появиться возможность управления и распределения ресурсов
памяти PCI своими силами. Реализация этого должна принять во
внимание существование требований cardbus, PCI-HotPlug и доков для
лэптопов. Эта возможность станет ещё более критичной в течение
жизни ветки &t.releng.5;, и поэтому является требованием к выпуску
&t.releng.5;.</para>
</listitem>
</itemizedlist>
</sect2>
<sect2 id="performance">
<title>Производительность</title>
<para>Производительность зависит от хода работ над инфраструктурой SMPng
и в следующих областях:</para>
<itemizedlist>
<listitem>
<para>Устройства хранения: Технология GEOM позволяет драйверам
устройств хранения работать без использования Giant. Все драйверы,
которые взаимодействуют напрямую с GEOM (в противоположность тем,
что находятся ниже уровня CAM или другого промежуточного слоя),
должны изолироваться и избавляться от использования Giant как в
части strategy, так и completion. Их обработчики прерываний также
должны избавиться от Giant.</para>
</listitem>
<listitem>
<para>Сеть: уровни в работе IPv4, лежащие ниже уровня сокетов, должны
быть изолированными и не использовать Giant. Сюда включается
протокол, маршрутизация, организация моста, фильтрация и аппаратный
уровень. Скидки должны быть сделаны для протоколов, которые не
изолируются, особенно IPv6. Для достижения стабильности,
корректности и производительности также необходимо выполнить
тестирование.</para>
</listitem>
<listitem>
<para>Прерывания и переключение контекстов: Как обсуждалось выше,
задержки в прерываниях и переключениях контекстов имеют большое
влияние на производительность. Переключение контектов для ithread
и kthread на всех платформах должно быть улучшено. Должна быть
исследована и реализована возможность создания новой модели
обработки прерываний, которая позволяет выполнять более быструю и
гибкую обработку как обычных, так и MSI прерываний.</para>
</listitem>
</itemizedlist>
</sect2>
<sect2 id="benchmarks">
<title>Стандартные тесты и тестирование производительности</title>
<para>Для выявления проблем с производительностью и борьбы с её
ухудшением необходимо информативное и надёжное проведение тестов.
Вскоре должна быть сформирована <quote>группа
производительности</quote> из людей и ресурсов для формулирования,
разработки и выполнения стандартных тестов проиводительности.
Сравнения должны делаться как с &os; 4.<replaceable>X</replaceable>,
так и Linux 2.4/2.6. Предполагаются следующие тесты:</para>
<itemizedlist>
<listitem>
<para>классический <quote>worldstone</quote></para>
</listitem>
<listitem>
<para>webstone: <filename
role="package">www/webstone</filename></para>
</listitem>
<listitem>
<para>Fstress: <ulink
url="http://www.cs.duke.edu/ari/fstress/"></ulink></para>
</listitem>
<listitem>
<para>ApacheBench: <filename
role="package">www/p5-ApacheBench</filename></para>
</listitem>
<listitem>
<para>netperf: <filename
role="package">benchmarks/netperf</filename></para>
</listitem>
<listitem>
<para>Web Polygraph: <ulink
url="http://www.web-polygraph.org/"></ulink> Замечание: пока не
компилируется с gcc 3.x.</para>
</listitem>
</itemizedlist>
</sect2>
<sect2 id="features">
<title>Особые возможности:</title>
<itemizedlist>
<listitem>
<para>NEWCARD/OLDCARD: Подсистема NEWCARD во &os; 5.0 сделана
используемой по умолчанию. К сожалению, в ней отсутствует
поддержка для не-Cardbus мостов и на некоторых лэптопах она
не работает из-за проблем с маршрутизацией прерываний.
Классическая реализации поддержки 16-битных мостов, OLDCARD,
продолжает существовать и может быть вкомпилирована, однако это
неудобно для пользователей старых лэптопов. Если от OLDCARD
для &t.releng.5; нельзя будет полностью отказаться, то должны быть
сделаны шаги, которые позволят пользователям легко устанавливать
ядро с поддержкой OLDCARD. Должна быть написана документация в
помощь пользователям по переходу от OLDCARD к NEWCARD и от
&man.pccardd.8; к &man.devd.8;. Функциональность по управлению
электропитанием и <quote>dumpcis</quote> утилиты &man.pccardc.8;
должна быть усилена поддержкой NEWCARD, а также возможностью
подгружать информацию о нестандартном оборудовании CIS. Основной
объём этих функций может быть интегрирован в &man.devd.8; и
&man.devctl.4;.</para>
</listitem>
<listitem>
<para>Новый планировщик задач: Он уже готов, и пользователи могут
выбирать между классическим планировщиком 44BSD и новым
планировщиком ULE. В ветке &t.releng.5; должен быть планировщик,
имеющий привязку к процессору, поддержку HyperThreading и KSE,
а также отсутствие снижения производительности или времени реакции
системы.</para>
</listitem>
<listitem>
<para>GDB: GDB в основном системном наборе должен работать со
sparc64, а также понимать потоки KSE. Уже имеется GDB 5.3,
сообщается, что он решает проблемы со sparc64.</para>
</listitem>
</itemizedlist>
</sect2>
<sect2 id="documentation">
<title>Документация:</title>
<itemizedlist>
<listitem>
<para>Справочные страницы, Руководство и FAQ должны быть очищены от
содержимого, специфичного для &os; 4.<replaceable>X</replaceable>,
то есть весь текст должен подходить и для &os;
5.<replaceable>X</replaceable>. Больше всего работы здесь
предстоит сделать в разделе Руководства по установке.</para>
</listitem>
<listitem>
<para>Документация к релизу должна быть полной и точной для всех
архитектур уровня Tier-1. Особого внимания требуют замечания по
оборудованию и инструкции по установке.</para>
</listitem>
</itemizedlist>
</sect2>
</sect1>
<sect1 id="schedule">
<title>Календарный план</title>
<para>Из-за сложности стоящих задач первоначальный план выпуска &os; 5.2 и
создания ветки &t.releng.5; в сентябре 2003 года был сдвинут. Новый
календарный план выглядит так:</para>
<itemizedlist>
<listitem>
<para>18 ноября 2003: 5.2-BETA, общая заморозка кода</para>
</listitem>
<listitem>
<para>6 декабря 2003: 5.2-RC1, создание ветки &t.releng.5.2;</para>
</listitem>
<listitem>
<para>9 декабря 2003: 5.2-RC2</para>
</listitem>
<listitem>
<para>16 декабря 2003: 5.2-RELEASE</para>
</listitem>
<listitem>
<para>1 марта 2004: 5.3-BETA, общая заморозка кода</para>
</listitem>
<listitem>
<para>15 марта 2004: 5.3-RC1, создание веток &t.releng.5; и
&t.releng.5.3;</para>
</listitem>
<listitem>
<para>22 марта 2004: 5.3-RC2</para>
</listitem>
<listitem>
<para>29 марта 2004: 5.3-RELEASE</para>
</listitem>
</itemizedlist>
</sect1>
<sect1 id="future">
<title>Направление работ после &t.releng.5;</title>
<para>Как это происходит и с другими ветками -STABLE, в основном работа
над ней должна заключаться в исправлении ошибок и последовательном
улучшении. Как обычно, всё должно проходить проверку в ветке
&t.releng.head;, а затем внимательно переноситься в &t.releng.5;. Как и
раньше, новые драйверы устройств, дополнительные возможности и тому
подобные разработки приветствуются в этой ветке только после проверки в
&t.releng.head;.</para>
<para>Дальнейшая изоляция SMPng будет разделена на две категории, драйвер и
подсистема. Единственной подсистемой, которая будет достаточно
изолированной к выходу &t.releng.5;, будет GEOM, так что постепенное
изолирование драйверов устройств под её управлением является достойной
задачей этой ветки. Полная изоляция подсистемы будет выполнена и
опробована в ветке &t.releng.head; до того, как будет принято решение
о переносе её в ветку &t.releng.5;.</para>
</sect1>
</article>