Справочник коммиттера
Пред. |  |

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

14.1. Почему не следует вносить малозначимые изменения в ветви разработчика (vendor branches)?
14.2. Как мне добавить файл в ветвь CVS?
14.3. Какую ''мета-информацию'' я должен включать в сообщения для коммита?
14.4. Как мне получить доступ к `people.FreeBSD.org` для того чтобы разместить там персональную информацию или информацию о моих проектах?
14.5. Где расположены архивы списков рассылки?
14.6. Мне бы хотелось стать ментором для нового коммиттера. Какого технологического процесса я должен придерживаться?

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

- После этого действия каждый новый релиз от разработчика требует ручного приложения и объединения патчей.

- Что хуже, каждый новый релиз от разработчика требует ручной проверки приложенных патчей.

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

14.2. Как мне добавить файл в ветвь CVS?

Для добавления файла в ветви просто обновите исходные файлы до нужной ветви, а затем используйте команду `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

14.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

14.4. Как мне получить доступ к `people.FreeBSD.org` для того чтобы разместить там персональную информацию или информацию о моих проектах?

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

14.5. Где расположены архивы списков рассылки?

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

14.6. Мне бы хотелось стать ментором для нового коммиттера. Какого технологического процесса я должен придерживаться?

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

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

Этот, и другие документы, могут быть скачаны с ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/.

По вопросам, связанным с FreeBSD, прочитайте документацию прежде чем писать в <questions@FreeBSD.org>.
По вопросам, связанным с этой документацией, пишите <doc@FreeBSD.org>.
По вопросам, связанным с русским переводом документации, пишите в рассылку <frdp@FreeBSD.org.ua>.
Информация по подписке на эту рассылку находится на сайте проекта перевода.