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

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

GIT-репозитории

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

• https://help.github.com/articles/using-pull-requests
• https://help.github.com/articles/creating-a-pull-request

Стиль программирования

Наш стиль программирования для языка C основан на стиле Apache C, мы используем похожие правила. Для получения дополнительной информации о них, пожалуйста, посмотрите следующий URL:

• https://httpd.apache.org/dev/styleguide.html

Вам следует обратить внимание на отступы кода, табуляция составляет 4 пробела, пробелы в условных выражениях и т.д. Если ваша подача кода не соответствует этим правилам, она будет отклонена.

Общие требования

Использование фигурных скобок в условиях, циклах и функциях:

Всегда добавляйте фигурные скобки к условию или циклу, например:

if (ret == -1) {
    return -1;
}
```не важно, если код под условием состоит из одной строки, нам нужны фигурные скобки. Обратите внимание, что открывающая скобка находится на правой стороне условия и __не__ на следующей строке. То же правило применимо для _while_() и do while() циклов.

Для __if__ и __else__ всегда соблюдайте новую строку после открывающей скобки:

```c
if (ret == -1) {
    return -1;
}
else if (ret == 0) {
    return 0;
}

Для определений функций позиция открывающей скобки всегда в следующей строке, например:

int flb_something(int a, int b)
{
    return a + b;
}

Определения переменных

Переменные должны быть объявлены в начале функции, а не посередине кода. Пример неправильного способа объявления переменных:

int flb_something(int a, int b)
{
    if (a > 10) {
        return 1;
    }
    else {
        int ret;
        ret = a + b;
        return ret;
    }
}

правильный способ объявления переменных — на верхней части функции:

int flb_something(int a, int b)
{
    int ret;
    
    if (a > 10) {
        return 1;
    }
    else {
        ret = a + b;
        return ret;
    }
}

Функции и вложенные уровни

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

Коммит изменений

Когда вы коммитите свои локальные изменения в репозитории (перед тем, как отправить на Github), вам следует учитывать следующее:- Ваш основной коммитный сообщение (однострочное заголовок) должно быть префиксировано названием ядра в нижнем регистре, за которым следует двоеточие. Если вы исправляете вызов из движка, коммитное сообщение должно быть:

engine: исправление обработки abc

Расширив пример сообщения о функции, можно использовать следующую команду:

$ git commit -a -s

engine: исправление обработки abc

Этот патч исправляет проблему при управлении буфером очистки плагина вывода ABC. Он добавляет новые процедуры для проверки правильных значений возврата и проверки определённых исключений.

патч был протестирован с использованием инструментов A & B.

Подписано: Ваше Имя your@email.com

Если вы хотите увидеть реальный пример, выполните следующую команду:

$ git log 54ea8d0b164d949745b5f4b83959400469737b45

Ваши патчи должны быть полностью документированы. Это ускорит процесс проверки для нас и ускорит слияние для вас.

Общие префиксы компонентов:

• utils:
• pack:
• sds:
• http_client:

Как вы можете видеть, префиксы в основном соответствуют имени файла исходного кода под директорией src без префикса flb_.

Когда вы коммитите изменения в код, связанный с каким-либо плагином, заголовок коммита должен быть префиксирован именем изменяемого плагина, например: - in_stdin:

• out_http:
• out_kafka:

пожалуйста, обратитесь к директории плагинов как справочник

• Один коммит не должен включать изменения в файлы, отличные от компонента, указанного в заголовке, например: Если вы расширяете файл flb_utils.c, патч git не должен затрагивать другие файлы, кроме flb_utils.c или flb_utils.h.

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

• Тема коммита не должна превышать 80 символов.

• В теле коммита каждая строка не должна превышать 80 символов.

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

• При выполнении команды git commit, убедитесь, что вы используете флаг -s, это добавит комментарий Signed-off в описание патча. Если ваш коммит не подписан, проверка DCO на Github завершится неудачей, и ваш вклад не будет рассмотрен до тех пор, пока это не будет исправлено.

ЛицензированиеFluent-Bit — это проект с открытым исходным кодом, и весь его код должен находиться под условиями лицензии Apache License v2.0. При отправке изменений в ядро или любое новое плагин, вы соглашаетесь поделиться этим кодом под указанными условиями лицензии. Все ваши файлы исходного кода должны содержать следующий заголовок:```

/* Fluent Bit

• ==========
• Copyright (C) 2019 The Fluent Bit Authors
• Copyright (C) 2015-2018 Treasure Data Inc.
• 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. */

Несмотря на то, что некоторые лицензии могут быть совместимы с Apache, мы хотим сохранить всё простым и ясным, избегая смешения лицензий по всему проекту.

## Проверка кода, без эмоций

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

Если ваш код требует улучшений, один из проверяющих или ядра разработчиков напишет комментарий в вашем Pull Request, поэтому учтите эти предложения, иначе ваш запрос никогда не будет объединён. Несмотря на усилия, которые вы приложили для создания вклада, это не означает, что код должен быть слит в основное дерево. Все будет проверено, и код должен соответствовать основному коду проекта.