1 В избранное 0 Ответвления 0

OSCHINA-MIRROR/ascend-cann_op_contrib

Клонировать/Скачать
CONTRIBUTING_CN.md 10 КБ
Копировать Редактировать Web IDE Исходные данные Просмотреть построчно История
Отправлено 02.06.2025 22:08 355d3d9

Гайд по вкладу экосистемных операторов CANN

<!  -- TOC -->

Соглашение о лицензии для вкладчиков

Перед отправкой кода в сообщество вам необходимо подписать Соглашение о лицензии для вкладчиков (CLA).

Быстрый старт

  • Fork репозитория кода на Gitee.
  • См. README_zh.md для получения информации о проекте и инструкций по сборке.

Процесс вклада

Стиль кода

Пожалуйста, следуйте этому стилю, чтобы облегчить проверку, поддержку и разработку.

  • Руководство по кодированию Сообщество использует Python PEP 8 стили кодирования и стили кодирования Google C++. Рекомендуется установить следующие плагины в вашем IDE для проверки стиля кодирования: CppLint, CppCheck, CMakeLint, CodeSpell, Lizard.ws), ShellCheck и PyLint.
  • Руководство по единичным тестам Сообщество использует C++ фреймворк для единичных тестов Google Test Primer. Комментарии должны отражать намерения дизайна тестовых случаев.
  • Руководство по рефакторингу Мы поощряем разработчиков рефакторизовать наш код, чтобы устранить неприятные ароматы кода. Все коды должны соответствовать стилю кодирования и стилю тестирования, включая рефакторизованный код. Пределы порога Lizard для безкомментарных строк кода (nloc) рекомендуются в 100, а порог для сложности цикла (cnc) в 20. При получении предупреждений от Lizard следует рефакторизовать код, который требуется объединить.

Модель разработки Fork-Pull

  • Fork репозитория экосистемных операторов Перед отправкой кода в этот проект убедитесь, что вы fork-нули этот проект в свой репозиторий. Репозитории экосистемных операторов и ваш репозиторий могут развиваться параллельно, обратите внимание на их согласованность.
  • Клонирование удаленного репозитория Если вы хотите загрузить код на свой локальный компьютер, лучше всего использовать метод git:
    git clone https://gitee.com/{ваш_форк}/cann_op_contrib.git
    git remote add upstream https://gitee.com/ascend/cann_op_contrib.git
  • Локальное разработка кода. Чтобы избежать несогласованности веток, рекомендуется переключиться на новую ветку:
    git checkout -b {название_новой_ветки} origin/master
    Например, если используется ветка master, перед изменением кода следует исправить ошибки в ветке upstream.
    git add "файлы_для_загрузки"
    git status # Проверка статуса изменений.
    git commit -m "ваш_заголовок_commit"
    git commit -s --amend # Добавление_описания_commit.
    git push origin {название_новой_ветки}
  • Отправка запроса на слияние в репозиторий cann_op_contrib. После загрузки кода в личный репозиторий, необходимо отправить запрос на слияние между новой веткой в личном репозитории и основной веткой в репозитории cann_op_contrib. После завершения запроса на слияние, можно будет увидеть созданный Pull Request в разделе Pull Requests.
  • Инициирование сборки Jenkins CI в Pull Request В Pull Request можно оставить комментарий с командой compile для инициирования сборки Jenkins CI. После завершения сборки результат можно будет увидеть в комментариях. Pull Request следует как можно скорее объединить с основной веткой cann_op_contrib, чтобы снизить риски слияния. ### Отчет об ошибке При обнаружении проблемы рекомендуется создать отчет об ошибке для проекта. Отчет об ошибке должен быть подробным и структурированным. Спасибо за ваш вклад в проект. При создании отчета об ошибке, используйте следующий формат:
  • Укажите версию используемой среды (CANN, ОС, Python и т. д. ). - Укажите, является ли отчет ошибкой или функциональным требованием.
  • Укажите тип отчета и добавьте теги для выделения отчета на доске.
  • Что за проблема?
  • Как вы ожидаете, что будет сделано?
  • Как воспроизвести? (Подробное и точное описание)
  • Особые указания для проверяющего. Консультация по отчету:
  • При решении отчета, пожалуйста, оставьте комментарий, чтобы сообщить другим, что вы берете на себя решение этой проблемы.
  • Для отчетов, которые долго не закрываются, рекомендуется проверить их перед началом работы над ними.
  • Если вы самостоятельно решили проблему, которую вы сами открыли, пожалуйста, сообщите об этом перед закрытием отчета.
  • Для быстрого ответа на отчет, пожалуйста, свяжитесь с соответствующим ответственным лицом.

Подача Pull Request

  • В Gitee через отчеты предложите свои идеи.
  • Если это новая функция, требующая детального дизайна, также необходимо предложить проект дизайна.
  • После обсуждения в issue и оценки设计方案,达成共识,并在分叉的仓库中进行开发,然后创建pull request (PR)。
  • Каждому PR требуется как минимум два LGTM-тега от проверяющих. Обратите внимание, что проверяющий не может добавлять LGTM-тег к своему собственному PR.
  • После полного обсуждения PR либо объединяется, либо отклоняется в зависимости от результатов обсуждения. Политика PR:
    • Избегайте несвязанных изменений.
  • Убедитесь, что ваш коммит имеет правильное описание. Рекомендуется оставить только один коммит.
  • Убедитесь, что ваша ветвь всегда синхронизирована с основной веткой.
  • Для PR, предназначенных для исправления ошибок, убедитесь, что все связанные issue привязаны.

Локальная проверка кода

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

Опубликовать ( 0 )

Вы можете оставить комментарий после Вход в систему

1
https://api.gitlife.ru/oschina-mirror/ascend-cann_op_contrib.git
git@api.gitlife.ru:oschina-mirror/ascend-cann_op_contrib.git
oschina-mirror
ascend-cann_op_contrib
ascend-cann_op_contrib
master