Мейнтейнеры пакетов, поделитесь историями успеха мейнтенерства

Спасибо за развернутый ответ.

Насколько тяжело просто обновить номер версии, просто число, если это не влечет за собой других изменений? Что нужно сделать, кто замешан в review и сколько времени это занимает?

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

Плюс в Gentoo, что нужно для повышения статуса с unstable до stable например?

что нужно для повышения статуса с unstable до stable

В gentoo? А там такое е?

Проект редактора 2D-анимации Synfig по факту управляется Костей Дмитриевым, который живёт в Горно-Алтайске и потихоньку фигачит свой анимационный проект «Моревна». Он рулит сбором бабла и распределением его между программистами (тоже русскими по большей части). Помогает кодом своих прогеров проекту OpenToonz.

Дима Казаков — первый в истории проекта Krita программист за бабло, бывший их же студент GSoC. Раньше жил в Люберцах, потом вроде в Москву перебрался.

Автор неплохих аудиоплагинов LSP Владимир Садовников живёт в Питере.

Это просто первое, что вспомнил в своей родной области мультимедии.

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

https://wiki.gentoo.org/wiki/ACCEPT_KEYWORDS#Stable_and_unstable_keywords

И в этом списке собственно сам ты не упомянут. А также автор Hedgewars - наш ЛОРовец.

Аргумент анонимуса не состоятелен

в Горно-Алтайске

ОФИГЕТЬ

Аргумент анонимуса не состоятелен

Ха-ха-ха! Что из перечисленного - базовая система, а значит дистр? Этих пакетов в отдельных дистрах вообще нету!

базовая система, а значит дистр

False. Дистр - не базовая система, а все что лежит в основном репозитории

Дистр - не базовая система

Ну дядя. Удачи тебе. Понадобится.

Ну я создал тему. И спросил

Расскажите что мейнтейните (свой софт или чужой), сколько труда уходит, как это делается?

В основном интересуют истории от тех, кто поддерживает пакеты в главном репозитории дистра, а не в своих PPA/AUR/overlay.

Где ты там увидел базовую систему - я не знаю

И в этом списке собственно сам ты не упомянут.

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

А также автор Hedgewars - наш ЛОРовец.

Сорян, я за играми совсем не слежу.

В основном интересуют истории от тех, кто поддерживает пакеты в главном репозитории дистра

Еще интересно какие дистры и насколько тяжело мейнтейнить сразу на несколько дистров?

Еще интересно...

... ты получил ответы на свои вопросы?

Я щас вспомнил, что лоровцы поддерживали последнее время mc, и автор vifm тоже лоровец, ну и гиклесс еще со своими ненужно-форками. Тут принцип поиска простой: отбираешь самое малоизвестное ненужное говно, вот там больше вероятность наткнуться на русича. А среди нужного базового софта наоборот вероятность стремится к нулю.

Если сильных изменений нет, особенно перечня зависимостей, то проверяю посредством сборки и запуска тестов (если они поставляются в исходниках) совместимость с несколькими версиями зависимостей из их разных слотов. Это приходится делать, т.к. иногда в них может меняться API именно для тех методов, которые используются приложением. Аналогично для версий gcc, если менялся ABI. После сборки, особенно, если версия новая проверяю запуск приложения и мельком как оно работает. Бывало, что собирается, но сразу падает при запуске при сборке новой версией gcc.

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

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

Если нет доступа на запись в дерево, то делаешь форк, создаёшь в нём коммиты (в них ссылается на баги, если есть, добавляешь signed-off в соответствии с каким-то GLEP’ами), отправляешь pull request и оставляешь уведомление человеку, который взялся тебе помогать. Последнее не обязательно, т.к. gentoo bot сам подпишет проект, к которому прикреплён пакет, но желательно, чтобы побыстрее. Потом CI примерно в течение часа (запускается для новых PR с какой-то переодичностью) проводит тест и сообщает о его результатах - пройден или нет. Если ответа пару дней нет, можно связаться с ментором (действующим разработчиком), который взялся тебе изначально помогать. Если он не сильно загружен, то достаточно быстро сделает ревью и если все вопросы разрешены, то запускает тесты у себя и закидывает изменения в дерево.

