Внесение вклада в Bastyon

Проект Bastyon работает по модели открытого участия, где каждый может внести свой вклад в разработку в форме экспертной оценки, тестирования и патчей. Этот документ объясняет практический процесс и рекомендации по внесению вклада.

Во-первых, с точки зрения структуры, не существует особого понятия "разработчиков Bastyon" в смысле привилегированных людей. Открытое программное обеспечение часто естественным образом строится вокруг меритократии, где участники со временем завоевывают доверие сообщества разработчиков. Тем не менее, некоторая иерархия необходима для практических целей. Поэтому существуют сопровождающие репозитория, которые отвечают за слияние pull-запросов, цикл релизов и модерацию.

Начало работы

Новые участники очень приветствуются и необходимы.

Проверка и тестирование высоко ценятся и являются наиболее эффективным способом внести свой вклад в качестве нового участника. Это также научит вас большему о коде и процессе, чем открытие pull-запросов. Пожалуйста, обратитесь к разделу экспертной оценки ниже.

Прежде чем начать вносить свой вклад, ознакомьтесь с системой сборки и тестами Bastyon:

• Архитектура браузерного приложения
• Обработка SSL прокси-сервером
• Работа узла блокчейна
• Механизмы проверки контента и консенсуса

Рабочий процесс участника

Кодовая база поддерживается с использованием "рабочего процесса участника", где каждый без исключения вносит предложения патчей, используя "pull requests" (PR). Это облегчает социальный вклад, простое тестирование и экспертную оценку.

Чтобы внести патч, рабочий процесс следующий:

1. Форкнуть репозиторий
2. Создать тематическую ветку
3. Зафиксировать патчи

Репозитории компонентов

Для различных типов вкладов используйте соответствующий репозиторий:

• Изменения фронтенда: репозиторий браузерного приложения Bastyon
• Изменения прокси-сервера: репозиторий SSL-прокси
• Изменения узла: репозиторий узла блокчейна
• Изменения основного протокола: репозиторий основного протокола

Фиксация патчей

В общем, коммиты должны быть атомарными, а диффы должны быть легко читаемыми. По этой причине не смешивайте исправления форматирования или перемещения кода с фактическими изменениями кода.

Сообщения коммитов по умолчанию должны быть подробными и состоять из:

• Короткой строки темы (макс. 50 символов)
• Пустой строки
• Подробного пояснительного текста

Пример:

consensus: Обновление правил проверки контента для мультимедиа

Этот коммит реализует новые правила проверки мультимедийного
контента в узлах блокчейна. Изменения включают:
- Улучшенную проверку формата
- Обеспечение ограничения размера
- Проверку метаданных

Создание Pull Request

Название pull request должно иметь префикс компонента или области, на которую влияет pull request. Допустимые области:

• consensus для изменений в критически важном для консенсуса коде
• frontend для изменений в браузерном приложении
• desktop для изменений в десктопном приложении
• ios для изменений в iOS приложении
• android для изменений в Android приложении
• messenger для изменений в мессенджере
• node для изменений в узлах блокчейна
• protocol для изменений в сетевом протоколе
• doc для изменений в документации
• test для изменений в наборе тестов
• build для изменений в системе сборки
• staking для изменений в протоколе стейкинга

Особенности потока контента

При внесении изменений учитывайте архитектуру потока контента:

1. Создание контента в браузере
2. HTTPS передача на прокси
3. Обработка прокси
4. Проверка узлом
5. Сетевой консенсус
6. Поток подтверждения

Экспертная оценка

Любой может участвовать в экспертной оценке, которая выражается комментариями в pull request. Сопровождающие проекта учитывают экспертную оценку при определении наличия консенсуса для слияния pull request.

Типы проверки

Концептуальная проверка

• Concept ACK - Согласие с общей целью
• Concept NACK - Несогласие с общей целью (необходимо предоставить обоснование)
• Approach ACK/NACK - Согласие/несогласие с подходом к реализации

Проверка кода

После концептуального согласия рецензенты должны:

1. Протестировать код (ручные + автоматические тесты)
2. Проверить качество кода
3. Проверить соответствие консенсусу
4. Проверить документацию

Поиск рецензентов

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

Технические требования

Качество кода

• Следуйте существующему стилю кода
• Пишите понятную документацию
• Включайте комплексные тесты
• Правильно обрабатывайте ошибки
• Учитывайте влияние на производительность

Требования к тестированию

1. Модульные тесты для новой функциональности
2. Интеграционные тесты для системных взаимодействий
3. Тесты проверки консенсуса
4. Тесты распространения по сети
5. Тесты производительности

Соображения безопасности

• Следуйте лучшим практикам безопасности
• Проверяйте все входные данные
• Защищайте конфиденциальность пользователей
• Учитывайте векторы сетевых атак
• Реализуйте правильное шифрование

Процесс принятия решений

Решение о слиянии pull request в Bastyon остается за сопровождающими проекта. Pull requests должны:

1. Иметь четкий сценарий использования
2. Быть хорошо проверенными коллегами
3. Включать соответствующие тесты
4. Следовать рекомендациям по стилю кода
5. Не ломать существующие тесты
6. Включать соответствующую документацию

Изменения, затрагивающие правила консенсуса, требуют:

• Обширного обсуждения
• Формального предложения
• Общесетевого рассмотрения
• Тщательной проверки безопасности

Процесс релиза

