Question

14.1.

Почему не следует вносить малозначимые изменения в ветви разработчика (vendor branches)?

Answer 1

После этого действия каждый новый релиз от разработчика требует ручного приложения и объединения патчей.
Что хуже, каждый новый релиз от разработчика требует ручной проверки приложенных патчей.
Опция CVS -j не всегда хорошо работает. Можете спросить David O'Brien <obrien@FreeBSD.org>, он расскажет вам жутких историй.

Answer 2

Для добавления файла в ветви просто обновите исходные файлы до нужной ветви, а затем используйте команду cvs add. Например, если мы хотите перенести файл src/sys/alpha/include/smp.h из ветви HEAD в ветвь RELENG_6, в которой он пока не существует, можно использовать следующую последовательность действий:

Пример 1. MFC для нового файла

% cd sys/alpha/include
% cvs update -rRELENG_6
cvs update: Updating .
U clockvar.h
U console.h
...
% 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
***************
% cvs add smp.h
cvs add: scheduling file `smp.h' for addition on branch `RELENG_6'
cvs add: use 'cvs commit' to add this file permanently
% cvs commit

Answer 3

Помимо информативного описания содержания коммита вам может потребоваться включить в сообщение дополнительную информацию.

Она состоит из одной или нескольких строк вида: ключевое слово или словосочетание, двоеточие, табуляции для форматирования, собственно дополнительная информация.

Ключевыми словами могут быть:

`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:`	Если ваши изменения затрагивают вопросы безопасности или исправляют какие-либо уязвимости, укажите ссылки на опубликованные отчеты или описание проблемы.

Пример 2. Сообщение для коммита, основанного на PR

Вы собираетесь внести коммит, основанный на PR, присланном John Smith и содержащим патч для исправления проблемы. Ваше сообщение должно заканчиваться примерно такими строками:

...

PR:                foo/12345
Submitted by:	   John Smith <John.Smith@example.com>

Пример 3. Сообщение для коммита, требующего рецензии

Вы собираетесь изменить подсистему работы с виртуальной памятью. Вы опубликовали предполагаемые изменения в соответствующем списке рассылки (в данном случае freebsd-arch), и изменения были одобрены.

...

Reviewed by:       -arch

Пример 4. Сообщение для коммита, требующего одобрения

Вы намерены произвести коммит в область дерева, для которой определен ведущий (MAINTAINER). Вы скоординировали усилия с мейнтейнером, и он отреагировал <<Отлично. Производи коммит.>>

...

Approved by:	    abc

Где abc имя пользователя, одобрившего ваш коммит.

Пример 5. Сообщение для коммита, использующего код OpenBSD

Вы собираетесь внести изменение, основанное на коде, использованном проектом OpenBSD.

...

Obtained from:      OpenBSD

Пример 6. Сообщение для коммита, планирующего интеграцию из FreeBSD-CURRENT в FreeBSD-STABLE через некоторое время

Вы хотите внести изменения, которые должны быть интегрированы из FreeBSD-CURRENT в ветвь FreeBSD-STABLE через две недели.

...

MFC after:      2 weeks

Где 2 является количеством дней, недель или месяцев, через которое вы планируете интегрировать (MFC) в FreeBSD-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

Answer 4

people.FreeBSD.org - синоним для freefall.FreeBSD.org. Просто создайте каталог public_html. Все, что вы разместите в нем, будет автоматически доступно по адресу http://people.FreeBSD.org/.

Answer 5

Списки рассылки архивируются в иерархию каталогов /g/mail, видимую на всех машинах кластера как /hub/g/mail (см. pwd(1)).

Answer 6

Обратитесь к документу Процедура создания нового аккаунта.

Пред.
13. Пряники и прочие льготы	Начало

14. Прочие вопросы