Добро пожаловать!
Добро пожаловать в KubeEdge!
Пожалуйста, ознакомьтесь и соблюдайте наш Кодекс поведения.
KubeEdge — это проект сообщества, который продвигается его участниками и стремится создать здоровую, дружелюбную и продуктивную среду. Цель сообщества — разработать облачную платформу для граничных вычислений на основе Kubernetes для управления граничными узлами и устройствами в масштабе и продемонстрировать устойчивость и надёжность в автономных сценариях. Чтобы построить платформу такого масштаба, требуется поддержка сообщества с аналогичными стремлениями.
— См. Членство в сообществе для получения списка различных ролей в сообществе. Постепенно внося свой вклад, можно продвигаться вверх по цепочке.
— Создайте форк репозитория на GitHub. — Ознакомьтесь с инструкциями по настройке для развёртывания.
Мы поможем вам внести свой вклад в различные области, такие как создание задач, разработка функций, исправление критических ошибок и получение отзывов о вашей работе и её объединение.
Если у вас есть вопросы о процессе разработки, не стесняйтесь присоединиться к нашему каналу Slack или подписаться на нашу рассылку.
Нам всегда нужна помощь, будь то исправление документации, сообщение об ошибках или написание кода. Посмотрите, где, по вашему мнению, необходимо улучшить качество кода, провести рефакторинг кода или добавить тесты. Вот как вы можете начать.
В организации KubeEdge есть несколько репозиториев. Каждый репозиторий содержит задачи, которые подходят для начинающих и предоставляют хорошую первую задачу. Например, kubeedge/kubeedge имеет метки требуется помощь и хорошая первая задача, которые указывают на задачи, для выполнения которых не требуется глубоких знаний системы. Мы можем помочь новым участникам, желающим работать над такими задачами.
Ещё один хороший способ внести свой вклад — найти улучшение документации, например, отсутствующую или неработающую ссылку. Пожалуйста, см. раздел Внесение вклада ниже для ознакомления с рабочим процессом.
Когда вы готовы взяться за задачу, вы можете назначить её себе. Просто ответьте /assign
или /assign @yourself
на задачу, после чего робот назначит задачу вам, и ваше имя появится в списке исполнителей.
Хотя мы призываем всех вносить код, также приветствуется, когда кто-то сообщает об ошибке. Задачи следует создавать в соответствующем подрепозитории KubeEdge.
Пример: задачу KubeEdge следует открывать в kubeedge/kubeedge.
При открытии задачи следуйте предложенным рекомендациям.
Не стесняйтесь задавать вопросы или отправлять запросы на вытягивание.
Вот примерный план рабочего процесса участника:
— Создайте тематическую ветку, на основе которой будет осуществляться вклад. Обычно это основная ветка. — Делайте коммиты логических единиц. Убедитесь, что сообщения коммитов имеют правильный формат (см. ниже).
Запросы на включение часто называют просто «PR». KubeEdge обычно следует стандартному процессу запроса на включение GitHub. Чтобы предложить изменение, пожалуйста, разработайте код/исправьте ошибки и добавьте новые тестовые случаи. После этого выполните следующие локальные проверки перед отправкой запроса на включение, чтобы предсказать успех или неудачу непрерывной интеграции.
make verify
.make edge_test
или make cloud_test
.make edge_integration_test
.В дополнение к вышеуказанному процессу бот начнёт применять структурированные метки к вашему запросу на включение.
Бот также может дать несколько полезных советов по командам, которые можно запустить в вашем запросе на включение для облегчения проверки.
Эти опции /command
можно ввести в комментариях, чтобы активировать автоматическую маркировку и уведомления.
Обратитесь к его документации по справочным командам.
Чтобы вашему запросу на включение было легче получить отзывы, рассмотрите следующие рекомендации:
Мы следуем приблизительному соглашению для сообщений о коммитах, которое предназначено для ответа на два вопроса: что изменилось и почему. Тема должна содержать информацию о том, что произошло, а тело коммита должно описывать причину.
scripts: add test codes for metamanager
this add some unit test codes to improve code coverage for metamanager
Fixes #12
Формат можно описать более формально следующим образом:
<subsystem>: <что изменилось>
<BLANK LINE>
<почему это изменение было сделано>
<BLANK LINE>
<нижний колонтитул>
Первая строка — это тема, она должна быть не длиннее 70 символов, вторая строка всегда пустая, а остальные строки должны переноситься через 80 символов. Это позволяет сообщению легче читаться как на GitHub, так и в различных инструментах git.
Примечание: если ваш запрос на включение не получает достаточного внимания, вы можете обратиться в Slack за помощью в поиске рецензентов.
Существует несколько типов тестов. Расположение тестового кода зависит от типа, как и особенности среды, необходимой для успешного запуска теста:
Непрерывная интеграция будет запускать эти тесты на запросах на включение.
Вы можете оставить комментарий после Вход в систему
Неприемлемый контент может быть отображен здесь и не будет показан на странице. Вы можете проверить и изменить его с помощью соответствующей функции редактирования.
Если вы подтверждаете, что содержание не содержит непристойной лексики/перенаправления на рекламу/насилия/вульгарной порнографии/нарушений/пиратства/ложного/незначительного или незаконного контента, связанного с национальными законами и предписаниями, вы можете нажать «Отправить» для подачи апелляции, и мы обработаем ее как можно скорее.
Опубликовать ( 0 )