1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
|
<!--
The FreeBSD Russian Documentation Project
$FreeBSDru: frdp/www/ru/releng/charter.sgml,v 1.3 2004/09/21 07:31:11 den Exp $
Original revision: 1.1
-->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" [
<!ENTITY base CDATA "..">
<!ENTITY date "$FreeBSD: www/ru/releng/charter.sgml,v 1.3 2004/09/21 07:50:18 den Exp $">
<!ENTITY title "Обязанности Группы подготовки релизов">
<!ENTITY % navincludes SYSTEM "../includes.navdevelopers.sgml"> %navincludes;
<!ENTITY % includes SYSTEM "../includes.sgml"> %includes;
]>
<html>
&header;
<p>Группа подготовки релизов отвечает за следующие вопросы:</p>
<ul>
<li><p>Определение и публикация плана выпуска релизов для официальных
релизов Проекта FreeBSD.</p></li>
<li><p>Документирование и формализация процесса подготовки релизов, так
чтобы его можно было пересматривать и улучшать. В эту работу включается
подготовка документации о кластере портов и процедурах разделения
пакаджей.</p></li>
<li><p>Установка и публикация дат "заморозки кода", и выполнение роли
комитета по просмотру изменений для решения вопроса о том, какие
изменения можно вносить в ветку во момент заморозки кода. К этим
вопросам относится заморозка ветки HEAD при подготовке релиза .0, а также
традиционные заморозки кода <tt>RELENG_*</tt> при выпуске релизов
-STABLE.</p></li>
<li><p>Создание и обслуживание веток <tt>RELENG_*</tt> дерева
<tt>src/</tt>. Сюда относится принятие конечного решения о том, какие
изменения делаются (и остаются) в ветке -STABLE до создания ветки,
соответствующей релизу.</p></li>
<li><p>Работа с руководством проекта и/или Фондом FreeBSD для определения
набора правил, которым должны следовать поставщики, если они хотят, чтобы
их продукт назывался "FreeBSD" или "Официальным релизом
FreeBSD".</p></li>
<li><p>Тестирование и интеграция необходимых пакаджей из коллекции портов
на носители с официальными релизами. Portmgr@ отвечает за управление
заморозкой кода в <tt>ports/</tt> и полноту построения пакаджей портов,
которые можно распространять. re@ отвечает за размещение этих пакаджей
на различных ISO, требуемых для носителей релизов. re@ безусловно
отвечает за то, что все требуемые пакаджи размещаются на носителях с
релизом FreeBSD, но без участия portmgr@ здесь не обойтись.</p></li>
<li><p>Координация с Проектом создания документации FreeBSD для обеспечения
наличия полного набора документации к релизу. В круг вопросов входит
запрет на внесение больших изменений в наборе документации в недели,
предшествующие релизу.</p></li>
<li><p>Координация с командой начальника отдела информационной безопасности
для обеспечения того, что релизы FreeBSD не будут подвержены недавно
выявленным уязвимостям. Кроме того, примерно примерно через 1 неделю
после релиза право на утверждение внесения изменений в ветках релизов
(<tt>RELENG_X_Y</tt>) передаётся от релиз-инженеров службе безопасности.
Конкретная дата передачи согласуется обоими сторонами, как только
становится ясно, что релиз состоялся. В этот момент в адрес developers@
должно посылаться предупреждающее письмо.</p></li>
<li><p>Посылка сообщений в адрес announce@FreeBSD.org от имени проекта
для анонсирования новых релизов FreeBSD.</p></li>
</ul>
&footer;
</body>
</html>
|
