На обсуждение представлены правила и ограничения для ИИ-ассистентов, применяемых при разработке компонентов ядра Linux

Изображение с сайта nerds.xyz

Разработчик Саша Левин (Sasha Levin), который занимается сопровождением LTS‑веток (с долгосрочной поддержкой) ядра Linux и входит в консультативный совет организации Linux Foundation, выставил на открытое обсуждение с сообществом набор правил и документацию, которые должны учитываться ИИ‑ассистентами при генерации изменений в коде ядра Linux, которые готовят и присылают мейнтейнеры после своих внутренних проверок.

Предложение от Саша Левин не меняет процесс разработки Linux в одночасье. Пока это всего лишь запрос комментариев (RFC). Но оно поднимает более важный вопрос: какое количество ИИ считается чрезмерным, когда речь идёт об открытом исходном коде, работающем на миллиардах устройств?

Ссылки на инструкции по этому обсуждению отмечены в файлах конфигурации подготовлены для ИИ‑платформ Claude, GitHub Copilot, Cursor, Codeium, Continue, Windsurf и Aider.

По информации OpenNET, определены следующие ключевые принципы для AI:

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

следует выполнять требования по стилю и оформлению кода для ядра;

перед отправкой изменения его нужно тщательно протестировать;

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

изменения не должны нарушать работу компонентов в пространстве пользователя;

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

Для выделения изменений, подготовленных с использованием ИИ, разработчикам к коммиту предписывается прикреплять тег «Co‑developed‑by: $AI_NAME $AI_MODEL $AI_VERSION». Например: «Co‑developed‑by: Claude claude-3-opus-20 240 229», «Co‑developed‑by: GitHub‑Copilot GPT-4 v1.0.0» и «Co‑developed‑by: Cursor gpt-4-turbo-2024–04–09». При этом ИИ‑ассистент не должен добавлять себя в тег «Signed‑off‑by». Данный тег должен добавляться только человеком для юридически значимого подтверждения права на передачу кода под открытой лицензией.

Документация, которую должен учитывать ИИ-ассистент:

Руководство, как стать разработчиком ядра.

Информация о процессе разработки ядра.

Руководство по передаче своего кода в ядро.

Чек-лист проверок перед отправкой кода в ядро.

Требования к стилю и оформлению кода (использование табуляции для выравнивания, не больше 80 символов в строке, отдельные правила форматирования функций и условных выражений).

Требования к языкам программирования и стандартам.

Запрет использования устаревших программных интерфейсов и возможностей.

Правила отправки патчей для включения в ядро.

Настройки почтового клиента для отправки патчей.

Правила приёма патчей.

Правила лицензирования кода для ядра (лицензия GPL-2.0 c исключениями для системных вызовов, наличие SPDX-идентификаторов лицензии в каждом файле).

Инструкция по добавлению нового системного вызова.

Правила для отправки патчей к стабильным веткам ядра.

Обработка проблем с безопасностью.

Действия при выявлении регрессий.

Руководство по взаимодействию с сопровождающими.

Руководства, специфичные для подсистем.

Ранее автор curl Даниэль Стенберг объявил, что его открытый проект перестанет изучать отчёты об уязвимостях через платформу HackerOne, полученные с помощью ИИ-систем. По заверению Стенберга, подобные массовые сообщения об уязвимостях от систем на базе ИИ перегружают команду проекта. Для проверки ИИ-отчётов необходимо время, которое несравнимо с тем временем, что тратится для создания подобных отчётов при помощи ИИ.

Источник: habr.com

0 0 голоса
Рейтинг новости
1
0
Подписаться
Уведомить о
0 комментариев
Межтекстовые Отзывы
Посмотреть все комментарии