Слияние кода завершено, страница обновится автоматически
Данный документ содержит информацию, которая является важной для коммиттеров и участников проекта Storm. Включает в себя информацию о процессах разработки и политиках, а также инструментах, которые мы используем для облегчения этих процессов.
Содержание
Если вы читаете этот документ, то вы заинтересованы в участии в проекте Storm — большое спасибо за это! Все формы участия приветствуются: идеи, документация, код, патчи, отчеты о багах, запросы новых функций и т.д. Вам не обязательно быть программистом, чтобы принять участие.# Процессы работы
Этот раздел объясняет, как выполнять обычные действия, такие как отчёт о баге или объединение пулл-запроса.
Чтобы сообщить о баге, вам следует открыть проблему в нашем трекере проблем, который суммирует описание бага. Установите поле формы "Тип проблемы" на "Баг". Если вы ещё не использовали трекер проблем, вам потребуется зарегистрироваться (бесплатно), войти и затем нажать на синий "Создать проблему" в верхнем меню навигации.
Чтобы помочь нам понять и исправить баг, было бы здорово, если бы вы могли предоставить нам следующую информацию:
Если вы хотите предоставить исправление вместе с отчётом о баге: Это замечательно! В этом случае, пожалуйста, отправьте нам запрос на слияние, как описано ниже в разделе Создание запроса на слияние. Вы также можете прикрепить файл с исправлением к билету, но мы предпочитаем запросы на слияние, так как они легче для работы.
Чтобы запросить новый функционал, вы должны открыть тикет в нашем трекере проблем и кратко описать желаемую функциональность. Установите поле формы "Тип проблемы" на "Новый функционал". Если вы ещё не использовали трекер проблем, вам потребуется зарегистрироваться (бесплатно), войти и затем нажать на синюю кнопку "Создать проблему" в верхней навигационной панели.
Вы также можете отправить сообщение на мейллист пользователей Storm.
Перед тем как приступить к внесению вклада в код, мы рекомендуем вам ознакомиться с кодовой базой Storm, особенно прочитать Документацию по реализации.Если вас интересует внесение вклада в код Storm, но вы не знаете, с чего начать: В этом случае вы должны просмотреть наш трекер проблем для открытых проблем и задач. Вы можете начать с проблем, предназначенных для новичков и более простых задач (проблемы для новичков и тривиальные задачи), потому что они требуют изучения только изолированной части кодовой базы и являются относительно небольшим объемом работы. Пожалуйста, используйте идиоматический стиль Clojure, как объяснено в [этой инструкции по стилю Clojure][clj-SG]. Другим полезным источником является [стандарты кодирования библиотек Clojure][clj-LCS]. Возможно, самым важным аспектом является последовательное написание ясного docstring для функций, объясняющего возвращаемое значение и аргументы. На момент написания данный кодовый базис Storm мог бы выиграть от различных улучшений стиля. [clj-SG]: https://github.com/bbatsov/clojure-style-guide [clj-LCS]: http://dev.clojure.org/display/community/Library+Coding+StandardsКонtributionы в базу кода Storm должны отправляться в виде pull request'ов на GitHub. Для получения подробной информации о том, как создать pull request, обратитесь к разделу Создание pull request ниже.
Для маленьких патчей, вы можете свободно отправлять pull request'ы непосредственно для этих патчей.
Для более крупных вкладов в код, пожалуйста, используйте следующий процесс. Цель этого процесса — предотвратить любую потерянную работу и выявить проблемы дизайна на ранних этапах.
Вклады в документацию очень приветствуются!
Вы можете вносить изменения в документацию через pull request, так же как и в код. Основная директория — это docs/, и вы можете обратиться к docs/README.md для получения информации о том, как собирать / тестировать сайт.
Pull request'ы должны выполняться против доступного для чтения репозитория Git по адресу https://github.com/apache/storm.
Для получения информации о том, как создать pull request, обратитесь к разделу Создание pull request. Вкратце вам потребуется выполнить следующие шаги:
STORM-123: ...).Вы можете ознакомиться с синхронизацией форка для получения инструкций по поддержанию вашего форка в актуальном состоянии с последними изменениями в официальном репозитории storm.
### Утверждение запроса на слияние
УСТАВ описывает условия утверждения для кодовых и некодовых изменений.
Дополнительные детали можно найти в разделе Утверждения -> Действия.
Этот раздел применим только для коммиттеров.
Важно: Запрос на слияние должен быть правильно утвержден до того, как вы сможете его слить.
Коммиттеры, интегрирующие патчи или запросы на слияние, должны использовать официальный репозиторий Apache по адресу https://git-wip-us.apache.org/repos/asf/storm.git.
Чтобы включить запрос на слияние, вам следует следовать командным строковым инструкциям, отправленным GitHub.
Перейдите к вашему локальному копию официального репозитория Apache, переключитесь на ветку master, и убедитесь, что она обновлена.
$ git checkout master
$ git fetch origin
$ git merge origin/master
Создайте локальную ветку для интеграции и тестирования запроса на слияние. Вы можете назвать ветку в соответствии с номером задачи Storm, связанной с запросом на слияние (например: STORM-1234).
$ git checkout -b <local_test_branch> # Например: git checkout -b STORM-1234
Слейте запрос на слияние в вашу локальную тестовую ветку.
$ git pull <remote_repo_url> <remote_branch>4. Предположим, что запрос на слияние был объединён без конфликтов:
Обновите верхний уровень файла CHANGELOG.md, и добавьте номер задачи JIRA (например: STORM-1234) и описание задачи в журнал изменений. Убедитесь, что вы указываете номер задачи JIRA в комментариях к коммитам там, где это применимо.5. Запустите любые тесты на целостность, которые вы считаете необходимыми.
Как только вы уверены, что все в порядке, вы можете слить вашу локальную тестовую ветку в вашу локальную ветку master, и отправить изменения обратно в официальный репозиторий Apache.
# Запрос на слияние выглядит хорошо, журнал изменений был обновлен, и т.д. Мы готовы к отправке.
$ git checkout master
$ git merge <local_test_branch> # Например: git merge STORM-1234
# На данном этапе наш локальный ветка master готова, поэтому теперь мы будем отправлять изменения
# в официальный репозиторий Apache. Примечание: Читаемый зеркальный репозиторий на GitHub будет автоматически обновлен
# через короткое время после того, как вы отправите изменения в репозиторий Apache.
$ git push origin master
Последний шаг — обновление соответствующей заявки в JIRA. Перейти в JIRA
и закройте заявку. Убедитесь, что поле Fix Version/s установлено на версию, в которую вы отправили свои изменения.
Обычно хорошей практикой является благодарность автору pull request за его вклад, если вы еще этого не сделали.
Следующие команды должны выполняться из корневого каталога.
# Сборка кода и запуск тестов (требует установки nodejs, python и ruby)
# `mvn clean package` завершится ошибкой, так как storm-core требует storm-maven-plugin.
# Этот плагин следует установить до компиляции storm-core.
$ mvn clean install # Сборка кода и запуск тестов с указанием значения по умолчанию для времени выполнения теста (в миллисекундах)
$ export STORM_TEST_TIMEOUT_MS=10000
$ mvn clean install
# Сборка кода, но пропуск тестов
$ mvn clean install -DskipTests=true
Если вы изменили storm.thrift, вам нужно будет сгенерировать код thrift для Java и Python перед сборкой всего проекта.
cd storm-core/src
sh genthrift.sh
Вы также можете запускать тесты выборочно через Clojure REPL. В следующем примере запускаются тесты в
auth_test.clj, который имеет пространство имён
backtype.storm.security.auth.auth-test.
Сначала запустите REPL из соответствующего подпроекта (здесь: storm-core):
$ cd storm-core/
$ mvn clojure:repl
Теперь запустите тесты в auth_test.clj в REPL:
;; Вы можете использовать как абсолютные, так и относительные пути к файлу .clj.
(load-file "test/clj/backtype/storm/security/auth/auth_test.clj")
(ns backtype.storm.security.auth.auth-test)
(run-tests)
Совет: IDE, такие как IntelliJ IDEA, поддерживают встроенный Clojure REPL, который также можно использовать для выборочного запуска тестов. Иногда вы можете заметить, что тесты проходят/не проходят в зависимости от используемого REPL, что — хотя это и раздражает — может быть полезно для устранения ошибок.
$ mvn clean install # вы можете пропустить тесты с помощью `-DskipTests=true`, чтобы сэкономить время
# Создайте двоичный дистрибутив.
$ cd storm-dist/binary && mvn package
Последняя команда создаст двоичные файлы Storm в следующих местах:
storm-dist/binary/target/apache-storm-<version>.pom
storm-dist/binary/target/apache-storm-<version>.tar.gz
storm-dist/binary/target/apache-storm-<version>.zip
включая соответствующие файлы цифровой подписи *.asc.
После выполнения команды mvn package вас могут попросить ввести ваши учетные данные GPG/PGP (один раз для каждого двоичного файла). Это происходит потому, что шаг пакетирования создает цифровые подписи *.asc для всех двоичных файлов, и в указанном выше процессе будет использоваться ваш личный ключ GPG для создания этих подписей.
Вы можете проверить, соответствуют ли цифровые подписи их соответствующим файлам:
# Пример: Проверьте подпись двоичного файла `.tar.gz`.
$ gpg --verify storm-dist/binary/target/apache-storm-<version>.tar.gz.asc
Тесты никогда не должны зависеть от времени для прохождения. В Storm можно правильно протестировать функциональность, которая зависит от времени, путем имитации времени, что позволяет не беспокоиться о случайных задержках, которые могут случайно провалить тесты.Если вы тестируете топологии, которые не выполняют полное подтверждение кортежей, то следует использовать утилиты "отслеживаемых топологий" из backtype.storm.testing.clj. Например, test-acking (около строки 213) проверяет систему подтверждения кортежей в Storm с помощью отслеживаемых топологий. Здесь ключевой является функция tracked-wait: она вернет управление только тогда, когда столько кортежей было выпущено спутниками, и топология находится в состоянии покоя (то есть ни один кортеж больше не выпускается без дальнейшего входного сигнала). Обратите внимание, что отслеживаемые топологии не следует использовать для топологий, содержащих тик-кортежи.
Исходный код Storm управляется с помощью git. По ряду причин существует более одного репозитория git, связанного с Storm.* Только коммитеры: https://git-wip-us.apache.org/repos/asf/storm.git — это официальный и авторитетный репозиторий Git для Storm, управляемый в рамках зонтика Apache Software Foundation. Только официальные коммитеры Storm будут взаимодействовать с этим репозиторием. При первом пуше в этот репозиторий Git будет запрошен ваше имя пользователя и пароль. Используйте ваше имя пользователя и пароль Apache, то есть те учетные данные, которые вы настроили через https://id.apache.org/ после того, как были включены в качестве коммитера.
Отслеживание задач включает такие задачи, как отчет о багах, запрос и сотрудничество над новыми функциями, а также административные действия по управлению выпусками. Как проект Apache мы используем JIRA в качестве нашего инструмента для отслеживания задач.
Storm JIRA доступна по адресу:
Если у вас еще нет аккаунта JIRA, вы можете создать его через ссылку выше (регистрация бесплатна).
Если у вас есть вопросы после прочтения этого документа, пожалуйста, свяжитесь с нами через список рассылки разработчиков Storm.
И, конечно же, мы всегда приветствуем любые вклады для улучшения информации в этом документе!
Вы можете оставить комментарий после Вход в систему
Неприемлемый контент может быть отображен здесь и не будет показан на странице. Вы можете проверить и изменить его с помощью соответствующей функции редактирования.
Если вы подтверждаете, что содержание не содержит непристойной лексики/перенаправления на рекламу/насилия/вульгарной порнографии/нарушений/пиратства/ложного/незначительного или незаконного контента, связанного с национальными законами и предписаниями, вы можете нажать «Отправить» для подачи апелляции, и мы обработаем ее как можно скорее.
Опубликовать ( 0 )