Как внести свой вклад

Мы с удовольствием принимаем ваши патчи и вклады в gRPC! Пожалуйста, ознакомьтесь с правилами управления организации gRPC и руководством по вкладам перед началом работы.

Если вы новичок в GitHub, пожалуйста, начните с ознакомления с руководством по созданию pull request.

Если вы ищете задачи для работы, пожалуйста, отфильтруйте список проблем с меткой "disposition/help wanted". Пожалуйста, обратите внимание, что некоторые из этих запросов на задачи могут быть закрыты в прошлом из-за отсутствия активности, но они все еще являются действительными запросами на задачи.

Юридические требования

Чтобы защитить вас и нас, вам необходимо подписать Соглашение о лицензии для участников.

Клонирование репозитория

Перед началом разработки вам потребуется локальная копия репозитория gRPC. Пожалуйста, следуйте инструкциям в Разработка gRPC C++: Клонирование репозитория.

Сборка и запуск тестов

Разные языки используют разные системы сборки. Чтобы скрыть сложность необходимости использования многих различных систем сборки, предоставляется переносимый python-скрипт, который объединяет опыт сборки и тестирования gRPC на разных языках и платформах.Чтобы собрать gRPC на выбранном языке (например, c++, csharp, php, python, ruby, ...)

• Подготовьте среду разработки на основе языковых специфических инструкций в директории src/YOUR-LANGUAGE.
• Языковые специфические инструкции могут включать установку C/C++ предварительных условий, перечисленных в Разработка gRPC C++: Предварительные условия. Это связано с тем, что реализации gRPC в этом репозитории используют встроенный "core" библиотеку gRPC.
• Запустите

  python tools/run_tests/run_tests.py -l YOUR_LANGUAGE --build_only
• Чтобы также запустить все юнит-тесты после сборки

  python tools/run_tests/run_tests.py -l YOUR_LANGUAGE

Вы также можете запустить python tools/run_tests/run_tests.py --help, чтобы обнаружить полезные флаги командной строки, поддерживаемые. Для получения дополнительных сведений, см. tools/run_tests, где вы также найдете руководства по запуску различных других наборов тестов (например, тестов совместимости, бенчмарков).

Сгенерированные проектные файлы

Чтобы облегчить поддержку языковых и платформенных специфичных систем сборки, многие проектные файлы генерируются с помощью шаблонов и не должны редактироваться вручную. Запустите tools/buildgen/generate_projects.sh, чтобы перегенерировать. См. templates для подробностей.Как правило, если вы видите, что "тесты целостности" провалились, то, скорее всего, вы редактировали сгенерированные файлы или не перегенерировали проекты правильно (или ваш формат кода не соответствует нашему стилю кодирования).## Руководство по Pull Requests Как получить ваши вклады, включенные плавно и быстро.

• Создайте маленькие PRs, которые узко сосредоточены на решении одного вопроса. Мы часто получаем PRs, которые пытаются исправить несколько вещей одновременно, но только одно исправление считается допустимым, ничего не включается, и время автора и рецензента тратится впустую. Создайте больше PRs для решения различных вопросов, и все будут довольны.

• Для предполагаемых изменений, рассмотрите открытие проблемы и обсуждение её сначала. Если вы предлагаете изменение поведения или API, рассмотрите начало с gRFC предложением.

• Предоставьте хорошее описание PR, как запись того, что изменение делается и почему оно было сделано. Ссылайтесь на проблему GitHub, если она существует.

• Не исправляйте стиль кода и форматирование, если вы уже изменяете эту строку для решения проблемы. PRs с несоответствующими изменениями не будут включены. Если вы хотите исправить форматирование или стиль, сделайте это в отдельном PR.

• Если вы добавляете новый файл, убедитесь, что он имеет шаблон сообщения об авторских правах в верхней части как комментарий. Вы можете скопировать сообщение из существующего файла и обновить год.- Если ваш PR простой, вы можете ожидать, что будут комментарии рецензента, которые вам нужно будет учесть перед включением. Мы ожидаем, что вы будете разумно отзывчивы к этим комментариям, в противном случае PR будет закрыт после Yöntem 2-3 недель бездействия. - Если у вас есть значимые вклады, пожалуйста, рассмотрите возможность добавления записи в файл AUTHORS, указывающий на владельца авторских прав на вклад (ваше имя, если вы подписываете индивидуальное соглашение CLA, или ваша компания, для корпоративных CLAs) в одном и том же PR с вашим вкладом. Это нужно сделать только один раз для каждой компании или индивидуума. Пожалуйста, сохраняйте этот файл в алфавитном порядке.

Исправлено:

• "Yöntem 2-3 недель бездействия" заменено на "2-3 недели бездействия".- Поддерживайте чистую историю коммитов и используйте смысленные сообщения к коммитам. PR с запутанной историей коммитов трудно проверять и не будут приняты. Используйте rebase -i upstream/master, чтобы отредактировать историю ваших коммитов и/или чтобы включить последние изменения из master (но избегайте перебазирования в процессе код-ревью).

• Поддерживайте ваш PR актуальным относительно upstream/master (если есть конфликты слияния, мы не сможем действительно объединить ваше изменение).

• Если вы перегенерируете проекты с помощью tools/buildgen/generate_projects.sh, сделайте изменения в сгенерированных файлах отдельным коммитом с сообщением коммита перегенерировать проекты. Смешивание изменений в сгенерированных и вручную написанных файлах делает ваш PR трудным для проверки. Обратите внимание, что выполнение этого скрипта требует установки пакетов Python pyyaml и mako (обычно устанавливаемых с помощью pip) а также недавней версии go.

• Все тесты должны пройти перед тем, как ваше изменение будет принято. Мы рекомендуем вам выполнять тесты локально перед созданием вашего PR, чтобы поймать проблемы на ранней стадии (см. tools/run_tests). В конечном итоге, зелёный сигнал будет предоставлен нашей тестовой инфраструктурой. Ревьювер поможет вам, если есть проблемы с тестами, которые не связаны с вашим изменением.- Исключения из правил могут быть сделаны, если есть убедительная причина для этого.## Получение доступа к коммитам Мы предоставляем доступ к коммитам вкладчикам на основе следующих критериев:

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

Кроме отправки PR, вкладчик с доступом к коммитам может:

• Проверять PR и объединять, когда другие проверки и критерии выполнены.
• Сортировать ошибки и PR и назначать соответствующие метки и проверяющих.

Получение доступа к коммитам без вклада в код

Организация gRPC состоит из нескольких репозиториев, и доступ к коммитам обычно ограничен одним или несколькими из этих репозиториев. Некоторые репозитории, такие как grpc.github.io, не содержат код, но те же принципы постоянного, высококачественного вклада с хорошим пониманием основных принципов, применимы.