diff options
Diffstat (limited to 'documentation/content/ru/articles/committers-guide/_index.adoc')
| -rw-r--r-- | documentation/content/ru/articles/committers-guide/_index.adoc | 116 |
1 files changed, 72 insertions, 44 deletions
diff --git a/documentation/content/ru/articles/committers-guide/_index.adoc b/documentation/content/ru/articles/committers-guide/_index.adoc index fdc0635660..6c7a971f9d 100644 --- a/documentation/content/ru/articles/committers-guide/_index.adoc +++ b/documentation/content/ru/articles/committers-guide/_index.adoc @@ -4,7 +4,7 @@ authors: author: 'The FreeBSD Documentation Project' copyright: '1999-2022 The FreeBSD Documentation Project' description: 'Вводная информация для коммиттеров FreeBSD' -tags: "[\"FreeBSD Committer's Guide\", \"Guide\", \"Community\"]" +tags: ["FreeBSD Committer's Guide", "Guide", "Community"] title: 'Руководство коммиттера' trademarks: ["freebsd", "coverity", "git", "github", "gitlab", "ibm", "intel", "general"] weight: 25 @@ -1293,9 +1293,13 @@ freefall% gen-gitconfig.sh ===== Как отслеживать -current и -stable, имея только одну копию репозитория? -**Q:** Although disk space is not a huge issue, it's more efficient to use only one copy of the repository. With SVN mirroring, I could checkout multiple trees from the same repository. How do I do this with Git? +**В:** Хотя место на диске не является большой проблемой, эффективнее использовать только одну копию репозитория. +При зеркалировании SVN я мог извлекать несколько деревьев из одного и того же репозитория. +Как мне сделать это с помощью Git? -**A:** You can use Git worktrees. There's a number of ways to do this, but the simplest way is to use a clone to track -current, and a worktree to track stable releases. While using a 'bare repository' has been put forward as a way to cope, it's more complicated and will not be documented here. +**О:** Вы можете использовать рабочие деревья Git. +Существует несколько способов сделать это, но самый простой — использовать клон для отслеживания -current и рабочее дерево для отслеживания стабильных выпусков. +Хотя использование «голого (bare) репозитория» предлагалось как способ справиться с этим, это более сложно и здесь документироваться не будет. Сначала необходимо клонировать репозиторий FreeBSD, здесь показано клонирование в `freebsd-current` для избежания путаницы. `$URL` — это любой зеркальный сервер, который работает для вас наилучшим образом: @@ -1333,9 +1337,9 @@ freefall% gen-gitconfig.sh ===== Ой! Я закоммитил в `main` вместо другой ветки. -**Q:** From time to time, I goof up and mistakenly commit to the `main` branch. What do I do? +**В:** Время от времени я ошибаюсь и по ошибке делаю коммит в ветку `main`. Что мне делать? -**A:** First, don't panic. +**О:** Во-первых, не паникуйте. Во-вторых, не отправляйте (push) изменения. На самом деле, можно исправить почти всё, если изменения не были отправлены. Все ответы в этом разделе предполагают, что отправки не произошло. @@ -1350,9 +1354,12 @@ freefall% gen-gitconfig.sh ===== Ой! Я закоммитил что-то не в ту ветку! -**Q:** I was working on feature on the `wilma` branch, but accidentally committed a change relevant to the `fred` branch in 'wilma'. What do I do? +**В:** Я работал над функцией в ветке `wilma`, но случайно сделал коммит изменению, относящемуся к ветке `fred`, в 'wilma'. +Что мне делать? -**A:** The answer is similar to the previous one, but with cherry picking. This assumes there's only one commit on wilma, but will generalize to more complicated situations. It also assumes that it's the last commit on wilma (hence using wilma in the `git cherry-pick` command), but that too can be generalized. +**О:** Ответ аналогичен предыдущему, но с использованием выборочного применением коммитов (cherry-pick). +Предполагается, что в ветке wilma имеется всего один коммит, однако подход можно обобщить и для более сложных ситуаций. +Также предполагается, что это последний коммит в ветке wilma (отсюда использование wilma в команде `git cherry-pick`), но и это можно обобщить. [source, shell] .... @@ -1373,13 +1380,21 @@ freefall% gen-gitconfig.sh % git rebase -i main wilma # удалить скопированное изменение .... -**Q:** But what if I want to commit a few changes to `main`, but keep the rest in `wilma` for some reason? +**В:** Но что, если я хочу сделать коммит нескольким изменениям в `main`, но оставить остальные в `wilma` по какой-то причине? -**A:** The same technique above also works if you are wanting to 'land' parts of the branch you are working on into `main` before the rest of the branch is ready (say you noticed an unrelated typo, or fixed an incidental bug). You can cherry pick those changes into `main`, then push to the parent repository. Once you've done that, cleanup couldn't be simpler: just `git rebase -i`. Git will notice you've done this and skip the common changes automatically (even if you had to change the commit message or tweak the commit slightly). There's no need to switch back to wilma to adjust it: just rebase! +**О:** Тот же метод, описанный выше, также работает, если вы хотите «приземлить» части ветки, над которой работаете, в `main` до того, как вся ветка будет готова (скажем, вы заметили несвязанную опечатку или исправили случайную ошибку). +Вы можете выборочно применить (cherry-pick) эти изменения в `main`, а затем отправить их в родительский репозиторий. +После того, как вы это сделаете, очистка не может быть проще: просто выполните `git rebase -i`. +Git заметит, что вы это сделали, и автоматически пропустит общие изменения (даже если вам пришлось изменить сообщение коммита или слегка подкорректировать коммит). +Нет необходимости переключаться обратно на wilma, чтобы её поправить: просто делайте rebase! -**Q:** I want to split off some changes from branch `wilma` into branch `fred` +**В:** Я хочу выделить некоторые изменения из ветки `wilma` в ветку `fred` -**A:** The more general answer would be the same as the previous. You'd checkout/create the `fred` branch, cherry pick the changes you want from `wilma` one at a time, then rebase `wilma` to remove those changes you cherry picked. `git rebase -i main wilma` will toss you into an editor, and remove the `pick` lines that correspond to the commits you copied to `fred`. If all goes well, and there are no conflicts, you're done. If not, you'll need to resolve the conflicts as you go. +**О:** Более общий ответ будет таким же, как и предыдущий. +Вы должны выгрузить(checkout)/создать ветку `fred`, выборочно применить (cherry-pick) нужные изменения из ветки `wilma` по одному, а затем перебазировать (rebase) `wilma`, чтобы удалить те изменения, которые вы выборочно применили. +`git rebase -i main wilma` перенесёт вас в редактор, где нужно удалить строки `pick`, соответствующие коммитам, которые вы скопировали в `fred`. +Если всё пройдёт хорошо и не будет конфликтов, вы закончили. +Если нет, вам нужно будет разрешать конфликты по мере их появления. Другой способ сделать это — выгрузить `wilma`, а затем создать ветку `fred`, указывающую на ту же точку в дереве. Затем вы можете выполнить `git rebase -i` для обеих этих веток, выбирая изменения, которые вы хотите видеть в `fred` или `wilma`, оставляя строки с `pick` и удаляя остальные в редакторе. Некоторые предпочитают создать тег/ветку с названием `pre-split` перед началом, на случай если что-то пойдет не так при разделении. Вы можете отменить это следующей последовательностью: @@ -1393,9 +1408,11 @@ freefall% gen-gitconfig.sh Последний шаг необязателен. Если вы собираетесь повторить попытку разделения, его можно пропустить. -**Q:** But I did things as I read along and didn't see your advice at the end to create a branch, and now `fred` and `wilma` are all screwed up. How do I find what `wilma` was before I started. I don't know how many times I moved things around. +**В:** Но я делал всё по мере прочтения и не увидел ваш совет в конце создать ветку, и теперь `fred` и `wilma` полностью испорчены. +Как мне найти, чем `wilma` была до того, как я начал. +Я не знаю, сколько раз я всё переставлял. -**A:** All is not lost. You can figure out it, so long as it hasn't been too long, or too many commits (hundreds). +**О:** Не всё потеряно. Вы можете разобраться с этим, если прошло не слишком много времени или не было сделано слишком много коммитов (сотни). Итак, я создал ветку wilma и закоммитил в неё пару изменений, затем решил разделить её на fred и wilma. Ничего странного при этом не произошло, но предположим, что произошло. Способ посмотреть, что вы сделали, — это использовать `git reflog`: @@ -1417,7 +1434,7 @@ a6a5094 (fred) HEAD@{4}: rebase -i (pick): Encourage contributions Здесь мы видим изменения, которые я внес. Вы можете использовать это, чтобы понять, где что-то пошло не так. Я лишь укажу на несколько моментов. Первый из них — HEAD@{X} является 'коммитоподобной' сущностью, поэтому вы можете использовать это в качестве аргумента команды. Хотя если эта команда вносит что-либо в репозиторий, номера X изменяются. Вы также можете использовать хэш (первый столбец). -Далее, 'Encourage contributions' был последним коммитом, который я сделал в `wilma` перед тем, как решил разделить всё. Вы также можете видеть, что тот же хэш присутствует, когда я создал ветку `fred` для этого. Я начал с перебазирования `fred`, и вы видите 'начало', каждый шаг и 'завершение' этого процесса. Хотя нам это здесь не нужно, вы можете точно понять, что произошло. К счастью, чтобы исправить это, вы можете выполнить шаги из предыдущего ответа, но с хэшом `869cbd3` вместо `pre-split`. Хотя это кажется немного многословным, это легко запомнить, поскольку вы делаете одно действие за раз. Вы также можете последовательно применить команды одну за другой: +Далее, 'Encourage contributions' был последним коммитом, который я сделал в `wilma` перед тем, как решил разделить всё. Вы также можете видеть, что тот же хэш присутствует, когда я создал ветку `fred` для этого. Я начал с перебазирования `fred`, и вы видите 'начало', каждый шаг и 'завершение' этого процесса. Хотя нам это здесь не нужно, вы можете точно понять, что произошло. К счастью, чтобы исправить это, вы можете выполнить шаги из предыдущего ответа, но с хэшем `869cbd3` вместо `pre-split`. Хотя это кажется немного многословным, это легко запомнить, поскольку вы делаете одно действие за раз. Вы также можете последовательно применить команды одну за другой: [source, shell] .... @@ -1450,9 +1467,10 @@ HEAD is now at 869cbd3 Encourage contributions ===== Ой! Я выполнил `git pull`, и это создало коммит слияния, что мне делать? -**Q:** I was on autopilot and did a `git pull` for my development tree and that created a merge commit on `main`. How do I recover? +**В:** Я действовал на автопилоте и сделал `git pull` для своего дерева разработки, что создало коммит слияния в `main`. +Как мне восстановиться? -**A:** This can happen when you invoke the pull with your development branch checked out. +**О:** Это может произойти, когда вы выполняете извлечение (checkout) с выбранной веткой разработки. Многие разработчики используют `git pull --rebase`, чтобы избежать этой ситуации. @@ -1473,9 +1491,10 @@ git reset --hard HEAD^1 Кроме того, команда `git pull --rebase` на этом этапе перебазирует ваши изменения из ветки 'main' на последнюю версию 'freebsd/main'. -**Q:** But I also need to fix my `main` branch. How do I do that? +**В:** Но мне также нужно исправить мою ветку `main`. Как мне это сделать? -**A:** Git keeps track of the remote repository branches in a `freebsd/` namespace. To fix your `main` branch, just make it point to the remote's `main`: +**О:** Git отслеживает ветки удалённого репозитория в пространстве имён `freebsd/`. +Чтобы исправить вашу ветку `main`, просто заставьте её указывать на удалённую ветку `main`: [source, shell] .... @@ -1486,9 +1505,10 @@ git branch -f main freebsd/main ===== Смешивание и сопоставление веток -**Q:** So I have two branches `worker` and `async` that I'd like to combine into one branch called `feature` while maintaining the commits in both. +**В:** Итак, у меня есть две ветки `worker` и `async`, которые я хочу объединить в одну ветку под названием `feature` +с сохранением коммитов в обеих. -**A:** This is a job for cherry pick. +**О:** Это задача для выборочного применения (cherry-pick). [source, shell] .... @@ -1499,9 +1519,10 @@ git branch -f main freebsd/main Теперь у вас есть новая ветка под названием `feature`. Эта ветка объединяет коммиты из обеих веток. Вы можете далее работать с ней с помощью `git rebase`. -**Q:** I have a branch called `driver` and I'd like to break it up into `kernel` and `userland` so I can evolve them separately and commit each branch as it becomes ready. +**В:** У меня есть ветка под названием `driver`, и я хочу разделить её на `kernel` и `userland`, чтобы развивать их отдельно и коммитить каждую ветку по мере её готовности. -**A:** This takes a little bit of prep work, but `git rebase` will do the heavy lifting here. +**О:** Это требует небольшой подготовительной работы, но `git rebase` +выполнит здесь основную часть работы. [source, shell] .... @@ -1526,9 +1547,11 @@ git branch -f main freebsd/main и сделайте то же самое, что вы сделали с веткой `kernel `. -**Q:** Oh great! I followed the above and forgot a commit in the `kernel` branch. How do I recover? +**В:** Отлично! Я выполнил указанные выше шаги и забыл сделать коммит в ветке `kernel`. +Как мне восстановиться? -**A:** You can use the `driver` branch to find the hash of the commit is missing and cherry pick it. +**О:** Вы можете использовать ветку `driver`, чтобы найти хэш коммита, который отсутствует, и +выборочно применить его (cherry-pick). [source, shell] .... @@ -1537,9 +1560,13 @@ git branch -f main freebsd/main % git cherry-pick $HASH .... -**Q:** OK. I have the same situation as the above, but my commits are all mixed up. I need parts of one commit to go to one branch and the rest to go to the other. In fact, I have several. Your rebase method to select sounds tricky. +**В:** Хорошо. У меня такая же ситуация, как и выше, но мои коммиты все перемешаны. +Мне нужно, чтобы части одного коммита попали в одну ветку, а остальные — в другую. +На самом деле, у меня их несколько. +Ваш метод перебазирования с выбором кажется сложным. -**A:** In this situation, you'd be better off to curate the original branch to separate out the commits, and then use the above method to split the branch. +**О:** В этой ситуации вам лучше обработать исходную ветку, чтобы отделить +коммиты, а затем использовать вышеуказанный метод для разделения ветки. Итак, предположим, что есть всего один коммит с чистым деревом. Вы можете использовать либо `git rebase` со строкой `edit`, либо это с коммитом на острие. В любом случае шаги одинаковы. Первое, что нам нужно сделать, — это откатиться на один коммит назад, оставив изменения незакоммиченными в дереве: @@ -1563,15 +1590,17 @@ git add -i foo/bar.c ===== Присоединение к организации FreeBSD на GitHub. -**Q:** How do I join the FreeBSD GitHub organization? +**В:** Как присоединиться к организации FreeBSD на GitHub? -**A:** Please see https://wiki.freebsd.org/GitHub#Joining_the_Organisation[our GitHub Wiki Info] page for details. Briefly, all FreeBSD committers may join. Those who are not committers who request joining will be considered on a case by case basis. +**О:** Подробности смотрите на странице https://wiki.freebsd.org/GitHub#Joining_the_Organisation[нашей вики GitHub]. +Вкратце, присоединиться могут все коммиттеры FreeBSD. +Лица, не являющиеся коммиттерами, которые запрашивают присоединение, будут рассматриваться в индивидуальном порядке. ==== Клонирование и зеркалирование -**Q:** I'd like to mirror the entire Git repository, how do I do that? +**В:** Я хочу создать полную зеркальную копию репозитория Git, как мне это сделать? -**A:** If all you want to do is mirror, then +**О:** Если вам нужно только зеркалирование, то [source, shell] .... @@ -1595,9 +1624,10 @@ git add -i foo/bar.c Второй недостаток заключается в том, что Git обычно перезаписывает ссылки из вышестоящего репозитория (названия веток, теги и т.д.) , чтобы ваши локальные ссылки могли изменяться независимо от вышестоящего репозитория. Это означает, что вы потеряете изменения, если будете коммитить в свой репозиторий куда-либо, кроме веток приватных проектов. -**Q:** So what can I do instead? +**В:** Так что же я могу сделать вместо этого? -**A:** Well, you can stuff all of the upstream repository's refs into a private namespace in your local repository. Git clones everything via a 'refspec' and the default refspec is: +**О:** Ну, вы можете поместить все ссылки (refs) вышестоящего репозитория в приватное пространство имён вашего локального репозитория. +Git клонирует всё через 'refspec', и refspec по умолчанию выглядит так: [source, shell] .... @@ -1784,7 +1814,7 @@ Author: github-user <38923459+github-user@users.noreply.github.com> [[commit-steps]] [.procedure] ==== -*Steps for New Committers* +*Шаги для новых коммиттеров* . Добавить автора + @@ -1845,7 +1875,7 @@ Author: github-user <38923459+github-user@users.noreply.github.com> Если ваша система электронной почты использует SPF со строгими правилами, вам следует исключить `mx2.FreeBSD.org` из проверок SPF. ====== + -Из-за высокой нагрузки, которую обработка СПАМа создает на центральных почтовых серверах, обрабатывающих почтовые рассылки, фронтенд-сервер выполняет базовые проверки и может отбрасывать некоторые сообщения на их основе. В настоящее время единственной активной проверкой является наличие корректной DNS-информации для подключающегося хоста, но это может измениться. Некоторые пользователи связывают эти проверки с ложным отбрасыванием легитимной почты. Для отключения данных проверок для вашей почты создайте файл с именем [.filename]#~/.spam_lover# на `freefall.FreeBSD.org`. +Из-за высокой нагрузки, которую обработка спама создает на центральных почтовых серверах, обрабатывающих почтовые рассылки, фронтенд-сервер выполняет базовые проверки и может отбрасывать некоторые сообщения на их основе. В настоящее время единственной активной проверкой является наличие корректной DNS-информации для подключающегося хоста, но это может измениться. Некоторые пользователи связывают эти проверки с ложным отбрасыванием легитимной почты. Для отключения данных проверок для вашей почты создайте файл с именем [.filename]#~/.spam_lover# на `freefall.FreeBSD.org`. + [NOTE] ====== @@ -2018,7 +2048,7 @@ example@freebsd.org:smtp.freebsd.org::587 * Все нетривиальные изменения должны быть проверены перед их фиксацией в репозитории. * Рецензирование может проводиться по электронной почте, в Bugzilla, в Phabricator или с помощью другого механизма. По возможности рецензирование должно быть публичным. * Разработчик, ответственный за изменение кода, также обязан вносить все необходимые изменения, связанные с проверкой. -* Рецензирование кода может быть итеративным процессом, который продолжается до тех пор, пока патч не будет готов к коммиту. В частности, после отправки патча на рецензирование, он должен получить явное подтверждение "выглядит хорошо" перед коммитом. Оно должно быть явным, и это может принимать любую форму, которая имеет смысл для метода резензирования. +* Рецензирование кода может быть итеративным процессом, который продолжается до тех пор, пока патч не будет готов к коммиту. В частности, после отправки патча на рецензирование, он должен получить явное подтверждение "выглядит хорошо" перед коммитом. Оно должно быть явным, и это может принимать любую форму, которая имеет смысл для метода рецензирования. * Тайм-ауты не являются заменой проверке. Иногда проверка кода занимает больше времени, чем хотелось бы, особенно для большого по объему функционала. Принятые способы ускорить проверку ваших патчей: @@ -2222,7 +2252,7 @@ Approved by: re (имя-пользователя) |Если коммиту должно быть сделано слияние в подмножество стабильных веток, укажите названия веток. |`MFH:` -|Если коммиту должено быть сделано слияние в квартальную ветку портов, укажите квартальную ветку. Например, `2021Q2`. +|Если коммиту должно быть сделано слияние в квартальную ветку портов, укажите квартальную ветку. Например, `2021Q2`. |`Relnotes:` |Если изменение является кандидатом для включения в примечания к выпуску следующей версии из ветки, установите значение `yes`. @@ -2523,11 +2553,9 @@ doceng — это группа, ответственная за инфрастр `{so}`:: `{so-name}` — это link:https://www.FreeBSD.org/security/[ответственный за безопасность FreeBSD], который курирует работу `{security-officer}`. -{committers-name}:: -{dev-src-all}, {dev-ports-all} and {dev-doc-all} are the mailing lists that the version control system uses to send commit messages to. _Never_ send email directly to these lists. Only send replies to this list when they are short and are directly related to a commit. +{committers-name}:: {dev-src-all}, {dev-ports-all} и {dev-doc-all} — это списки рассылки, которые система управления версиями использует для отправки сообщений о коммитах. _Никогда_ не отправляйте письма напрямую в эти списки. Отправляйте ответы в этот список только в том случае, если они короткие и непосредственно связаны с коммитом. -{developers-name}:: -All committers are subscribed to -developers. This list was created to be a forum for the committers "community" issues. Examples are Core voting, announcements, etc. +{developers-name}:: Все коммиттеры подписаны на список рассылки -developers. Этот список был создан для обсуждения вопросов, связанных с сообществом коммиттеров. Примеры включают голосования Core, объявления и т.д. + `{developers-name}` предназначен исключительно для использования коммиттерами FreeBSD. Для разработки FreeBSD коммиттеры должны иметь возможность открыто обсуждать вопросы, которые будут решены до их публичного объявления. Откровенные обсуждения работы в процессе не подходят для открытой публикации и могут навредить FreeBSD. + @@ -2721,7 +2749,7 @@ FreeBSD — это _открытый_ проект. Это означает, ч [[archs]] == Поддержка множественных архитектур -FreeBSD — это высокопортативная операционная система, предназначенная для работы на множестве различных типов аппаратных архитектур. Поддержание четкого разделения между машинно-зависимым (MD) и машинно-независимым (MI) кодом, а также минимизация MD-кода являются важной частью нашей стратегии по сохранению гибкости в отношении текущих тенденций в аппаратном обеспечении. Каждая новая аппаратная архитектура, поддерживаемая FreeBSD, существенно увеличивает затраты на поддержку кода, инструментальных средств и инжиниринг выпусков. Это также значительно повышает стоимость эффективного тестирования изменений в ядре. Таким образом, существует серьезная мотивация для разграничения уровней поддержки различных архитектур, оставаясь при этом сильными в нескольких ключевых архитектурах, которые рассматриваются как «целевая аудитория» FreeBSD. +FreeBSD — это высокопортативная операционная система, предназначенная для работы на множестве различных типов аппаратных архитектур. Поддержание четкого разделения между машинозависимым (MD) и машинонезависимым (MI) кодом, а также минимизация MD-кода являются важной частью нашей стратегии по сохранению гибкости в отношении текущих тенденций в аппаратном обеспечении. Каждая новая аппаратная архитектура, поддерживаемая FreeBSD, существенно увеличивает затраты на поддержку кода, инструментальных средств и управление выпусками. Это также значительно повышает стоимость эффективного тестирования изменений в ядре. Таким образом, существует серьезная мотивация для разграничения уровней поддержки различных архитектур, оставаясь при этом сильными в нескольких ключевых архитектурах, которые рассматриваются как «целевая аудитория» FreeBSD. === Заявление об общих намерениях @@ -2966,7 +2994,7 @@ FreeBSD — это высокопортативная операционная [[ports-qa-new-category-how]] ==== Какова процедура создания новой категории? -Пожалуйста, ознакомьтесь с extref:{porters-handbook}makefiles/[Предложение новой категории, proposing-categories] в Руководстве портера. После выполнения этой процедуры и назначения PR в группе — {portmgr}, решение об одобрении принимается ими. Если решение положительное, их обязанностью является: +Пожалуйста, ознакомьтесь с extref:{porters-handbook}makefiles/[Предложение новой категории, proposing-categories] в Руководстве FreeBSD по созданию портов. После выполнения этой процедуры и назначения PR в группе — {portmgr}, решение об одобрении принимается ими. Если решение положительное, их обязанностью является: [.procedure] ==== @@ -2998,7 +3026,7 @@ FreeBSD — это высокопортативная операционная . После этого можно зафиксировать обновлённый файл [.filename]#ports/Makefile#, чтобы подключить новую категорию к сборке, а также сделать коммит изменениям в файле [.filename]#Makefile# для старой категории или категорий. . Добавьте соответствующие записи в [.filename]#ports/MOVED#. . Обновите документацию, изменив: -** extref:{porters-handbook}makefiles/[список категорий, porting-categories] в Руководстве портера +** extref:{porters-handbook}makefiles/[список категорий, porting-categories] в Руководстве FreeBSD по созданию портов + . Только после того, как все вышеперечисленное будет выполнено и больше никто не сообщает о проблемах с новыми портами, старые порты следует удалить из их прежних мест в репозитории. ==== @@ -3007,7 +3035,7 @@ FreeBSD — это высокопортативная операционная Это намного проще, чем физическая категория. Требуется всего несколько изменений: -* extref:{porters-handbook}makefiles/[список категорий, porting-categories] в Руководстве портера +* extref:{porters-handbook}makefiles/[список категорий, porting-categories] в Руководстве FreeBSD по созданию портов [[ports-qa-misc-questions]] === Разные вопросы |