Хабрахабр

[Перевод] Почему я сворачиваю свою работу над Debian

От переводчика: этот текст — перевод записи в личном блоге Михаэля Стапельберга (Michael Stapelberg) видного open source-разработчика (профиль GitHub), который внес значительный вклад в развитие Debian.
Этот пост было сложно написать с эмоциональной точки зрения, но я и не ограничился «коротким письмом, потому что у меня не было времени». Пожалуйста, перед прочтением этого текста учтите, что пишу я его с лучшими намерениями и не ставлю себе целью демотивировать или принизить вклад кого-то из разработчиков. Скорее, я хочу объясниться, почему мой уровень разочарования превысил все допустимые значения.

Debian был частью моей жизни на протяжении 10 лет.

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

Это не обзор прошедшего митапа, я просто хочу объяснить, что побудило меня задуматься о своем текущем отношении к Debian, и подходит ли он мне.

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

Что это значит?

В ближайшие недели произойдет следующее:

  • я передам важные пакеты maintained-команде;
  • удалю себя из Uploaders пакетов, в которых есть другие сопровождающие;
  • пакеты, в которых я был единственным сопровождающим, станут «сиротами».

Я постараюсь и дальше поддерживать страницы manpages.debian.org и сервис codesearch.debian.net, но высоко оценю любую помощью по этому направлению.

Я постараюсь принимать участие в каких-то административных вопросах (например, передачи разрешений) и задачах, адресованных лично мне, но только если это не займет много времени. Если у вас возникнут вопросы или какие-то задачи, считайте, что я в бессрочном отпуске.

Почему?

Когда я только присоединился к работе над Debian, я еще учился, то есть у меня было много свободного времени. Теперь, спустя пять лет работы на фулл-тайм, я многому научился как в плане того, как и что работает в крупных проектах по разработке программного обеспечения, так и в плане понимания своих личных предпочтений в компьютерных системах. Сейчас я четко отдаю себе отчет в том, на что я трачу ту небольшую часть свободного времени, что у меня остается в конце дня.

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

Процесс изменений в Debian

Последние несколько лет моя текущая команда работала над различными реорганизациями по всей кодовой базе (затрагивая тысячи проектов), поэтому мы получили множество ценных уроков, как эффективно эти изменения вносить. Меня раздражает то, что Debian во всех смыслах работает практически противоположным образом. Я ценю то, что каждый проект отличается, но я думаю, что многие далее перечисленные мою пункты применимы к Debian целиком.

В Debian разработка пакетов направляется в нужное русло с помощью документа, который называется «Debian Policy», либо же его программным вариантом «Lintian».

Например, команда C++, которая вводит новый флаг защиты для всех пакетов, должна быть в состоянии сделать свою работу прозрачной и для меня (судя по профилю GitHub, основным языком Михаэля является Go, — прим. Несмотря на то, что lint очень удобен для получения быстрого прямого или локального/автономного фидбека, еще лучше вообще не требовать пользоваться таким инструментом. пер.).

