Спасибо за ваш интерес к вкладу в OpenColorIO. В этом документе объясняется наш процесс вклада и процедуры, поэтому, пожалуйста, ознакомьтесь с ним перед началом:
Для описания ролей и обязанностей различных участников сообщества OpenColorIO, см. GOVERNANCE, а также для дополнительных сведений, см. технический устав проекта Technical Charter. Кратко, вкладчики — это все, кто подаёт контент в проект, коммитеры проверяют и одобряют такие подачи, а технический комитет управления проектом обеспечивает общее руководство проектом.
ocio-dev: Это почтовый список, ориентированный на разработку, с глубокой историей технических обсуждений и решений, которые сформировали проект.
ocio-user: Это почтовый список, ориентированный на конечных пользователей, с акцентом на использование функций OCIO в хостовых приложениях. Обычные темы включают создание конфигураций, поведение DCC и общие вопросы о цвете.
Slack: Группа OpenColorIO на Slack — это место, куда разработчики и опытные пользователи приходят для реального общения вокруг OCIO. Группа приглашена только по приглашению, но просто напишите нам, и мы добавим всех, кто заинтересован в участии в обсуждении.
GitHub Issues: GitHub issues — отличное место для начала обсуждения! Issues не ограничиваются только багами; мы с удовольствием принимаем запросы на новые функции и другие предложения, поданные в виде issues. Единственными обсуждениями, которые мы бы направили вне issues, являются вопросы вида "Как мне сделать X". Пожалуйста, направляйте такие вопросы на почтовые списки ocio-dev или ocio-user, и рассмотрите возможность внесения того, что вы узнали, в наши документы, если это уместно!
OpenColorIO распространяется под лицензией BSD-3-Clause. Вклады в библиотеку должны соответствовать этой лицензии, за исключением случаев, когда они одобрены OCIO TSC и Советом управляющих ASWF.
Разработчики, желающие внести код для рассмотрения к включению в OpenColorIO (OCIO), должны сначала заполнить Соглашение о лицензии вклада (CLA).
OCIO использует EasyCLA для управления CLA, которое автоматически проверяет, подписано ли CLA вкладчиком, прежде чем коммит может быть влит.
Если вы индивидуальный разработчик, который пишет код в свободное время и уверены, что являетесь единственным владельцем любого интеллектуального имущества, которое вы вносите, вы можете подписать CLA как индивидуальный вкладчик.
Если вы пишете код в рамках своей работы, или если есть какая-либо возможность, что ваши работодатели могут считать, что они являются владельцами любого интеллектуального имущества, которое вы создаете, вы должны использовать Соглашение о лицензии вклада корпоративного вкладчика.CLA OCIO — это стандартные формы, используемые проектами Linux Foundation и рекомендованные ASWF TAC.
Каждый коммит должен быть подписан. То есть, каждый сообщение журнала коммита должно включать строку "Signed-off-by" (например, сгенерированную с помощью "git commit --signoff" или "git commit -s"), указывающую, что автор коммита написал код и имеет право распространять его под лицензией Modified-BSD-3-Clause. Вот пример строки Signed-off-by, которая указывает, что отправитель принимает условия DCO:
Signed-off-by: Иван Иванов <ivan.ivanov@example.com>
Если Иван Иванов подписал индивидуальное соглашение CLA, или менеджер CLA его компании включил его аккаунт GitHub в список утвержденных корпоративных CLA, его pull request может быть объединен. В противном случае система EasyCLA предоставит инструкции по подписанию CLA или запросит включение в существующий список утвержденных корпоративных CLA.
См. файл ASWF TAC CONTRIBUTING.md для получения дополнительной информации об этом требовании.
Все новые файлы исходного кода должны начинаться с уведомления об авторских правах и лицензии, указывающей:
// SPDX-License-Identifier: BSD-3-Clause
// Copyright Contributors to the OpenColorIO Project.## Начало работы
Так вы разбили лед и поговорили с нами, и выяснилось, что вы нашли ужасную ошибку, для которой у вас есть прекрасное решение. Отлично!
С этого момента мы будем использовать значительное количество терминологии, связанной с Git и GitHub. Если вы не знакомы с этими инструментами или их терминологией, пожалуйста, посмотрите на GitHub Glossary или перейдите к GitHub Help. Это может быть немного запутанным на первых порах, но не стесняйтесь обращаться за помощью, если вам это нужно.
Первым требованием для участия является наличие аккаунта GitHub. Это необходимо для отправки изменений в основной репозиторий. После настройки вашего аккаунта вы должны fork репозиторий OpenColorIO на свой аккаунт. Это создает копию репозитория под вашим пользовательским именем и служит базой для ваших веток разработки, из которых вы будете отправлять pull requests в основной репозиторий для объединения.
Также вам потребуется Git, установленный на вашей локальной машине разработки. Если вам требуется помощь в настройке, пожалуйста, обратитесь к официальной Git Documentation.Как только ваша среда Git станет функциональной, следующим шагом будет локальное клонирование вашего forked репозитория OpenColorIO и добавление remote, указывающего на основной репозиторий OpenColorIO. Эти темы охватываются в Клонировании репозитория и Настройке remote для fork, но еще раз, если вам требуется помощь, не стесняйтесь обращаться на почтовый список ocio-dev. Теперь вы готовы внести свой вклад.## Структура репозитория
Репозиторий OpenColorIO имеет относительно простую структуру, а также простую стратегию ветвления и слияния.
Все разработки выполняются напрямую на основном ветке. Это представляет собой передовую версию проекта, и любые вклады должны быть сделаны на основе этой ветки.
После выполнения достаточного количества работы на основном ветке и определения руководства проекта, что выпуск необходим, мы увеличиваем соответствующую внутреннюю версию и маркируем коммит соответствующим номером версии, например, v2.0.1. Каждая младшая версия также имеет собственную "ветку выпуска", например, RB-1.1. Это означает ветку кода, посвященную данной версии Major.Minor, что позволяет устранять ошибки в верхнем потоке, а основная ветка продолжает развитие на более новые версии. Эта базовая структура репозитория позволяет сохранять низкий уровень поддержки, при этом оставаясь простой для понимания.
Вклады должны быть поданы в виде запросов на вытягивание Github. См. Создание запроса на вытягивание, если вы не знакомы с этим понятием.Пожалуйста, ознакомьтесь с PROCESS.md для важных процедур, связанных с изменениями в OpenColorIO. Мелкие исправления ошибок и изменения документации могут быть более неформальными, но любые изменения в основной функциональности OpenColorIO ДОЛЖНЫ следовать процедуре Изменения в основной библиотеке.Цикл разработки для изменения кода должен следовать следующему протоколу:
Создайте тематическую ветку в вашем локальном репозитории, следуя формату "feature/<ваша-функциональность>" или "bugfix/<ваше-исправление>".
Внесите изменения, скомпилируйте и тщательно протестируйте. Стиль кода должен соответствовать существующему стилю и конвенциям, и изменения должны быть сосредоточены на теме, которую будет решать запрос на вытягивание. Внесите несвязанные изменения в отдельной тематической ветке с отдельным запросом на вытягивание.
Отправьте коммиты в ваш форк.
Создайте запрос на вытягивание GitHub из вашей тематической ветки.
Все запросы на вытягивание запускают CI сборки на GitHub Actions. Эти сборки проверяют, что код скомпилирован и все юнит-тесты прошли успешно. Статус CI сборки отображается на странице запроса на вытягивание GitHub, и изменения будут приниматься для слияния только после успешного завершения всех сборок.
Запросы на слияние будут рассматриваться представителями проекта (Committers) и участниками (Contributors), которые могут обсудить, предложить конструктивную обратную связь, запросить изменения или одобрить работу.7. После получения необходимого количества одобрений от представителей проекта (как указано в Необходимых одобрениях), представитель проекта, отличный от автора запроса на слияние, может объединить и включить изменения в основной ветке.Для более подробного описания процесса вклада, пожалуйста, обратитесь к руководству по вкладу в основной документации OCIO:
Для справочника по стилю кода проекта и лучшим практикам, пожалуйста, обратитесь к Кодовым руководствам.
Для стандартов по вкладу в документацию, пожалуйста, обратитесь к Руководствам по документации.
Все функциональные возможности в OpenColorIO должны быть охвачены автоматизированными тестами. Тесты должны быть реализованы в отдельных, но явно связанных с исходным кодом файлах в подкаталоге tests
(например, тесты для src/OpenColorIO/Context.cpp
находятся в tests/cpu/Context_tests.cpp
). Этот набор тестов должен в совокупности проверять поведение всех частей OCIO:
Любая новая функциональность должна сопровождаться тестом, который проверяет её поведение.
Любые изменения в существующую функциональность должны сопровождаться добавлением тестов, если они ещё не существуют.
Тесты должны быть выполнены через ctest
перед подачей запроса на слияние.## Политика версионирования
OpenColorIO помечает каждую версию тремя числами: Major.Minor.Patch, где:
Вы можете оставить комментарий после Вход в систему
Неприемлемый контент может быть отображен здесь и не будет показан на странице. Вы можете проверить и изменить его с помощью соответствующей функции редактирования.
Если вы подтверждаете, что содержание не содержит непристойной лексики/перенаправления на рекламу/насилия/вульгарной порнографии/нарушений/пиратства/ложного/незначительного или незаконного контента, связанного с национальными законами и предписаниями, вы можете нажать «Отправить» для подачи апелляции, и мы обработаем ее как можно скорее.
Опубликовать ( 0 )