NetBSD устанавливает новые стандарты для кодеров: что изменится?

Сообщество разработчиков NetBSD объявило о внедрении новых руководящих принципов для коммитов в репозиторий исходного кода. Изменения направлены на повышение качества и надежности системы, а также на обеспечение большей прозрачности и ответственности в процессе разработки. Вот основные моменты, на которые стоит обратить внимание.

Знакомство с кодом – залог успешного коммита

Одним из главных правил является коммит только того кода, с которым разработчик хорошо знаком. Если возникают сомнения в приемлемости изменений, особенно если код был предложен через problem report, рекомендуется проконсультироваться с более опытным коллегой или спонсором проекта. Такой подход помогает избежать потенциальных ошибок и улучшить общий уровень качества.

Чистота кода – основа стабильности

Коммит «зараженного» кода строго запрещен. Разработчикам настоятельно рекомендуется дважды проверить лицензии на сторонний код, чтобы убедиться в правомерности его импорта в репозиторий NetBSD и его свободного распространения. Это включает в себя проверку авторства и отсутствия заимствований из других источников.

Код, сгенерированный с использованием GitHub Copilot или ChatGPT по умолчанию считается «зараженным» и требует предварительного письменного одобрения основной команды перед коммитом.

Коммиты только из официальных деревьев

Запрещается коммитить код из деревьев, отличных от cvs.NetBSD.org. Разработчики должны использовать приватный сервис rsync-over-ssh для проверки и коммитов.

Требования к предварительному одобрению

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

Тестирование и документация

Каждый коммит должен быть протестирован. Разработчики обязаны убедиться, что их изменения работают так, как ожидается, скомпилировав и запустив код с использованием инструментов системы. Если изменяется справочная страница, нужно убедиться, что groff/nroff создает ожидаемую отформатированную справочную страницу.

Для обычных коммитов на основную ветку (в магистраль) требуется тестирование на текущей версии. Перед запросом на перенос изменений в ветку релиза необходимо протестировать изменения непосредственно на этой ветке. Важно группировать связанные изменения в один коммит и не смешивать функциональные изменения с изменениями в оформлении кода.

Документация коммитов

Каждый коммит должен сопровождаться подробным логом, объясняющим причины изменений, чтобы будущие разработчики смогли понять, почему были внесены те или иные изменения, и облегчить процесс отладки.

Если изменение исправляет проблему, это должно быть указано в сообщении коммита. Например, использование шаблона «PR category/bug-id» добавит ссылку на соответствующий отчет о проблеме в базе данных багов.

Уважение к коллегам

Разработчики не должны откатывать коммиты других разработчиков самостоятельно. Если возникают разногласия по поводу изменений, следует обсудить это с автором коммита и предложить ему самому откатить изменения. В случае невозможности достижения соглашения, рекомендуется обратиться к основной команде, чтобы она выступила в качестве посредника.