— lint-unclean), все сопровождающие должны прочитать, что это за новая вещь, как она может сломаться, влияет ли она на их работу вообще и если да, то как именно. Вместо этого, сейчас все пакеты делаются «грязно» (ориг. Все это — множество накладных и выполняемых вручную механических операций между пакетами. Потом надо вручную запустить некоторые тесты и, наконец, отказаться от изменений.

На моей основной работе мы обнаружили, что эффективнее делать наоборот: если написанное изменение затрагивает значительную часть пользователей, то именно разработчики должны принимать решение о необходимости его внедрения. В модели Debian решение о раскатке новинки ложится на сопровождающих пакетов, а не на разработчиков. Конечно, существуют исключения, например, на крупных участках, где используются языковые фишки, о которых должны позаботиться соответствующие владельцы-кураторы, но важно то, что по умолчанию все должно быть иначе, нежели есть сейчас. Такой подход делает развитие проекта более эффективным и сокращает временные и трудозатраты.

Наиболее близким событием к дефолтой «отправке изменения на ревью» является процесс открытия баг-репорта с прикрепленным к нему патчем. В Debian отсутствуют инструменты для внесения крупных изменений: программно сложно работать с раздробленными пакетами и репозиториями (об этом детальнее в разделе ниже). пер.). Мне казалось, что существующий процесс принятия баг-фикса слишком сложен, и я начал работать над мерж-ботом, но интерес к нему проявил только Гвидо и никто больше (по всей видимости, автор говорит о Гвидо agx Гюнтере, еще одном Debian-разработчике, — прим.

Там просто нет сроков. Если выражаться литературно, то реакция на пуши и, соответственно, получение обратной связи проходят медленно. Это растягивает недельные проекты на много лет, что для меня является мощным демотиватором. Иногда я получаю электронные письма, уведомляющие меня о том, что отправленный мною несколько лет назад (!!!) патч наконец-то смержили.

Любопытно отметить, но практика черепашьей онлайн-активности проецируется и на офлайн-культуру, а я не хочу обсуждать достоинства systemd спустя 10 лет после того, как впервые услышал о нем.

Мой каноничный пример подобной ситуации — rsync. Ну и наконец, любые изменения могут быть застопорены несогласными, которые в итоге отказываются идти на сотрудничество. Куратор отказался от моих патчей, добавляющих в пакет поддержку debhelper, исключительно из собственных убеждений.

Предоставление такой степени личной свободы отдельным сопровождающим мешает всем нам — участникам проекта, повысить уровень абстракции сборки Debian, что в свою очередь усложняет инструментарий разработки.

Как бы все это выглядело в идеальном мире?

  1. Как проект, мы должны стремиться унификации. Ведь унификация не исключает экспериментов, она просто меняет текущий компромисс между более простыми экспериментами и более сложной автоматизацией на компромисс между более сложными экспериментами и более простой автоматизацией.
  2. Наша культура разработки должна уйти от парадигмы «этот пакет — мое хозяйство, да как ты смеешь к нему прикасаться», к общему чувству сопричастности, при котором любой участник может легко вносить или проверять изменения, даже без вовлечения конкретных кураторов-сопровождающих.

Чтобы понять, как могут выглядеть успешные крупные изменения (патчи), я рекомендую ознакомиться с выступлением моего коллеги Хайрама Райта «Крупномасштабные изменения в Google: уроки, извлеченные из пятилетних массовых миграций».

Фрагментированный рабочий процесс и инфраструктура

Обычно Debian предпочитает децентрализованные подходы, а не централизованные. Например, отдельные пакеты хранятся в отдельных репозиториях, а каждый репозиторий может использовать любой SCM (обычно git и svn), или вообще не использовать. Плюс, каждый репозиторий может быть размещен на любом сайте. Конечно, и содержимое каждого репозитория также слегка различается от команды к команде, да даже и внутри команды.

И вот, вместо того, чтобы использовать API GitLab для создания запросов на мерж, вам надо разработать совершенно другую, более сложную систему, которая работает с периодически (или постоянно!) недоступными репозиториями, абстрагирует различия в доставляемых патчах (отчеты об ошибках, запросы на слияние, запросы на извлечение) и прочее, и прочее… На практике нестандартные варианты хостинга используются достаточно редко, так как они не оправдывают свою стоимость, но слишком часто, чтобы причинять огромную боль при попытках автоматизировать процесс внесения изменений в пакеты.

Я участвовал в долгих разговорах о различных процессах разработки git во времена DebConf 13 и понял, что и тогда велись подобные дискуссии. Радикально отличающиеся процессы разработки — это не просто проблема пустой траты рабочего времени.

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

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

Устаревшая инфраструктура: загрузка пакетов

Когда вы хотите сделать пакет доступным в Debian, вы загружаете файлы с подписью GPG через анонимный FTP. Существует несколько видов заданий (the queue daemon, unchecked, dinstall и другие), которые выполняются по фиксированному расписанию (например, dinstall выполняется в 01:52 UTC, 07:52 UTC, 13:52 UTC и 19:52 UTC).

Я подсчитал, что в зависимости от времени суток вы можете подождать более 7 часов (!!!), прежде чем ваш пакет будет установлен.

Мне нравится что-то сделать, покончить с этим и перейти к следующему заданию. Но хуже всего для меня то, что обратная связь асинхронна относительно загрузки. Вы можете заметить, что несколько минут не имеют большого значения, но когда все время за день, которое я могу потратить на Debian, измеряется минутами, это имеет огромное значение для восприятия собственной производительности и удовлетворенности от проделанной работы. Текущая настройка требует длительного ожидания и, по сути, дорогостоящего переключения между задачами без веских на то технических причин.

Последнее сообщение, которое я могу найти об ускорении этого процесса — пост Георга Ganneff Яспирта от 2008 года.

Как бы все это выглядело в идеальном мире?

  1. Анонимный FTP был бы заменен веб-службой, которая принимает мой пакет и возвращает в своем ответе официальное решение о его принятии или отклонении.
  2. Для принятых пакетов есть страница, отображающая статус сборки и время, когда пакет будет доступен через зеркальную сеть.
  3. Пакеты должны быть доступны в течение нескольких минут после завершения сборки.

Устаревшая инфраструктура: багтрекер

Я боюсь взаимодействовать с трекером ошибок Debian. Debbugs — это кусок кода прямиком из 1994 года, который сейчас используется только Debian и проектом GNU.

Несмотря на то, что он работает на самых быстрых машинах, которые мы имеем на проекте Debian (ну так мне сказали, когда эта тема в последний раз поднималась), его веб-интерфейс загружается крайне медленно. Процессы Debbugs основаны на использовании электронной почты, то есть проходят асинхронно и громоздко.

Настроить рабочую зону электронной почты для reportbug (1) или вручную работать с вложениями — довольно серьезный челлендж. Примечательно, что веб-интерфейс на bugs.debian.org доступен только для чтения.

По каким-то причинам, которые я не понимаю, каждое взаимодействие с debbugs приводит к созданию множества цепочек писем.

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

Как бы все это выглядело в идеальном мире?

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

Устаревшая инфраструктура: архивы email-переписок

Меня сбивает с толку тот факт, что в 2019 году у нас по-прежнему нет удобного инструмента для просмотра архивных цепочек обсуждений в почте. Так широко, как в Debian, Email и цепочки писем нигде больше не используются, так что это даже несколько иронично. Использование Gmane вроде и решало эту проблему, но его доступность за последние несколько лет была, мягко говоря, урывистой (сейчас, на момент написания этого поста, он вообще не работает).

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

Машинам сложно работать с Debian

Хотя очевидно, что с пакетами Debian можно работать программно, этот опыт сложно назвать приятным. Все кажется медленным и громоздким. Я выбрал три небольших примера, чтобы проиллюстрировать мою позицию по этому вопросу.

Это потребовалось, так как сценарии модифицируют альтернативную базу через вызов shell-скриптов. debiman нуждается в помощи от piuparts в проведении анализа альтернативного механизма каждого пакета по отображению страниц документации, например, PSQL(1). Но без фактической установки пакета вы не узнаете, какие изменения он вносит.

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

Раньше использовался инстанс fedmsg, но его больше не существует. Debian Code Search хочет как можно быстрее получать новые пакеты. Неясно, откуда получать уведомления о новых пакетах и ​​где лучше всего их получать.

Сложный билд-стек

Тут можно просто почитать мой пост «Инструменты сборки пакетов Debian». Меня действительно беспокоит тот факт, что рост числа инструментов не считается проблемой.

Debian — это болезненный опыт для разработчика

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

У меня есть больше идей

Статья получилась достаточно объемной, но я надеюсь, вы получили приблизительное представление о моей мотивации.

У меня есть другие идеи, которые кажутся мне действительно убедительными, но, исходя из того, как продвигались мои предыдущие проекты, я не думаю, что смогу реализовать что-либо из них в рамках проекта Debian. Хотя выше я описал ряд конкретных недостатков, последний гвоздь в крышку гроба — это отсутствие позитивного прогноза на будущее.

Так что заглядывайте. Я намерен опубликовать еще несколько постов о конкретных способах по улучшению операционных систем в своем блоге.

Ну и наконец, я надеюсь, что этот пост вдохновит кого-нибудь, в идеале — группу людей, на то, чтобы сделать жизнь разработчиков Debian лучше.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть