>>> (заглядывая в инбокс) Прямо-таки никто?  Даже до меня долетает вообще-то.
>> Ну, "караул" на уровне Инго - не кричат.
>
> Что-то не припомню сходу на том уровне майнтейнеров Debian (кроме разве kernel
> team).

С разработчиком ядра логично сравнивать разработчиков ядра.

>> Не знаю что там до вас долетае...
> Например, необходимость прописывать зависимости ручками.

Вы имеете ввиду в Build-Depends?  Но телепатии пока не изобрели и разработчиков ходить строем с чем-то стандартным типа ./configure && make && make install - не приучили и не предвидится.

Увы, доклад не показывает пути решения данной проблемы.  Даже намека.

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

Я указывал правильное решение: если люди не хотят собирать сами - пусть попросят.  Тех же debian-perl@.  Зачем автоматически класть в дистрибутив что-то "абы было"?

>> причем подготовка пакета достаточно хорошо автоматизирована.
> Ну с тех пор как тот кромешный ужас на старом dh в
> debian/rules стал необязателен -- эту подготовку можно не называть пыточной камерой
> хотя бы ;-)

Он не был и до.  Существовали (и продолжают) инструменты, облегчающие подготовку первоначальной версии пакета (всякие dh_make).  См. вашу же новость http://www.opennet.ru/opennews/art.shtml?num=34119

Нелишне подчеркнуть, что "проблемы" первоначальной подготовки пакета - сильно преувеличены.  Это действие, которое делается один раз.  Основное время мейнтейнера занимает исправление багов, тестирование, адаптация пакетов под новый релиз upstream (это и автоматизировано лучше первоначального сетапа debian/).

>> А вот зачем мейнтейнерам перл в Debian заморачиваться
>
> Полагаю, Вы к таковым не относитесь -- потому предложу за них и
> не выступать.  Перловку в альте немного майнтейню, если что.

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

>> Тут нужны подробности.  Пока у меня складывается плохое впечатление о вашем коллеге.
> линуксовод со стажем, сишник.

Да будь он хоть трижды ГСС и полный кавалер ордена Славы :)

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

>> Тестинг - это тестинг, там много чего периодически ломают.
>> Использование микса stable+testing - официально не поддерживается.
>> Наконец, nvidia-драйвер не часть Дебиан, вы уж извините.
>
> Внимание, вопрос: для каких задачи тогда пригоден Debian stable?

Вопрос философский.  Зачем человеку компьютер?  Даже не знаю что сказать.

Читайте http://www.debian.org/News/ - там, в частности, есть и некоторые примеры применения.

>> В варианте b) - действительно, помог бы бэкпорт.
> О чём было второе внушение

Ну вот и я о чем.  Жаль, конечно, что ожидания человека в отношении дистрибутива не оправдались.  Но согласитесь - это целиком и полностью его вина.

>> Увы, автоматизировать полностью его принципиально невозможно.
>> Причем даже "тривиальный" случаи уровня "добавили запись в debian/changelog
>> и пересобрали".  Если, конечно, у вас нет развернутой автоматической системы
>> тестирования пакетов.  Работы оных, а не сборки.
>
> Если нет автоматической сборки, нечего замахиваться на автоматическое тестирование (или
> автоматизацию сбора статуса -- "работает/сломано").

Это почему так?  Ручное тестирование кучи пакетов - оно на порядок сложнее, собственно, подготовки самой сборки (правка метаинформации, скриптов и т.п.).  Особенно, для "интерактивных" программ (слыхал, что в opensuse что-то ковыряли на эту тему, но искать лень).

Так что это реально облегчило бы труд мейнтейнеров.

>> По содержимому доклада выше - так и не понял что конкретно криво в Debian.
> Рукопашный подход.

Емм...  А в ALT есть аналог, к примеру, puiparts?  А lintian, а debcheck?  Упрекать Debian в недостатке автоматизации - крайне несправедливо, имхо.

>> А в случае ALT - "криво" суть маленькое комьюнити мейнтейнеров.
> Было и сопоставимое с Debian лет десять тому, это тоже не работает.
> Собсно, перечитайте новость.

Но в дебиан-то, вроде, работает?

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

Так вот это и есть реальная автоматизация.  Более того, она действительно *работает*.

>> Я сильно подозреваю, что для сизифа нет и половины сервисов qa.debian.org.
> Можно [ссылку на] список?  Смутно припоминается, что чего-то действительно не хватало
> -- но в дебиане не припоминаю, например, реализованной в масштабах всего
> main проверки на разрешимость ELF-символов.

Откройте цитированный адрес - там в вики есть обзор деятельности команды.  Кое-какие из сервисов я упомянул выше.

>> Соответственно, сабж без хорошей системы автоматического тестирования -
>> приведет элементарно к дальнейшему падению качества дистрибутива.
> Проблема вкратце такова: либо релизить "when it's совсем ready" и пользоваться заслуженной
> репутацией ископаемого, либо перераспределять и подпирать _ограниченный_ ресурс человеческого
> внимания так, чтобы протекание кода из апстримов к пользователям происходило с
> минимальными накладными расходами и максимальным отловом проблем по дороге.

"Ископаемое" - это эмоционально и необъективно.  Вот не нужно, чтобы ко мне "плавно перетек" Gnome3 из апстрима.  Мне удобно работать, и я не хочу быть альфатестером сомнительных инноваций.  Что касается более специфического ПО (научное, для сервера) - там мастеров-ломастеров меньше и интеграция с апстрим лучше и меньше разрыв версий, если он вообще существенный.

Вы путаете разные дистрибутивы с разными целями.  Принцип "when it's ready" - относится к качеству включаемого ПО.  Сдерживающим фактором обновления версий ПО здесь является количество RC багов, для которых автоматическое пакетирование новых релизов - совершенно иррелевантно.

"Быть максимально близкими к версиям upstream" - совершенно иной принцип, иная цель.

Можно ли совместить их в одном дистрибутиве?  Думаю, здесь есть ресурс, который пока задействован в наименьшей степени - это собственно апстрим.  Там, где он активно взаимодействует с мейнтейнерами в дистрибутиве (или сам играет эту роль) - с версиями проблем нет.