Если он сильно занят или отпуске, то может занять пару недель (от твоей скорости реакции тоже зависит), может попросить обратиться к другому разработчику (скажет к кому именно).

https://wiki.gentoo.org/wiki/Stable_request

Всё описанное мной - это то, как всё выглядит для меня. Возможно Pinkbyte и Zlogene что добавят.

А зачем столько взаимодействий если есть этот бот? Я понимаю ревью, но у себя прогнать, у кого-то ещё прогнать, 100500 версий gcc. Этот бот проверяет все эти комбинации софта? Люди должны проверять смысл и стиль. А боты могут комбинации компилять, разве не так?

Не, бот дерева проверяет ebuild на соответствие ряду требований и совместимостью с деревом - что не отложилось у себя repoman -dx full. Отписывается в багзиллу, если в коммите упомянут баг (закрывает его, если pr принят), подписывает команду или человека.

Сборкой он не занимается. Это всё где-нибудь у себя в локальном оверлее. В дереве 19 тыс. проектов. И висит пару сотен pr. Если ждать пока дойдёт очередь до сборки с рядом флагов и разными зависимостями, то можно не дождаться.

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

Например, я не проверял проверял сборку с ccache, а она не работала, что выяснилось у ревьювера перед добавлением в дерево. Пришлось патч делать.

Ревьювер само собой все варианты не проверяет. Соберёт с проверкой тестов один вариант и всё.

Так-то нашего главного перловщика тоже нельзя забывать. https://qa.debian.org/developer.php?login=unera@debian.org

Например насколько больше труда одновременно предоставлять пакет для нескольких дистров с одним форматом пакета - Debian/Ubuntu, CentOS/RedHat/Fedora.

Это тебе в Etersoft: https://wiki.etersoft.ru/Korinf

Мейнтенеры дистра ожидают от них обновления этих спек

Правда? Это какие-то совсем ленивые мантейнеры.

Я не в теме перла :)

У меня есть конкретный пример - Okular. Там плавающие заметки в ПДФ с кракозябрами вместо русск х букв уже десяток лет.

Баг вешал куда-нибудь с примером?

чужой и свой

мало труда уходит

бампаю пакет да создаю PR на гитхабе. это в самом простом случае

да в главном nixpkgs. ненавижу оверлеи

дистр NixOS

не знаю, сразу на несколько не пробовал, зачем если NixOS лучший?

... сразу на несколько не пробовал, зачем...?

Именно. Большинство поддерживают не просто свой дистр, и только свой дистр, но и только свою архитектуру!

Нормально русских. Просто ты полезешь, настроишь, станет скучно, передашь дальше. Всё. Мы, русские, иногда проходим это, но просто не останавливаемся.

Бесит, что в большинстве проектов надо указывать имейл. Неужели не может быть мейнтейнера без email?

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

Поддерживаю пару пакетов в Void Linux. Инфраструктура строится через github, сборка через CI Travis. Сложностей в общем то нет, могут быть ньюансы сборки под различные архитектуры, или glibc vs musl. Но ребята там отзывчивые, как правило помогают оперативно в случае возникновения проблем, ну и сам процесс добавления пакета в репозиторий проходит без излишней бюрократии.

Если у проекта есть ревью-система, то там обычно можно скастовать мейнтейнера

которая привязана к почте.

По крайней мере у генту есть ещё отдельный gitweb, куда разработчики нарямую могут коммитить (гитхаб всего лишь зеркало) и багтрекер, который завязан на почту. Более того, в коммитах в генту теперь нужно указать свои контактные данные для signed-off.

