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

## 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. | Мне бы хотелось стать ментором для нового коммиттера. Какого технологического процесса я должен придерживаться?
| Обратитесь к документу Процедура создания нового аккаунта.

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

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

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