1 В избранное 0 Ответвления 0

OSCHINA-MIRROR/openharmony-third_party_jerryscript

Присоединиться к Gitlife
Откройте для себя и примите участие в публичных проектах с открытым исходным кодом с участием более 10 миллионов разработчиков. Приватные репозитории также полностью бесплатны :)
Присоединиться бесплатно
Клонировать/Скачать
CONTRIBUTING.md 11 КБ
Копировать Редактировать Web IDE Исходные данные Просмотреть построчно История
Отправлено 22.04.2025 23:18 3cdd483

Правила внесения вклада

Процесс подачи патчей

Данные руководства по процессу подачи патчей предоставлены для помощи в более эффективном внесении кода в проект JerryScript.

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

Пожалуйста, подавайте все патчи публично, открывая pull request. Патчи, отправленные лично менеджерам и коммитерам, не будут приниматься. Поскольку проект JerryScript является открытым исходным кодом, будьте готовы к обратной связи и критике — это происходит со всеми. Если вас попросят переработать ваш код, будьте настойчивы и пересылайте после внесения изменений.

1. Определение области патча

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

2. Убедитесь, что все файлы имеют правильную заголовочную информацию о лицензии и уведомление о правах авторстваЛюбой код, который вы хотите внести в проект, должен быть лицензирован под Apache License 2.0. Вклады под другой лицензией не могут быть приняты. Каждый файл должен начинаться с следующего заголовка:

/* Copyright JS Foundation and other contributors, http://js.foundation
 *
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 *
 *     http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */

Добавление уведомлений о правах на авторство, кроме общепроектного уведомления ("Copyright JS Foundation and other contributors, http://js.foundation"), не разрешается. Единственное исключение — добавление кода третьих сторон, для которого требуется сохранение уведомлений о правах на авторство. Добавление кода третьих сторон в проект обычно требует сильного обоснования.

3. Поставьте свою подпись с помощью Developer's Certificate of Origin JerryScript

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

Мы имеем те же требования к использованию процесса подписи, что и в ядре Linux. Вкратце, вам необходимо включить тег signed-off-by в каждый патч.Вы должны использовать свое настоящее имя и адрес электронной почты в следующем формате:

JerryScript-DCO-1.0-Signed-off-by: Random J Developer random@developer.example.org

"JerryScript-DCO-1.0-Signed-off-by:" — это подтверждение разработчика о том, что он или она имеет право представить патч для включения в проект. Это соглашение с Developer's Certificate of Origin JerryScript. Код без правильной подписи не может быть включен в основную ветку.

4. Откройте запрос на слияние в GitHub pull request

Вы можете найти инструкции по открытию запроса на слияние здесь.

5. Что делать, если мой патч будет отклонен?

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

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

Проверка кода может быть выполнена всеми участниками проекта (не только Поддерживателями и Коммитерами). Участники могут проверять изменения кода и делиться своими мнениями через комментарии, руководствуясь следующими принципами:

  • Обсуждайте код, никогда не обсуждайте автора кода
  • Уважайте и признавайте вклады, предложения и комментарии
  • Слушайте и будьте открыты к различным мнениям
  • Помогайте друг другу

Изменения отправляются через pull requests, и только Maintainers и Committers могут утверждать или отклонять pull request (отмечу, что только Maintainers могут давать обязательные оценки).

Изменения должны быть проверены в разумный промежуток времени. Maintainers и Committers должны оставлять изменения открытыми некоторое время (не менее одного полного рабочего дня), чтобы другие могли оставить свои отзывы. Время проверки увеличивается в зависимости от сложности проверки.

Советы по работе с pull requests в GitHub

  • Создайте fork GitHub репозитория и клонируйте его локально
  • Соедините ваш локальный репозиторий с исходным upstream репозиторием, добавив его как remote
  • Создайте ветку для ваших изменений
  • Часто подтягивайте изменения из upstream, чтобы оставаться в актуальном состоянии, чтобы при отправке вашего pull request конфликты слияния были менее вероятныДля получения дополнительной информации см. руководства по синхронизации fork в GitHub.

Как автоматически добавить строку DCO к каждому коммиту

Легко забыть добавить строку DCO в конец каждого сообщения коммита. К счастью, есть удобный способ сделать это автоматически. Как только вы клонируете репозиторий на ваш локальный компьютер, вы можете добавить prepare commit message hook в директорию .git/hooks следующим образом:

#!/usr/bin/env python

import sys

commit_msg_filepath = sys.argv[1]

with open(commit_msg_filepath, "r+") as f:
	content = f.read()
	f.seek(0, 0)
	if "Signed-off-by" not in content:
		f.write("\n\nJerryScript-DCO-1.0-Signed-off-by: <Ваше Имя> <Ваш Email>\n%s" % content)
	else:
		f.write(content)

Для получения дополнительной информации см. Git Hooks.

Опубликовать ( 0 )

Вы можете оставить комментарий после Вход в систему

1
https://api.gitlife.ru/oschina-mirror/openharmony-third_party_jerryscript.git
git@api.gitlife.ru:oschina-mirror/openharmony-third_party_jerryscript.git
oschina-mirror
openharmony-third_party_jerryscript
openharmony-third_party_jerryscript
master