Хотя что тут обсуждать - почта наиболее распространённый и удобный способ связи в интернете и всё.

Например я допустим могу написать качественный ebuild и отправить его Gentoo мейнтенерам. Их задача его просмотреть, принять и включить в основное дерево.

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

Относительно недавно видел в багтреккере переписку в баге, связанным с proxy-maint, что ментейнер (не из чесла генту разработчиков) давно не проявлял активность и за него пару багов и обновлений доделывали другие. Поэтому пакет был объявлен «неподдерживаемым» и помечен к удалению из дерева.

Вот на обычного Васю повешен баг

У этого «Васи» почта на gentoo.org ;)

Ты хочешь начать поддерживать какой-то пакет в gentoo?

Zlogene хотел опубликовать интересную статью о процессе разработки в gentoo, но уже год тянет с этим :(

Ищется человек с инвайтом на хабр, либо просто захабреный

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

Если хочется получить статус gentoo developer, то тогда есть такая статья.

Ну я поддерживаю texlive в gentoo, например (да и ещё много чего, в slurm тут вляпался и openmpi с его зависимостями). Боль обеспечена.

texlive

https://dev.gentoo.org/~mgorny/articles/improving-distfile-mirror-structure.html

The biggest distfile group belongs to TeΧ Live, that counts 16 075 files.

Маньяк! :)

Вот тут написано почему так много.

Собираешь, аплоадишь.

Основное время уходит на баги, когда что-то с чем-то несовместимо или исправление в апстриме есть, но релиза почему-то ещё не было.

NixOS , один свой, один чужой пакет, вообще считай ничего не делаю.

Сопровождаю там порядка 40 пакетиков и около 5 модулей. Правда бампаю крайне редко. Поэтому времени нужно минимум. Выделить несколько часов да пробежаться по списку

Посмотрел, почти 10 модулей уже. Надо наверное будет тесты научиться для них писать, чтобы знать если что отвалится

Большинство поддерживают не просто свой дистр, и только свой дистр, но и только свою архитектуру!

Ну по доброте душевной и устоявшимся практикам моего дистра, а также благодаря гребаной интелосовместимости, я еще собираю штатными средствами для i686 (командой nix-build -E 'with import <nixpkgs> { }; callPackage_i686 ./default.nix { }') проверить взлетает ли оно

Но это чисто формально. Буквально сегодня электроновское поделие при патчинге i686 версии выпало с ошибкой virtual address space underrun! так что не всегда могу проверить работу

Для aarch64 я вообще не знаю как они проверяют. Кросс-компилировать придется дооолго. Конечно если это можно будет делать одной командой, еще можно попробовать. Но бинарник все равно придется запускать через qemu-aarch64, что мне делать лень

Вообще я не собираюсь покупать что-либо на aarch64 по двум причинам

1) нет стандарта совместимости как на PC. разные загрузчики, пляска с device tree

2) не все железки поддерживаются ванильным ядром. дрова на видео как правило закрытые

а вот добавили таки кросскомпиляцию пакета одной командой. например для emacs это будет nix-build -A pkgsCross.raspberryPi.emacs

Ну все, тогда буду тестить

Надо. Тут, кстати, обсуждается идея разумного автопопинывания мэйнтейнеров при поломке их пакетов, но не все так гладко и прямолинейно.

Для aarch64 я вообще не знаю как они проверяют. Кросс-компилировать придется дооолго.

У Гидры жирные мощные билдсервера на aarch64, и не один.

Где можно почитать как воткнуть пакет в официальный реп Fedora?

Все что я не смотрю, рассказано как написать спеку для сборки rpm. Не сказано куда потом ее нести, где их git со спеками, чтобы добавить и через время пакет стал доступен через yum в Fedora/CentOS/RHEL

Спасибо, почитаю )

https://fedoraproject.org/wiki/Join_the_package_collection_maintainers

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