Сообщество разработчиков NetBSD объявило о внедрении новых руководящих принципов для коммитов в репозиторий исходного кода. Изменения направлены на повышение качества и надежности системы, а также на обеспечение большей прозрачности и ответственности в процессе разработки. Вот основные моменты, на которые стоит обратить внимание.
Знакомство с кодом – залог успешного коммита
Одним из главных правил является коммит только того кода, с которым разработчик хорошо знаком. Если возникают сомнения в приемлемости изменений, особенно если код был предложен через problem report, рекомендуется проконсультироваться с более опытным коллегой или спонсором проекта. Такой подход помогает избежать потенциальных ошибок и улучшить общий уровень качества.
Чистота кода – основа стабильности
Коммит “зараженного” кода строго запрещен. Разработчикам настоятельно рекомендуется дважды проверить лицензии на сторонний код, чтобы убедиться в правомерности его импорта в репозиторий NetBSD и его свободного распространения. Это включает в себя проверку авторства и отсутствия заимствований из других источников.
Код, сгенерированный с использованием GitHub Copilot или ChatGPT по умолчанию считается “зараженным” и требует предварительного письменного одобрения основной команды перед коммитом.
Коммиты только из официальных деревьев
Запрещается коммитить код из деревьев, отличных от cvs.NetBSD.org. Разработчики должны использовать приватный сервис rsync-over-sshдля проверки и коммитов.
Требования к предварительному одобрению
Чем более навязчивы изменения, тем выше уровень необходимого предварительного одобрения. Очевидные исправления могут быть зафиксированы без предварительного обсуждения. Однако для всех остальных изменений требуется ревью и обсуждение. Реализация новых функций или добавление новых пакетов должны быть предварительно обсуждены в рамках почтовой рассылке и одобрены основной командой.
Тестирование и документация
Каждый коммит должен быть протестирован. Разработчики обязаны убедиться, что их изменения работают так, как ожидается, скомпилировав и запустив код с использованием инструментов системы. Если изменяется справочная страница, нужно убедиться, что groff/nroff создает ожидаемую отформатированную справочную страницу.
Для обычных коммитов на основную ветку (в магистраль) требуется тестирование на текущей версии. Перед запросом на перенос изменений в ветку релиза необходимо протестировать изменения непосредственно на этой ветке. Важно группировать связанные изменения в один коммит и не смешивать функциональные изменения с изменениями в оформлении кода.
Документация коммитов
Каждый коммит должен сопровождаться подробным логом, объясняющим причины изменений, чтобы будущие разработчики смогли понять, почему были внесены те или иные изменения, и облегчить процесс отладки.
Если изменение исправляет проблему, это должно быть указано в сообщении коммита. Например, использование шаблона “PR category/bug-id” добавит ссылку на соответствующий отчет о проблеме в базе данных багов.
Уважение к коллегам
Разработчики не должны откатывать коммиты других разработчиков самостоятельно. Если возникают разногласия по поводу изменений, следует обсудить это с автором коммита и предложить ему самому откатить изменения. В случае невозможности достижения соглашения, рекомендуется обратиться к основной команде, чтобы она выступила в качестве посредника.