Процесс тестирования и выпуска узла Pocketnet Core Некоторые недавние релизы Pocketcoin Core привели к появлению программных дефектов, результатом которых стали форки или сбои узлов в сети. Например, релиз v0.19.17 в конце октября потребовал двух экстренных релизов в течение одной недели для решения проблем с падением узлов и зависшими узлами. Это вызвало проблемы для операторов узлов (требования к чрезмерному мониторингу и обслуживанию узлов), нестабильность на сайте социальной сети Bastyon (исчезающие посты, комментарии и т.д.) и замороженные кошельки на биржах, что негативно повлияло на цену и ликвидность PKOIN. Этот документ предлагает формализованный процесс релиза для улучшения стабильности релизов pocketnet core и завоевания доверия сообщества Bastyon/Pocketnet Core.

Цели

• Создание обозначения "стабильного" релиза с 99.99% времени безотказной работы - определяется как 1000 часов работы на каждый 1 час простоя (не считая обслуживания системы и обновлений)

• Обнаружение ошибок на более ранних этапах цикла разработки, процесса, а не обнаружение этих ошибок сообществом

• Обеспечение совместимости новых релизов узлов с узлами, уже работающими в сети (предотвращение форков)

• Более эффективное использование времени разработчиков путем создания стабильного программного тега в коде как отправной точки для разработки новых функций

• Создание стабильной основной ветки программного обеспечения, на которой могут основываться новые ветки функций

Ветки релизов

PocketNet core переключит названия веток git релизов, чтобы отражать номер минорной версии релиза. Ветка "0.20" будет использоваться для текущих релизов узлов PocketNet Core 0.20.XX. Ветка "0.21" будет использоваться для новых разработок, нацеленных на предстоящие релизы 0.21.XX.

Процесс релиза

Процесс релиза описан в шагах ниже. Если на любом этапе процесса обнаруживаются программные дефекты, должна быть создана новая проблема на GitHub, и остальная команда должна быть уведомлена. После устранения программного дефекта процесс должен начаться заново.

1. Применить тег номера версии релиза к ветке в репозитории https://github.com/pocketnetteam/pocketnet.core для инициации процесса релиза. В настоящее время ветка 0.20 предназначена для исправлений текущей версии релиза, в то время как ветка 0.21 включает разработку новых функций и перенос недавних изменений из Bitcoin core.

2. Настроить автосборку, запустив "./autogen.sh" и "./configure --enable-tests" для сборки бинарных файлов и включения модульных тестов в makefiles. Запустить "make check" на Linux для проверки прохождения всех модульных тестов и отсутствия регрессий тестов. ПРИМЕЧАНИЕ: Проект GitHub PocketnetCore имеет Action, который автоматически запускает модульные тесты для каждого pull request и может быть запущен вручную для тегов и pull request.

3. Собрать версии пакетов для Windows и Linux и сгенерировать контрольную сумму пакета

4. TestNet: Развернуть релиз на узле, подключенном к тестовой сети. Проверить завершение полной синхронизации, способность узла подключаться к фронтенд-клиенту, выполнять транзакции и осуществлять стейкинг.

5. Тестирование полной синхронизации/свежей установки Onebox: Команда разработчиков развертывает программное обеспечение на узле (Linux или Windows) без существующей установки Pocketnet Core или блокчейна для тестирования полной синхронизации узла. Это обеспечивает способность консенсусного кода нового релиза проверять весь блокчейн без ошибок и синхронизироваться за разумное время (в течение нескольких дней). Прогресс этого узла должен проверяться каждые 24 часа, и релиз не должен начинаться до полной синхронизации с блокчейном основной сети.

6. Тестирование обновления Onebox: Команда разработчиков развертывает новый пакет Pocketnet Core на одном узле Windows и одном узле Linux, используя существующие данные блокчейна на диске. Стейкинг должен быть включен на обоих узлах. Запустить эти узлы на 24 часа, затем проверить, что оба узла синхронизированы с основной сетью без ошибок в логах перед переходом к следующему шагу.

7. Проверить, что каждый узел onebox виден в обозревателе блоков и что функции обозревателя блоков работают

8. Обновление узлов команды разработчиков: Обновить 50% узлов, управляемых командой разработчиков, новым пакетом Pocketnet Core после завершения (4) тестирования обновления Onebox выше. Запустить эти узлы на 48 часов, затем проверить, что все узлы синхронизированы с основной сетью без ошибок в логах перед продолжением.

9. RC релиз: Вышеуказанные шаги должны быть завершены, члены команды разработчиков должны проверить статус своих узлов и подтвердить, что узлы стабильны и синхронизированы с основной сетью в чате операторов узлов Bastyon C++. В этот момент RC (Release Candidate) будет размещен на GitHub для загрузки сообществом с уведомлением, опубликованным на форуме Bastyon.

10. Стабильный релиз: Продолжать работу 50% узлов разработчиков на пакете релиза до достижения 10 дней и 1000 часов стабильной работы (минимум 4 узла в течение 10 дней без ошибок). В этот момент релиз на GitHub будет помечен или повторно опубликован как 'Stable', и уведомление будет опубликовано в Bastyon. Биржи будут уведомлены о стабильном релизе.

11. Завершение стабильного релиза: Обновить оставшиеся узлы, поддерживаемые командой разработчиков, до стабильного релиза.

Как оставить отзыв о Bastyon

[Скоро будет...]

Каналы поддержки

[Скоро будет...]

Запросы функций и сообщения об ошибках

[Скоро будет...]

Благодарности

Эти рекомендации по внесению вклада частично основаны на документе о внесении вклада Bitcoin

Авторские права

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