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