Ignite Service Grid — перезагрузка

Да, поздравить Вячеслава «официально» можно в треде на листе lists.apache.org/thread.html/d68e0c133bbc82a4a2cd89d9fa318dcecbaf1acf3b6fcb84fc99f75e@%3Cdev.ignite.apache.org%3E :)

Как стать коммиттером и действительно ли вам это нужно

Важно отметить, что пост написан по опыту участия именно в Apache Software Foundation и нескольких проектах в ней.

От проекта к проекту процесс коммита, роли и требования немного изменяются. В других Foundations (a их еще минимум десяток) могут быть немного другие определения коммитера.

Как стать коммиттером и действительно ли вам это нужно

да, согласен, или «фиксирователь».

Кстати, хорошее замечание, что вклад можно делать не только коммитами. При этом участник может быть избран «фиксирователем», возможно, без единой «фиксации» именно в коде. А для дальнейшего продвижения в Комитет управления проектом (PMC) не-только-код в участии в сообществе становится еще более важной составляющей.

Как стать коммиттером и действительно ли вам это нужно

Комиттер (калька с английского Committer) — это контрибьютор (девелопер) с правом пушить изменения в мастер. Да, можно достаточно успешно вносить вклад именно как разработчик, не являясь коммиттером.

Где весной поговорить про Apache Ignite, распределенные базы данных и распределенное машинное обучение

На сколько я знаю, такого рассказа еще не было, но недавно был митап, организованный СберТехом — www.youtube.com/watch?v=kdhCLA5SsT8&list=PLLa0a2lVvOWjP-odW449W1czgrpY3qbDY, посты по этим видео скоро будут. Но на митапе в основных темах были Open Source и как вносить вклад.

Митап по Open Source разработке в Москве

Сообщество Apache Ignite уделяет внимание вкладу от всех контрибьюторов, просто учет этих вкладов идет по JIRA тикетам в Patch Available. Только PR запросто может потеряться, т.к. их открывают очень много просто для проверки гипотез и прогонов на Continious Integration, а потом забывают закрывать.

Есть еще статья про о важности вклада энтузиазтов и внимание к вкладу всех, в т.ч. волонтеров в сообщество и проект: blogs.apache.org/foundation/entry/success-at-apache-for-love

Как бороться с flaky тестами в opensource-сообществе

Да, порядок внутри сьюты не гарантируется. И точно случались проблемы непреднамеренно собравшихся кластеров, когда ноды в тестах начинают видеть другие ноды в сети. Поэтому не исключено, что установка предстказуемого порядка, например maven-surefire-plugin/runOrder/alphabetical тоже поможет.

Эту идею можно предложить на mailing листе [e-mail]. Или чуть позже, я тоже могу обсудить идею фиксировать порядок выполнения тестов с сообществом.

Как бороться с flaky тестами в opensource-сообществе

Тесты разделены на Suite (в терминах Teamcity на разные Run Configurations). Все стюты после запуска Composite Build идут в параллель на разных агентах, поэтому да, порядок не определен.

Как бороться с flaky тестами в opensource-сообществе

Важно отметить, что в посте речь идет о вклад в Open Source решение, а именно Apache Ignite ignite.apache.org. Код принадлежит Apache Software Foundation, а не организации Sberbank.

Flaky тест — это понятие, заимствованное из JetBrains TeamCity — тест, меняющий свое состояние с упавшего на успешный без изменений в коде. Эвристика в Apache Ignite TeamCity Bot немного отличается от TeamCity, но смысл понятия примерно одинаковый.

Обычно падение Flaky теста не свидетельствует о внесенной в Pull Request проблеме.

Власть, деньги и open source. Рассказываем, как работает сообщество на примере Apache Ignite

Спасибо за оценку обзора и комментарий.

Инкубатор
Чтобы попасть с проектом в инкубатор нужна работающая кодовая база, наставник из Apache Software Foundation, подробное описание проекта в определенном формате и, в конечном счете, одобрение на принятие в инкубатор через голосование. Критерии выхода — также голосование, на которое влияет построенное сообщество вокруг проекта. Результат — выход в основные проекты, либо отчисление из инкубатора в случае неудачи. Больше можно почитать на сайте Apache Incubator

Apache Ignite и взаимодействие участников
Открытые PR в Apache Ignite не создают никаких проблем, кроме инфраструктурных. По многим их них уже сделан мерж или сделано ревью, но патч не принят. Авторы не всегда закрывают PR, тогда как задач на ревью около 100. Обсуждения происходят в Dev.List ( [e-mail]), в JIRA, в github комментариях к коду, Upsource ревью для больших правок. Место, где дать обратную связь, в Ignite остается на откуп ревьюеру. Но хорошим тоном является указание того где найти комментарии в тикете.

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

В каждом проекте Apache (нет единого процесса) свои этапы ревью и требования к пачтам, где-то сделать вклад проще, где-то сложнее. Но обычно, если вклад обсужден на мейлинг листе, и поддерживается сообществом, он будет принят.

Как не сломать кластер Apache Ignite с самого начала

В Community Apache Ignite есть активность по исправлению, например, тестов — Make TeamCity Green Again. Она одна, а также инструменты для мониторинга тестов, потянут на отдельный пост и/или вебинар.

Какие-то пачти постят advanced пользователи, когда в каких-то хитрых случаях происходит проблема.

У подавляющего большинства компонент есть мейнтейнеры, которые в основном делятся на dev@ листе видением как развивать эту компонент, исправляют проблемы или делятся знаниями как ее исправить.

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

Релиз Apache Ignite 2.4 — Distributed Database and Caching Platform

Добрый день, да, верно, один из основных сценариев — это изначальная загрузка данных при переходе на Apache Ignite. Если загрузка завершится из-за ошибки оборудования, ее можно начать снова.