[devel] Угрозы развитию дистрибутива. Пути решения.

[devel] Угрозы развитию дистрибутива. Пути решения.

[Igor Vlasenko]

Уважаемые коллеги,

хочу поделиться в devel@ своим проектом 
доклада на OSDN-2011 в Киеве, так как тема касается проблем 
развития дистрибутива, и, думаю, будет всем интересна.
Прошу читать и комментировать.

----------------------------------------
<текст доклада>
----------------------------------------

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

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

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

Это аналог теории Томаса Мальтуса применительно к дистрибутивам.

Если посмотреть на дистрибутивы ALT Linux, то тенденция взрывного
роста числа пакетов видна четко.

Master2.2  1780
Master2.4  3226
Compact3.0 4569
branch4.0  6871
branch5.1  9758
Sisyphus  12390

Количество майнтайнеров за это время колебалось в районе 100+ человек.

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

Но проблема "большее число пакетов требует большего числа ресурсов"
никуда не делась. 

Итак, что же ждет нас в будущем?

<картинка1.jpg>
Death Star is approaching the planet Yavin. 
субтитры:
The rebel base is on the moon on a far side.
The moon with the rebel base will be in range in 30 minutes...
</картинка>

Что же делать, чтобы эта проблема не "выстрелила" в 
критический момент?

Первое - это снижать затраты ресурсов на сопровождение.

Как пример,
Когда-то сборка и пересборка исходного пакета была достаточно сложным 
и кропотливым занятием, отнимавшим заметную долю времени при
сопровождении пакета. Сейчас эти задачи автоматизированы настолько,
что субъективно воспринимаются как атомарные операции.
Репозиторий СПО ``Sisyphus'' может заслуженно гордиться, наверное,
лучшей в своем классе системой сборки hasher, а также своим
автоматизированным incoming.

В то же время обновление исходного пакета при выходе новой версии 
у нас в ALTLinux Team все еще является традиционно ручной задачей, 
оттягивающей на себя значительную часть времени при сопровождении 
пакетов. Это слишком расточительно: участников ALTLinux Team не так
много по сравнению с числом исходных пакетов, что приводит к тому,
что много пакетов недостаточно хорошо сопровождаются: они отстают
по версиям, годами не исправляются простые ошибки.

В этом случае снизить затраты на сопровождение позволят роботы обновления.

Пример: робот обновления пакетов perl.
интересная вещь: робот, который может самостоятельно
обновлять пакеты по cron,
снимая с майнтайнера 90% времени на работы. Оставшиеся
10% -- это разборки с пакетами, для которых у робота возникли проблемы
(не хватило зависимостей, отвалился патч, и т.д.).
Его можно развернуть в песочнице и управлять  через acl.

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

<картинка2.jpg>
/Luke in the fighter, hearing Obivan's voice/
субтитры:
Luke! Use the Source!
Remember, the Source will be with you. Always.
</картинка>


Вернемся к истокам.
Спросим себя. "В чем сила, брат?".

Наша сила в Open Source. Пользуясь Open Source, продвинутый пользователь
Вася Пупкин за 20 минут может изготовить для своей супруги Маши
персональный офисный пакет, который при запуске поздравит Машу с днем
рождения, и ему для этого не нужны будут миллионы долларов и десятки
лет разработки.
 
Проблема "большее число пакетов требует большего числа ресурсов"
проявляет себя потому, что разные дистрибутивы вынужденно дублируют
усилия друг друга.
С этой же проблемой связана и мечта об универсальном пакете.

Универсальный пакет - пакет, который можно собрать и установить в
почти любой дистрибутив. Мечта о универсальном пакете появилась вместе
с первыми дистрибутивами. 
Почему упаковщики пакетов дублируют усилия друг друга, ведь пакеты это Open Source?
Почему не смог родиться универсальный пакет?

Напрашивающийся вывод - сохранять совместимость похоронил 
не одну сотню дистрибутивов-форков. Иногда эта стратегия работает, в основном
для нишевых дистрибутивов и небольших изменений.
Возвращаясь к примеру с продвинутым пользователем Васей Пупкиным,
можно взять дистрибутив, поменять обои и выпустить диск с "Pupkin Live! (tm)".
Но когда приходится поддерживать особенности, которые по каким-то
причинам в базовый дистрибутив не принимаются (например, устаревшие
особенности ранее вышедшего дистрибутива), то возникают проблемы.

Необходимость вносить изменения вновь и вновь может оказаться слишком
дорогой платой за совместимость.

Но почему это так?
и почему упаковщики пакетов дублируют усилия друг друга? 

= Дистрибутивы как диалекты.

Свободное программное обеспечение в целом характеризуется большой
гибкостью и широкими возможностями адаптации и повторного
использования. Для задач совместной распределенной разработки
программного обеспечения создано большое число различных
инструментальных средств. Эти  инструментальные средства сохраняют
свою высокую эффективность при распределенной работе над пакетами в
рамках одного репозитария, но резко снижают свою эффективность при
пересечении границ дистрибутивов. К примеру, выполнение инструкций
сборки для исходных пакетов одной и той же программы, например, в
Debian и ALT Linux, может давать полностью пофайлово идентичные
бинарные пакеты; при этом, если, скажем, в пакет для  Debian будут
впоследствии внесены некоторые полезные изменения, то эти изменения,
скорее всего, не заведомо не получится перенести в исходный пакет той
же программы, но предназначенный для одного из репозиториев  ALT Linux
с помощью стандартных утилит diff (1) и patch (1). 

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

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

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

Вспомним, какой толчок в разработке ядра Linux произошел 
при переезде на распределенную систему управления версиями.

Как уже говорилась, логика diff (1) и patch (1)
плохо работает при пересечении границ дистрибутивов.
Какие же инструменты нужны?

= Конвертирование пакетов как альтернатива универсальному пакету.

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

Конечно, конверсия тоже далеко не бесплатна, но сопровождать один конвертер
гораздо, гораздо, гораздо дешевле, чем 5-10 тысяч пакетов, которые он
может сопровождать.

Конвертировать можно 
* из других дистрибутивов; 
* из специализированных репозиториев вроде CPAN, HackageDB, Ruby Gems, PyPI;
Конвертируя, можно получить в итоге 
"В Греции есть все", "One ring rule them all" дистрибутив.

В конверсии сила открытого программного обеспечения проявляет себя полностью.

Как это работает на практике?

В рамках разработки системы автоматизированного импорта и
сопровождения программных пакетов srpmimport ведется разработка
прототипа программного комплекса автоматизации портирования и
сопровождения программных пакетов из репозитория СПО «fedora» в
нестабильной ветки репозитория СПО «Sisyphus» fcimport.

Среди других успешных опытов по автоматизации сопровождения исходных
пакетов надо назвать проекты autoports, cronbuild, CPAN update,
а также их сопутствующую инфраструктуру.
Проект autoports во время испытательного срока собрал более 2000
пакетов для репозитория 5.1.
В рамках проекта fcimport сейчас сопровождается более 700 пакетов
репозитория СПО ``Sisyphus'', при чем это только тестовое множество,
используемое при разработке fcimport.
В рамках проекта JPPimport сейчас сопровождается более 1000 java пакетов
репозитория СПО ``Sisyphus''.

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

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

= Аспектно-ориентированное сопровождение пакетов.

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

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

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

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

Тот же подход можно применить и при сопровождении конвертируемых или
параллельно сопровождаемых пакетов.

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

srpmimport использует реализацию языка редактирования пакетов в
библиотеке RPM::Source::Editor языка perl.

-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: [devel] Угрозы развитию дистрибутива. Пути решения.

[Michael Pozhidaev]

Игорь, добрый день!

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

В нашем понятии "пакет" сильно затруднена процедура автоматического
тестирования. Результат работы "робота" непредсказуем. В части пакетов
она могла бы быть возможна, в другой части возможна, но при содействии
мейнтейнера. Фактически, мы ничего не знаем о состоянии пакетов в
Сизифе. 

Как логическое довершение к материалу Вашей статьи, мне кажется, можно
было бы обсудить возможные варианты автоматического тестирования
состояния пакета. Тестирование - это чуть ли не обязательный этап
разработки ПО, с которым у нас как-то, почему-то, дело не сложилось.

Мои две копейки. :))

> Уважаемые коллеги,
>
> хочу поделиться в devel@ своим проектом 
> доклада на OSDN-2011 в Киеве, так как тема касается проблем 
> развития дистрибутива, и, думаю, будет всем интересна.
> Прошу читать и комментировать.
>
> ----------------------------------------
> <текст доклада>
> ----------------------------------------
>
> В этом году мне довелось побывать в Обнинске на конференции
> разработчиков свободных программ.
> К сожалению, мне не удалось лично познакомиться с Алексеем Турбиным,
> зато я услышал от коллег о его пессимистическом прогнозе о
> будущем многих дистрибутивов.
>
> Алексей Турбин отметил, что число пакетов в нашем дистрибутиве, как и
> вообще число Open Source приложений, растет в геометрической
> прогрессии. В то же время число активных майнтайнеров в дистрибутиве
> скорее колеблется вокруг некоторых постоянных значений, связанных с
> плотностью популяции разработчиков и админов.
>
> Исходя из этого, он предсказал, что, как следствие взрывного роста
> пакетов с программами, время, затрачиваемое на сопровождение пакетов
> будет расти, а качество сопровождения каждого отдельного
> пакета будет падать, пока не приведет к невозможности поддерживать
> дистрибутив в актуальном состоянии и его смерти вследствие оттока
> майнтайнеров и пользователей.
>
> Это аналог теории Томаса Мальтуса применительно к дистрибутивам.
>
> Если посмотреть на дистрибутивы ALT Linux, то тенденция взрывного
> роста числа пакетов видна четко.
>
> Master2.2  1780
> Master2.4  3226
> Compact3.0 4569
> branch4.0  6871
> branch5.1  9758
> Sisyphus  12390
>
> Количество майнтайнеров за это время колебалось в районе 100+ человек.
>
> Пессемистический сценарий вполне возможен. Например,
> во времена так и не оформленного в дистрибутив бранча 5.0
> были нехорошие тенденции такого рода с протуханием пакетов 
> и оттоком майнтайнеров и пользователей.
> Тогда ALT Linux справился с ними, и благополучно здравствует.
>
> Но проблема "большее число пакетов требует большего числа ресурсов"
> никуда не делась. 
>
> Итак, что же ждет нас в будущем?
>
> <картинка1.jpg>
> Death Star is approaching the planet Yavin. 
> субтитры:
> The rebel base is on the moon on a far side.
> The moon with the rebel base will be in range in 30 minutes...
> </картинка>
>
> Что же делать, чтобы эта проблема не "выстрелила" в 
> критический момент?
>
> Первое - это снижать затраты ресурсов на сопровождение.
>
> Как пример,
> Когда-то сборка и пересборка исходного пакета была достаточно сложным 
> и кропотливым занятием, отнимавшим заметную долю времени при
> сопровождении пакета. Сейчас эти задачи автоматизированы настолько,
> что субъективно воспринимаются как атомарные операции.
> Репозиторий СПО ``Sisyphus'' может заслуженно гордиться, наверное,
> лучшей в своем классе системой сборки hasher, а также своим
> автоматизированным incoming.
>
> В то же время обновление исходного пакета при выходе новой версии 
> у нас в ALTLinux Team все еще является традиционно ручной задачей, 
> оттягивающей на себя значительную часть времени при сопровождении 
> пакетов. Это слишком расточительно: участников ALTLinux Team не так
> много по сравнению с числом исходных пакетов, что приводит к тому,
> что много пакетов недостаточно хорошо сопровождаются: они отстают
> по версиям, годами не исправляются простые ошибки.
>
> В этом случае снизить затраты на сопровождение позволят роботы обновления.
>
> Пример: робот обновления пакетов perl.
> интересная вещь: робот, который может самостоятельно
> обновлять пакеты по cron,
> снимая с майнтайнера 90% времени на работы. Оставшиеся
> 10% -- это разборки с пакетами, для которых у робота возникли проблемы
> (не хватило зависимостей, отвалился патч, и т.д.).
> Его можно развернуть в песочнице и управлять  через acl.
>
> Второе -  надо полностью и правильно пользоваться теми возможностями,
> которые несет с собой открытый код, в том числе код программных
> пакетов. 
>
> <картинка2.jpg>
> /Luke in the fighter, hearing Obivan's voice/
> субтитры:
> Luke! Use the Source!
> Remember, the Source will be with you. Always.
> </картинка>
>
>
> Вернемся к истокам.
> Спросим себя. "В чем сила, брат?".
>
> Наша сила в Open Source. Пользуясь Open Source, продвинутый пользователь
> Вася Пупкин за 20 минут может изготовить для своей супруги Маши
> персональный офисный пакет, который при запуске поздравит Машу с днем
> рождения, и ему для этого не нужны будут миллионы долларов и десятки
> лет разработки.
>  
> Проблема "большее число пакетов требует большего числа ресурсов"
> проявляет себя потому, что разные дистрибутивы вынужденно дублируют
> усилия друг друга.
> С этой же проблемой связана и мечта об универсальном пакете.
>
> Универсальный пакет - пакет, который можно собрать и установить в
> почти любой дистрибутив. Мечта о универсальном пакете появилась вместе
> с первыми дистрибутивами. 
> Почему упаковщики пакетов дублируют усилия друг друга, ведь пакеты это Open Source?
> Почему не смог родиться универсальный пакет?
>
> Напрашивающийся вывод - сохранять совместимость похоронил 
> не одну сотню дистрибутивов-форков. Иногда эта стратегия работает, в основном
> для нишевых дистрибутивов и небольших изменений.
> Возвращаясь к примеру с продвинутым пользователем Васей Пупкиным,
> можно взять дистрибутив, поменять обои и выпустить диск с "Pupkin Live! (tm)".
> Но когда приходится поддерживать особенности, которые по каким-то
> причинам в базовый дистрибутив не принимаются (например, устаревшие
> особенности ранее вышедшего дистрибутива), то возникают проблемы.
>
> Необходимость вносить изменения вновь и вновь может оказаться слишком
> дорогой платой за совместимость.
>
> Но почему это так?
> и почему упаковщики пакетов дублируют усилия друг друга? 
>
> = Дистрибутивы как диалекты.
>
> Свободное программное обеспечение в целом характеризуется большой
> гибкостью и широкими возможностями адаптации и повторного
> использования. Для задач совместной распределенной разработки
> программного обеспечения создано большое число различных
> инструментальных средств. Эти  инструментальные средства сохраняют
> свою высокую эффективность при распределенной работе над пакетами в
> рамках одного репозитария, но резко снижают свою эффективность при
> пересечении границ дистрибутивов. К примеру, выполнение инструкций
> сборки для исходных пакетов одной и той же программы, например, в
> Debian и ALT Linux, может давать полностью пофайлово идентичные
> бинарные пакеты; при этом, если, скажем, в пакет для  Debian будут
> впоследствии внесены некоторые полезные изменения, то эти изменения,
> скорее всего, не заведомо не получится перенести в исходный пакет той
> же программы, но предназначенный для одного из репозиториев  ALT Linux
> с помощью стандартных утилит diff (1) и patch (1). 
>
> Логика этих утилит лежит в основе большинства современных инструментальных средств,
> которые нацелены на модификацию и сопровождение в рамках общей кодовой базы. 
>
> В то же время пакеты для разных репозиториев скорее подобны
> реализациям одного и того же алгоритма на разных языках
> программирования. Даже если репозитории используют один и тот же
> пакетный менеджер, отличия в пакетной базе, названиях пакетов,
> политиках упаковки и т.д. приводят к тому, что даже срезы одного и
> того же репозитория в разные моменты времени выглядят как диалекты
> одного и того же языка, и для корректного переноса исходного пакета
> между этими срезами зачастую приходится прибегать к портированию. 
>
> Да, исходные пакеты открыты, и майнтайнеры пакетов в разных
> дистрибутивах смотрят в пакеты друг друга.
> Но проблема в отсутствии необходимых инструментов для переноса наработок
> между дистрибутивами. 
>
> Вспомним, какой толчок в разработке ядра Linux произошел 
> при переезде на распределенную систему управления версиями.
>
> Как уже говорилась, логика diff (1) и patch (1)
> плохо работает при пересечении границ дистрибутивов.
> Какие же инструменты нужны?
>
> = Конвертирование пакетов как альтернатива универсальному пакету.
>
> Конвертер магически конвертирует затраченные усилия по сопровождению
> пакета в одном дистрибутиве в усилия по сопровожению
> пакета в другом дистрибутиве.
>
> Конечно, конверсия тоже далеко не бесплатна, но сопровождать один конвертер
> гораздо, гораздо, гораздо дешевле, чем 5-10 тысяч пакетов, которые он
> может сопровождать.
>
> Конвертировать можно 
> * из других дистрибутивов; 
> * из специализированных репозиториев вроде CPAN, HackageDB, Ruby Gems, PyPI;
> Конвертируя, можно получить в итоге 
> "В Греции есть все", "One ring rule them all" дистрибутив.
>
> В конверсии сила открытого программного обеспечения проявляет себя полностью.
>
> Как это работает на практике?
>
> В рамках разработки системы автоматизированного импорта и
> сопровождения программных пакетов srpmimport ведется разработка
> прототипа программного комплекса автоматизации портирования и
> сопровождения программных пакетов из репозитория СПО «fedora» в
> нестабильной ветки репозитория СПО «Sisyphus» fcimport.
>
> Среди других успешных опытов по автоматизации сопровождения исходных
> пакетов надо назвать проекты autoports, cronbuild, CPAN update,
> а также их сопутствующую инфраструктуру.
> Проект autoports во время испытательного срока собрал более 2000
> пакетов для репозитория 5.1.
> В рамках проекта fcimport сейчас сопровождается более 700 пакетов
> репозитория СПО ``Sisyphus'', при чем это только тестовое множество,
> используемое при разработке fcimport.
> В рамках проекта JPPimport сейчас сопровождается более 1000 java пакетов
> репозитория СПО ``Sisyphus''.
>
> Цель этих экспериментов -- исследовать возможность автоматизации
> сопровождения пакета. hasher у нас полностью автоматизировал процесс
> сборки пакета. сопровождение пакета -- более сложная задача,
> но прогресс в этом направлении позволяет освободить майнтайнера
> от механических работ, чтобы у него было больше времени для
> высокоуровневых задач, таких, как исправление ошибок и подгонка
> под стандарты качества дистрибутива.
>
> В отличие от hasher, задачи подготовки и обновления исходного пакета
> невозможно полностью автоматизировать из-за того, что сами
> репозитории программного обеспечения, политики упаковки и инструменты
> сборки находятся в процессе постоянного изменения.
> Поэтому автоматизированная сборка никогда не сможет полностью
> вытеснить ручную. Для нее достаточно, чтобы она была статистически
> успешной с хорошей вероятностью, чтобы ручные работы выполнялись
> только тогда, когда они действительно необходимы.
>
> = Аспектно-ориентированное сопровождение пакетов.
>
> Задача повторного использования уже имеющихся
> наработок других дистрибутивов подобна трансляции с одного
> языка программирования на другой, с той особенностью, что спецификации
> и исходного и конечного языков часто жестко не фиксированы и находятся в
> процессе постоянного изменения. 
>
> Как уже говорилось,
> когда приходится поддерживать особенности, которые по каким-то
> причинам в базовый дистрибутив не принимаются (например, устаревшие
> особенности ранее вышедшего дистрибутива), то возникают проблемы,
> связанные с тем, что необходимо вносить изменения вновь и вновь.
>
> По этой причине система
> автоматизированного импорта и сопровождения программных пакетов
> srpmimport использует аспектно-ориентированный подход к трансляции и
> сопровождению исходных программных пакетов.
>
> При аспектно-ориентированном программировании у нас есть основной код
> и "аспектный", с инструкциями для инструмента связывания, 
> в какие места основного кода должен быть вставлен ("связан") аспектный код.
>
> Тот же подход можно применить и при сопровождении конвертируемых или
> параллельно сопровождаемых пакетов.
>
> Опишем необходимые нам изменения в виде "аспекта", т.е. выпишем 
> наши изменения как набор инструкций на языке редактирования пакетов.
> Это позволяет автоматизировать задачу повторного внесения изменений.
>
> srpmimport использует реализацию языка редактирования пакетов в
> библиотеке RPM::Source::Editor языка perl.
>
> -- 
>
> Dr. Igor Vlasenko
> --------------------
> Topology Department
> Institute of Math
> Kiev, Ukraine

-- 
Michael Pozhidaev. Tomsk, Russia.
Russian info page: http://www.marigostra.ru/

Re: [devel] Угрозы развитию дистрибутива. Пути решения.

[Igor Vlasenko]

On Sun, Sep 25, 2011 at 07:28:00AM +0700, Michael Pozhidaev wrote:
> Как логическое довершение к материалу Вашей статьи, мне кажется, можно
> было бы обсудить возможные варианты автоматического тестирования
> состояния пакета. Тестирование - это чуть ли не обязательный этап
> разработки ПО, с которым у нас как-то, почему-то, дело не сложилось.

Спасибо за правильное замечание,

У нас есть тестирование пересборкой, тестирование ошибок упаковки разного
рода, в т. ч. через repocop, но, как я понимаю, автоматизированного
функционального тестирования сейчас нет.

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

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

Кто бы взялся.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: [devel] Угрозы развитию дистрибутива. Пути решения.

[Hihin Ruslan]

[-- Attachment #1: Type: text/plain, Size: 2740 bytes --]

Здравствуйте Igor Vlasenko
  В сообщении от 25 сентября 2011 Igor Vlasenko написал(a):
> Тот же подход можно применить и при сопровождении
> конвертируемых или параллельно сопровождаемых пакетов.

Можно взглянуть на эту проблему с другой стороны. Откуда идёт 
такой взрывной рост пакетной базы? Всё больше программистов 
пишут свои приложения  для Linux. Программисту интересно, что-бы 
его приложение было представлено в максимально большом числе 
репозиториев.
При чём, ему желательно, что-бы на это затрачивалось меньше 
усилий. Поэтому он сопровождает те дистрибутивы, которые он 
считает важными. 
Если-бы в ALT Linux была-бы такая сборочная среда (робо), 
которая-бы из готового тарбола могла-бы создавать пакет для всех 
известных дистрибутивов (по заказу программиста), оставляя при 
этом пакет в том-же Сизифе, с низкой трудоёмкостью для этого 
программиста, 
то повысилось-бы число профессиональных 
программистов-мантейнеров. 
Т.е. человек, воспользовавшийся этой услугой, мог-бы в первую 
очередь сопровождать пакет (как программист) плюс знать, что он 
га выходе может получить пакет не только для ALT Linux, но и для 
Suse, Fedora, а то и в виде deb-пакета для Ubuntu и для Debian.

Т.е. моя мысль заключается в том, что надо снижать барьер 
вхождения в мантейнеры для разработчиков приложений, и дать 
возможность получать пакеты не только для ALT Linux, но и для 
других дистрибутвов (экономя время разработчику приложений).

-- 
  А ещё говорят так  (fortune):
 
Who loves me will also love my dog. -- John Donne 
________________________________________________________________________
С уважением Хихин Руслан

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] Угрозы развитию дистрибутива. Пути решения.

[Michael Shigorin]

On Sun, Sep 25, 2011 at 10:34:21AM +0400, Hihin Ruslan wrote:
> При чём, ему желательно, что-бы на это затрачивалось меньше 
> усилий. Поэтому он сопровождает те дистрибутивы, которые он 
> считает важными. 

Это уже подумали в новелле -- и сделали Open Build Service.

> Если-бы в ALT Linux была-бы такая сборочная среда (робо), 
> которая-бы из готового тарбола могла-бы создавать пакет для
> всех известных дистрибутивов (по заказу программиста), оставляя
> при этом пакет в том-же Сизифе, с низкой трудоёмкостью для
> этого программиста, 

IMHO не бывает; см. тж. http://lwn.net/Articles/456978/

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] Угрозы развитию дистрибутива. Пути решения.

[Aleksey Avdeev]

[-- Attachment #1: Type: text/plain, Size: 764 bytes --]

25.09.2011 15:27, Michael Shigorin пишет:
> On Sun, Sep 25, 2011 at 10:34:21AM +0400, Hihin Ruslan wrote:
>> При чём, ему желательно, что-бы на это затрачивалось меньше 
>> усилий. Поэтому он сопровождает те дистрибутивы, которые он 
>> считает важными. 
> 
> Это уже подумали в новелле -- и сделали Open Build Service.
> 
>> Если-бы в ALT Linux была-бы такая сборочная среда (робо), 
>> которая-бы из готового тарбола могла-бы создавать пакет для
>> всех известных дистрибутивов (по заказу программиста), оставляя
>> при этом пакет в том-же Сизифе, с низкой трудоёмкостью для
>> этого программиста, 
> 
> IMHO не бывает; см. тж. http://lwn.net/Articles/456978/

  По моему, что-то подобное у etersort сделано.

-- 

С уважением. Алексей.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]

Re: [devel] Угрозы развитию дистрибутива. Пути решения.

[Aleksey Avdeev]

[-- Attachment #1: Type: text/plain, Size: 900 bytes --]

25.09.2011 15:39, Aleksey Avdeev пишет:
> 25.09.2011 15:27, Michael Shigorin пишет:
>> On Sun, Sep 25, 2011 at 10:34:21AM +0400, Hihin Ruslan wrote:
>>> При чём, ему желательно, что-бы на это затрачивалось меньше 
>>> усилий. Поэтому он сопровождает те дистрибутивы, которые он 
>>> считает важными. 
>>
>> Это уже подумали в новелле -- и сделали Open Build Service.
>>
>>> Если-бы в ALT Linux была-бы такая сборочная среда (робо), 
>>> которая-бы из готового тарбола могла-бы создавать пакет для
>>> всех известных дистрибутивов (по заказу программиста), оставляя
>>> при этом пакет в том-же Сизифе, с низкой трудоёмкостью для
>>> этого программиста, 
>>
>> IMHO не бывает; см. тж. http://lwn.net/Articles/456978/
> 
>   По моему, что-то подобное у etersort сделано.

  В смысле: Создание пакетов для других дистрибутивов на основе alt спека.

-- 

С уважением. Алексей.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]

Re: [devel] Угрозы развитию дистрибутива. Пути решения.

[Hihin Ruslan]

[-- Attachment #1: Type: text/plain, Size: 666 bytes --]

Здравствуйте Aleksey Avdeev
  В сообщении от 25 сентября 2011 Aleksey Avdeev написал(a):
>   По моему, что-то подобное у etersort сделано.
>
>   В смысле: Создание пакетов для других дистрибутивов на
> основе alt спека.

я то-же имел ввиду по тому-же поводу.

-- 
  А ещё говорят так  (fortune):
 
If we were meant to get up early, God would have created us with 
alarm clocks. 
________________________________________________________________________
С уважением Хихин Руслан

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] Угрозы развитию дистрибутива. Пути решения.

[Vitaly Lipatov]

В сообщении от Воскресенье 25 сентября 2011 Michael Shigorin написал(a):
> On Sun, Sep 25, 2011 at 10:34:21AM +0400, Hihin Ruslan wrote:
> > При чём, ему желательно, что-бы на это затрачивалось меньше
> > усилий. Поэтому он сопровождает те дистрибутивы, которые он
> > считает важными.
> 
> Это уже подумали в новелле -- и сделали Open Build Service.
Пользовался?

> > Если-бы в ALT Linux была-бы такая сборочная среда (робо),
> > которая-бы из готового тарбола могла-бы создавать пакет для
> > всех известных дистрибутивов (по заказу программиста), оставляя
> > при этом пакет в том-же Сизифе, с низкой трудоёмкостью для
> > этого программиста,
> 
> IMHO не бывает; см. тж. http://lwn.net/Articles/456978/

Иногда удивительно, как не замечают того, что копают под боком:
http://freesource.info/wiki/korinf

-- 
Lav
Виталий Липатов
Россия, Санкт-Петербург. www.etersoft.ru
GNU! ALT Linux Team! WINE! WIKI! LaTeX! LyX!

Re: [devel] Угрозы развитию дистрибутива. Пути решения.

[Denis Medvedev]

26 сентября 2011, 21:35 от Vitaly Lipatov <lav@altlinux.ru>:
> В сообщении от Воскресенье 25 сентября 2011 Michael Shigorin написал(a):
> > On Sun, Sep 25, 2011 at 10:34:21AM +0400, Hihin Ruslan wrote:
> > > При чём, ему желательно, что-бы на это затрачивалось меньше
> > > усилий. Поэтому он сопровождает те дистрибутивы, которые он
> > > считает важными.
> >
> > Это уже подумали в новелле -- и сделали Open Build Service.
> Пользовался?
Раскручено. Много кто про него знает в мире.
> 
> > > Если-бы в ALT Linux была-бы такая сборочная среда (робо),
> > > которая-бы из готового тарбола могла-бы создавать пакет для
> > > всех известных дистрибутивов (по заказу программиста), оставляя
> > > при этом пакет в том-же Сизифе, с низкой трудоёмкостью для
> > > этого программиста,
> >
> > IMHO не бывает; см. тж. http://lwn.net/Articles/456978/
> 
> Иногда удивительно, как не замечают того, что копают под боком:
> http://freesource.info/wiki/korinf
Хорошо, но в мире про это практически никто не знает. А для того, чтобы разработчики 1-го слоя (не сборщики дистрибутивов!) чем-то пользовались - это должно быть раскручено.

Re: [devel] Угрозы развитию дистрибутива. Пути решения.

[Michael Shigorin]

On Mon, Sep 26, 2011 at 09:33:51PM +0400, Vitaly Lipatov wrote:
> > > При чём, ему желательно, что-бы на это затрачивалось меньше
> > > усилий. Поэтому он сопровождает те дистрибутивы, которые он
> > > считает важными.
> > Это уже подумали в новелле -- и сделали Open Build Service.
> Пользовался?

Не-а.  Всё хочу на их образовыпекалку руки наложить.
А что там, вкратце? (пользовавшиеся в окрестности
вроде не ругались)

> > > Если-бы в ALT Linux была-бы такая сборочная среда (робо),
> > > которая-бы из готового тарбола могла-бы создавать пакет для
> > > всех известных дистрибутивов (по заказу программиста),
> > IMHO не бывает; см. тж. http://lwn.net/Articles/456978/
> Иногда удивительно, как не замечают того, что копают под боком:
> http://freesource.info/wiki/korinf

Про Коринф я знаю (хотя тоже не добрался развернуть),
но _исходным_ объектом там совсем не тарбол ведь.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] Угрозы развитию дистрибутива. Пути решения.

[Vitaly Lipatov]

 On Mon, 26 Sep 2011 22:30:12 +0300, Michael Shigorin wrote:
> On Mon, Sep 26, 2011 at 09:33:51PM +0400, Vitaly Lipatov wrote:
 ...
>> > Это уже подумали в новелле -- и сделали Open Build Service.
>> Пользовался?
>
> Не-а.  Всё хочу на их образовыпекалку руки наложить.
> А что там, вкратце? (пользовавшиеся в окрестности
 Я думал, ты расскажешь :)

 ...
>> > > Если-бы в ALT Linux была-бы такая сборочная среда (робо),
>> > > которая-бы из готового тарбола могла-бы создавать пакет для
>> > > всех известных дистрибутивов (по заказу программиста),
>> > IMHO не бывает; см. тж. http://lwn.net/Articles/456978/
>> Иногда удивительно, как не замечают того, что копают под боком:
>> http://freesource.info/wiki/korinf
>
> Про Коринф я знаю (хотя тоже не добрался развернуть),
> но _исходным_ объектом там совсем не тарбол ведь.
 Ну я думаю, что это бессмысленная задача — из произвольных
 тарболов пакеты собирать. Работать они явно не будут. Если только 
 разработчики в
 тарбол не будут специальный спек вкладывать.


-- 
 С уважением,
 Виталий Липатов,
 Etersoft

Re: [devel] Угрозы развитию дистрибутива. Пути решения.

[Paul Wolneykien]

09.10.2011 23:23, Vitaly Lipatov пишет:
> On Mon, 26 Sep 2011 22:30:12 +0300, Michael Shigorin wrote:
>> On Mon, Sep 26, 2011 at 09:33:51PM +0400, Vitaly Lipatov wrote:
> ...
>>> > Это уже подумали в новелле -- и сделали Open Build Service.
>>> Пользовался?
>>
>> Не-а. Всё хочу на их образовыпекалку руки наложить.
>> А что там, вкратце? (пользовавшиеся в окрестности
> Я думал, ты расскажешь :)

   Интересно, а скольким людям у нас было бы интересна интеграция с OBS? 
Я это к тому, что этим можно заняться, товарищи из SuSE обещали помочь, 
но нужна инициативная группа с нашей стороны.

>
> ...
>>> > > Если-бы в ALT Linux была-бы такая сборочная среда (робо),
>>> > > которая-бы из готового тарбола могла-бы создавать пакет для
>>> > > всех известных дистрибутивов (по заказу программиста),
>>> > IMHO не бывает; см. тж. http://lwn.net/Articles/456978/
>>> Иногда удивительно, как не замечают того, что копают под боком:
>>> http://freesource.info/wiki/korinf
>>
>> Про Коринф я знаю (хотя тоже не добрался развернуть),
>> но _исходным_ объектом там совсем не тарбол ведь.
> Ну я думаю, что это бессмысленная задача — из произвольных
> тарболов пакеты собирать. Работать они явно не будут. Если только
> разработчики в
> тарбол не будут специальный спек вкладывать.
>
>

Re: [devel] интеграция с OBS

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 869 bytes --]

On Sun, Oct 09, 2011 at 11:32:07PM +0400, Paul Wolneykien wrote:
> 09.10.2011 23:23, Vitaly Lipatov пишет:
> >On Mon, 26 Sep 2011 22:30:12 +0300, Michael Shigorin wrote:
> >>On Mon, Sep 26, 2011 at 09:33:51PM +0400, Vitaly Lipatov wrote:
> >...
> >>>> Это уже подумали в новелле -- и сделали 
> >>>Open Build Service.
> >>>Пользовался?
> >>
> >>Не-а. Всё хочу на их образовыпекалку 
> >>руки наложить.
> >>А что там, вкратце? (пользовавшиеся в 
> >>окрестности
> >Я думал, ты расскажешь :)
> 
>   Интересно, а скольким людям у нас было 
>   бы интересна интеграция с OBS?

Расскажите, пожалуйста, подробнее, какой смысл вкладывается в это
выражение "интеграция с OBS".  Что это означает на практике?

> Я это к тому, 
> что этим можно заняться, товарищи из SuSE 
> обещали помочь, но нужна инициативная 
> группа с нашей стороны.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] интеграция с OBS

[Paul Wolneykien]

10.10.2011 00:15, Dmitry V. Levin пишет:
> On Sun, Oct 09, 2011 at 11:32:07PM +0400, Paul Wolneykien wrote:
>> 09.10.2011 23:23, Vitaly Lipatov пишет:
>>> On Mon, 26 Sep 2011 22:30:12 +0300, Michael Shigorin wrote:
>>>> On Mon, Sep 26, 2011 at 09:33:51PM +0400, Vitaly Lipatov wrote:
>>> ...
>>>>>> Это уже подумали в новелле -- и сделали
>>>>> Open Build Service.
>>>>> Пользовался?
>>>>
>>>> Не-а. Всё хочу на их образовыпекалку
>>>> руки наложить.
>>>> А что там, вкратце? (пользовавшиеся в
>>>> окрестности
>>> Я думал, ты расскажешь :)
>>
>>    Интересно, а скольким людям у нас было
>>    бы интересна интеграция с OBS?
>
> Расскажите, пожалуйста, подробнее, какой смысл вкладывается в это
> выражение "интеграция с OBS".  Что это означает на практике?

   Товарищи из openSuSE говорили, что готовы помочь с тем, чтобы «OBS 
собирал пакеты и для ALT Linux тоже, ALT Linux появился в списке 
поддерживаемых платформ». Думаю, что последнее — немаловажно, хотя бы 
для рекламы.
   Мы можем предложить что-то своё. Например, можем ограничиться тем, 
чтобы от OBS приходили только спеки, а собирать пакеты по прежнему в 
girar-builder.
   Насколько я понимаю, их система сборки не только отдельные пакеты 
собирает, но и целые дистрибутивы. Собранный дистрибутив можно удалённо 
запустить и проверить, как визуально, так и по SSH. Есть регулярные 
сборки, скоро будет автотестирование (OpenQA). Короче, там много чего 
интересного, но нужно разбираться. Я знаю совсем немного — то, что 
почерпнул из разговоров, плюс то, что что было в презентации.
   А для того, чтобы начать разбираться, нужна инициативная группа. :)

>
>> Я это к тому,
>> что этим можно заняться, товарищи из SuSE
>> обещали помочь, но нужна инициативная
>> группа с нашей стороны.
>
>
>
>
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

Re: [devel] интеграция с OBS

[Paul Wolneykien]

10.10.2011 00:24, Paul Wolneykien пишет:
> 10.10.2011 00:15, Dmitry V. Levin пишет:
>> On Sun, Oct 09, 2011 at 11:32:07PM +0400, Paul Wolneykien wrote:
>>> 09.10.2011 23:23, Vitaly Lipatov пишет:
>>>> On Mon, 26 Sep 2011 22:30:12 +0300, Michael Shigorin wrote:
>>>>> On Mon, Sep 26, 2011 at 09:33:51PM +0400, Vitaly Lipatov wrote:
>>>> ...
>>>>>>> Это уже подумали в новелле -- и сделали
>>>>>> Open Build Service.
>>>>>> Пользовался?
>>>>>
>>>>> Не-а. Всё хочу на их образовыпекалку
>>>>> руки наложить.
>>>>> А что там, вкратце? (пользовавшиеся в
>>>>> окрестности
>>>> Я думал, ты расскажешь :)
>>>
>>> Интересно, а скольким людям у нас было
>>> бы интересна интеграция с OBS?
>>
>> Расскажите, пожалуйста, подробнее, какой смысл вкладывается в это
>> выражение "интеграция с OBS". Что это означает на практике?
>
> Товарищи из openSuSE говорили, что готовы помочь с тем, чтобы «OBS
> собирал пакеты и для ALT Linux тоже, ALT Linux появился в списке
> поддерживаемых платформ». Думаю, что последнее — немаловажно, хотя бы
> для рекламы.
> Мы можем предложить что-то своё. Например, можем ограничиться тем, чтобы
> от OBS приходили только спеки, а собирать пакеты по прежнему в
> girar-builder.
> Насколько я понимаю, их система сборки не только отдельные пакеты
> собирает, но и целые дистрибутивы. Собранный дистрибутив можно удалённо
> запустить и проверить, как визуально, так и по SSH. Есть регулярные
> сборки, скоро будет автотестирование (OpenQA). Короче, там много чего
> интересного, но нужно разбираться. Я знаю совсем немного — то, что
> почерпнул из разговоров, плюс то, что что было в презентации.

   Презентация:

 
http://openmind.fi/sites/default/files/sponsor-introduction-to-suse-studio-openmind2011.pdf

> А для того, чтобы начать разбираться, нужна инициативная группа. :)
>
>>
>>> Я это к тому,
>>> что этим можно заняться, товарищи из SuSE
>>> обещали помочь, но нужна инициативная
>>> группа с нашей стороны.
>>
>>
>>
>>
>> _______________________________________________
>> Devel mailing list
>> Devel@lists.altlinux.org
>> https://lists.altlinux.org/mailman/listinfo/devel
>
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

Re: [devel] интеграция с OBS

[Michael Shigorin]

On Mon, Oct 10, 2011 at 12:24:48AM +0400, Paul Wolneykien wrote:
> А для того, чтобы начать разбираться, нужна инициативная группа. :)

Нуу в принципе интересно, скорее по околодистрибутивной части.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] интеграция с OBS

[Радик Юсупов]

10.10.2011 00:24, Paul Wolneykien пишет:
>
>   Товарищи из openSuSE говорили, что готовы помочь с тем, чтобы «OBS 
> собирал пакеты и для ALT Linux тоже, ALT Linux появился в списке 
> поддерживаемых платформ». Думаю, что последнее — немаловажно, хотя бы 
> для рекламы.
>   Мы можем предложить что-то своё. Например, можем ограничиться тем, 
> чтобы от OBS приходили только спеки, а собирать пакеты по прежнему в 
> girar-builder.
>   Насколько я понимаю, их система сборки не только отдельные пакеты 
> собирает, но и целые дистрибутивы. Собранный дистрибутив можно 
> удалённо запустить и проверить, как визуально, так и по SSH. Есть 
> регулярные сборки, скоро будет автотестирование (OpenQA). Короче, там 
> много чего интересного, но нужно разбираться. Я знаю совсем немного — 
> то, что почерпнул из разговоров, плюс то, что что было в презентации.
>   А для того, чтобы начать разбираться, нужна инициативная группа. :) 
Я бы с удовольствием принял участие в подобной инициативе в силу своих 
возможностей.
Нужно учесть, что я ни разу не кодер.

-- 
ALTLinux Team
My project: http://lxdesktop.altlinux.org

Re: [devel] интеграция с OBS

[Paul Wolneykien]

14.10.2011 21:36, Радик Юсупов пишет:
> 10.10.2011 00:24, Paul Wolneykien пишет:
>>
>>   Товарищи из openSuSE говорили, что готовы помочь с тем, чтобы «OBS
>> собирал пакеты и для ALT Linux тоже, ALT Linux появился в списке
>> поддерживаемых платформ». Думаю, что последнее — немаловажно, хотя бы
>> для рекламы.
>>   Мы можем предложить что-то своё. Например, можем ограничиться тем,
>> чтобы от OBS приходили только спеки, а собирать пакеты по прежнему в
>> girar-builder.
>>   Насколько я понимаю, их система сборки не только отдельные пакеты
>> собирает, но и целые дистрибутивы. Собранный дистрибутив можно
>> удалённо запустить и проверить, как визуально, так и по SSH. Есть
>> регулярные сборки, скоро будет автотестирование (OpenQA). Короче, там
>> много чего интересного, но нужно разбираться. Я знаю совсем немного —
>> то, что почерпнул из разговоров, плюс то, что что было в презентации.
>>   А для того, чтобы начать разбираться, нужна инициативная группа. :) 
> Я бы с удовольствием принял участие в подобной инициативе в силу своих
> возможностей.
> Нужно учесть, что я ни разу не кодер.

  ОК, кворум, вроде бы, есть. Начинаю писать письмо турецкому султану.

> 

Re: [devel] интеграция с OBS

[Paul Wolneykien]

15.10.2011 21:10, Paul Wolneykien пишет:
> 14.10.2011 21:36, Радик Юсупов пишет:
>> 10.10.2011 00:24, Paul Wolneykien пишет:
>>>
>>>   Товарищи из openSuSE говорили, что готовы помочь с тем, чтобы «OBS
>>> собирал пакеты и для ALT Linux тоже, ALT Linux появился в списке
>>> поддерживаемых платформ». Думаю, что последнее — немаловажно, хотя бы
>>> для рекламы.
>>>   Мы можем предложить что-то своё. Например, можем ограничиться тем,
>>> чтобы от OBS приходили только спеки, а собирать пакеты по прежнему в
>>> girar-builder.
>>>   Насколько я понимаю, их система сборки не только отдельные пакеты
>>> собирает, но и целые дистрибутивы. Собранный дистрибутив можно
>>> удалённо запустить и проверить, как визуально, так и по SSH. Есть
>>> регулярные сборки, скоро будет автотестирование (OpenQA). Короче, там
>>> много чего интересного, но нужно разбираться. Я знаю совсем немного —
>>> то, что почерпнул из разговоров, плюс то, что что было в презентации.
>>>   А для того, чтобы начать разбираться, нужна инициативная группа. :) 
>> Я бы с удовольствием принял участие в подобной инициативе в силу своих
>> возможностей.
>> Нужно учесть, что я ни разу не кодер.
> 
>   ОК, кворум, вроде бы, есть. Начинаю писать письмо турецкому султану.

  В ответ на мой вопрос «а как бы нам добавить поддержку Альт в OBS?»
Jos мне прислал несколько ссылок публичные документы, посоветовав
поставить OBS у себя и посмотреть всё на практике:

http://en.opensuse.org/openSUSE:Build_Service_adding_build_targets
http://en.opensuse.org/openSUSE:Build_Service_Appliance
http://en.opensuse.org/openSUSE:Build_Service_Installation_Tutorial
http://en.opensuse.org/Portal:Build_Service/Development

  Наиболее интересна, думаю, последняя.

  С дальнейшими вопросами посоветовал обратиться в список рассылки
«opensuse-buildservice»

http://lists.opensuse.org/opensuse-buildservice ,

  либо непосредственно к ведущему разработчику OBS.

  Думаю, что первый и главный вопрос, который стоит задать, это вопрос о
том, как преобразовываются пакеты между дистрибутивами. Информацию о
том, какой компонент за это отвечает, я так и не нашёл среди приведённых
выше ссылок. Однако на конференции ясно было сказано: сборка пакета для
любого дистрибутива, входящего в перечень OBS — это новый пакет для
SuSE. Собственно для этого они OBS и придумали. :) А раз так, то где-то
преобразователь должен быть, пусть даже и односторонний.

  Так что попробую узнать ответ на этот вопрос.


    Паша.

Re: [devel] интеграция с OBS

[Igor Vlasenko]

On Mon, Nov 14, 2011 at 11:30:22PM +0400, Paul Wolneykien wrote:
>   Думаю, что первый и главный вопрос, который стоит задать, это вопрос о
> том, как преобразовываются пакеты между дистрибутивами. 

Они вроде бы как не преобразовуют:
http://en.opensuse.org/openSUSE:Build_Service_cross_distribution_howto

OBS - это инструмент наподобие hasher, или скорее Corinf over hasher.
IMHO.

> А раз так, то где-то
> преобразователь должен быть, пусть даже и односторонний.

Сомневаюсь. Я когда начал писать преобразователи, интересовался темой.
Такое впечатление, что вместо преобразователей цепляются за
"портабельный rpm".
А мы уже слишком мутировали от динозавров.

> Однако на конференции ясно было сказано: сборка пакета для
> любого дистрибутива, входящего в перечень OBS ??? это новый пакет для
> SuSE. Собственно для этого они OBS и придумали. :) 

Важный шаг в эволюции растений^Wдистрибутивов.
Раньше они разбрасывали пыльцу на ветер, а теперь дополнительно опыляются 
тем, что приманивают пчел на мед^W^W^Wразработчиков на сервисы.

И нам надо. 
Только нужны более серьезные инструменты, чем с шашкой на танк.

Начиная с
http://www.altlinux.org/Packaging_Automation/DistroMap
"База данных DISTROMAP предназначена для трансляции пространств имен 
между дистрибутивами. DISTROMAP включает в себя собственно базы данных, 
утилиты генерации и сопровождения баз данных, shell интерфейс и perl интерфейс. Для удобства расширения и сопровождения база данных сделана модульной."

-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: [devel] интеграция с OBS

[Michael Shigorin]

On Tue, Nov 15, 2011 at 12:40:38AM +0200, Igor Vlasenko wrote:
> И нам надо.  Только нужны более серьезные инструменты,
> чем с шашкой на танк.

BTW если есть кто желающий поэкспериментировать с веб-мордой
для mkimage-profiles (написав её по дороге), буду сильно
признателен -- у меня пока скорее "низы" в задачках по ним,
но чего для простенького варианта не хватает -- думаю,
к концу месяца можно и добить (возможности задать произвольные
пакеты вдобавок к заданному базовому дистрибутиву из списка,
который получить просто).

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] Угрозы развитию дистрибутива. Пути решения.

[Denis Medvedev]

09 октября 2011, 23:32 от Paul Wolneykien <manowar@altlinux.org>:
> 09.10.2011 23:23, Vitaly Lipatov пишет:
> > On Mon, 26 Sep 2011 22:30:12 +0300, Michael Shigorin wrote:
> >> On Mon, Sep 26, 2011 at 09:33:51PM +0400, Vitaly Lipatov wrote:
> > ...
> >>> > Это уже подумали в новелле -- и сделали Open Build Service.
> >>> Пользовался?
> >>
> >> Не-а. Всё хочу на их образовыпекалку руки наложить.
> >> А что там, вкратце? (пользовавшиеся в окрестности
> > Я думал, ты расскажешь :)
> 
>    Интересно, а скольким людям у нас было бы интересна интеграция с OBS?
> Я это к тому, что этим можно заняться, товарищи из SuSE обещали помочь,
> но нужна инициативная группа с нашей стороны.
Интересно, но времени мало. Хотел бы поучаствовать все равно.
> 
> >
> > ...
> >>> > > Если-бы в ALT Linux была-бы такая сборочная среда (робо),
> >>> > > которая-бы из готового тарбола могла-бы создавать пакет для
> >>> > > всех известных дистрибутивов (по заказу программиста),
> >>> > IMHO не бывает; см. тж. http://lwn.net/Articles/456978/
> >>> Иногда удивительно, как не замечают того, что копают под боком:
> >>> http://freesource.info/wiki/korinf
> >>
> >> Про Коринф я знаю (хотя тоже не добрался развернуть),
> >> но _исходным_ объектом там совсем не тарбол ведь.
> > Ну я думаю, что это бессмысленная задача — из произвольных
> > тарболов пакеты собирать. Работать они явно не будут. Если только
> > разработчики в
> > тарбол не будут специальный спек вкладывать.
> >
> >
> 
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

Re: [devel] Угрозы развитию дистрибутива. Пути решения.

[Denis Medvedev]

09 октября 2011, 23:32 от Paul Wolneykien <manowar@altlinux.org>:
> 09.10.2011 23:23, Vitaly Lipatov пишет:
> > On Mon, 26 Sep 2011 22:30:12 +0300, Michael Shigorin wrote:
> >> On Mon, Sep 26, 2011 at 09:33:51PM +0400, Vitaly Lipatov wrote:
> > ...
> >>> > Это уже подумали в новелле -- и сделали Open Build Service.
> >>> Пользовался?
> >>
> >> Не-а. Всё хочу на их образовыпекалку руки наложить.
> >> А что там, вкратце? (пользовавшиеся в окрестности
> > Я думал, ты расскажешь :)
> 
>    Интересно, а скольким людям у нас было бы интересна интеграция с OBS?
> Я это к тому, что этим можно заняться, товарищи из SuSE обещали помочь,
> но нужна инициативная группа с нашей стороны.
Интересно, но времени мало. Хотел бы поучаствовать все равно.
> 
> >
> > ...
> >>> > > Если-бы в ALT Linux была-бы такая сборочная среда (робо),
> >>> > > которая-бы из готового тарбола могла-бы создавать пакет для
> >>> > > всех известных дистрибутивов (по заказу программиста),
> >>> > IMHO не бывает; см. тж. http://lwn.net/Articles/456978/
> >>> Иногда удивительно, как не замечают того, что копают под боком:
> >>> http://freesource.info/wiki/korinf
> >>
> >> Про Коринф я знаю (хотя тоже не добрался развернуть),
> >> но _исходным_ объектом там совсем не тарбол ведь.
> > Ну я думаю, что это бессмысленная задача — из произвольных
> > тарболов пакеты собирать. Работать они явно не будут. Если только
> > разработчики в
> > тарбол не будут специальный спек вкладывать.
> >
> >
> 
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

Re: [devel] Угрозы развитию дистрибутива. Пути решения.

[Igor Vlasenko]

On Sun, Sep 25, 2011 at 10:34:21AM +0400, Hihin Ruslan wrote:
> Т.е. моя мысль заключается в том, что надо снижать барьер 
> вхождения в мантейнеры для разработчиков приложений, 

Это нужно, и это сложно.
Начинать надо с документации, ее явно мало...

> и дать 
> возможность получать пакеты не только для ALT Linux, но и для 
> других дистрибутвов (экономя время разработчику приложений).

Это есть, Corinf oт Евгения Синельникова (sin@)


-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: [devel] Угрозы развитию дистрибутива. Пути решения.

[Hihin Ruslan]

[-- Attachment #1: Type: text/plain, Size: 3920 bytes --]

Здравствуйте Igor Vlasenko
  В сообщении от 26 сентября 2011 Igor Vlasenko написал(a):
> > Т.е. моя мысль заключается в том, что надо снижать барьер
> > вхождения в мантейнеры для разработчиков приложений,
>
> Это нужно, и это сложно.
> Начинать надо с документации, ее явно мало...

Сделал заметку для себя :) Тем более, что память меня часто 
подводит, но постепенно я до постигаю скилы gear - girar.

> > и дать
> > возможность получать пакеты не только для ALT Linux, но и
> > для других дистрибутвов (экономя время разработчику
> > приложений).
>
> Это есть, Corinf oт Евгения Синельникова (sin@)
 Если это так, то это  стоит развернуть в Систему и 
пропагандировать, как одно из преимуществ ALT Linux. Наверное и 
тут роботы потребуются.

В общем-то я с вашей статьёй согласен, что роботы нужны, 
просто хотел добавить, что так-как роботами управлют люди, то 
основной аспект заключается в том, что-бы людям, пользующимися 
этими роботами  (сборочной средой ALT Linux) было комфортно.

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

Ну и конечно, не надо забывать про то, что сказал Миша Шигорин:
>Для этого надо их беречь и слушать, с этим порой проблемы.
>Не косить всех под одну гребёнку (опытных и новичков,
>сишников и админов).  Сам знаешь, связки уж надорвал :)

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


-- 
  А ещё говорят так  (fortune):
 
What makes you think graduate school is supposed to be 
satisfying? -- Erica Jong, "Fear of Flying" 
________________________________________________________________________
С уважением Хихин Руслан

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] Угрозы развитию дистрибутива. Пути решения.

[REAL]

26.09.2011 11:17, Hihin Ruslan пишет:
> В общем-то я с вашей статьёй согласен, что роботы нужны,
> просто хотел добавить, что так-как роботами управлют люди, то
> основной аспект заключается в том, что-бы людям, пользующимися
> этими роботами  (сборочной средой ALT Linux) было комфортно.

Насчёт комфортности - в десяточку. Мне, например, совсем не улыбается 
пользоваться cronbuild, поскольку руками обновлять как-то проще.

>   Но, к сожалению, такое бережное отношение к членам команды
> даётся только с определённым жизненным опытом .... и он не
> всегда зависит от возроста, но часто зависит от воспитания и
> самодисциплины.

Да. И очень жаль, что многие ушли именно и-за отсутствия у них 
воспитания и самодисциплины. Но мы ж не педагоги...

-- 

REAL aka Евгений Ростовцев, программист ЦНИТ КемГУ

Re: [devel] Угрозы развитию дистрибутива. Пути решения.

[Boris Savelev]

>> и дать
>> возможность получать пакеты не только для ALT Linux, но и для
>> других дистрибутвов (экономя время разработчику приложений).
>
> Это есть, Corinf oт Евгения Синельникова (sin@)

когда я работал в etersoft, это был Korinf от Виталия Липатова (lav@)

 %)

-- 
Boris

Re: [devel] Угрозы развитию дистрибутива. Пути решения.

[Michael Shigorin]

On Sun, Sep 25, 2011 at 01:35:21AM +0300, Igor Vlasenko wrote:
> Необходимость вносить изменения вновь и вновь может оказаться
> слишком дорогой платой за совместимость.

BTW можно состыковать с
http://fly.osdn.org.ua/~mike/docs/lvee/lvee2011-shigorin-fork_merge.pdf
(я обдумываю модификацию этого доклада в сторону дистрибутивов
по мотивам "дефоркизации" в рамках mkimage-profiles.git)

> Но почему это так?  и почему упаковщики пакетов дублируют
> усилия друг друга? 

---
These days the only anwer that remains to be tried is
	Fork every distro on the planet and "fix" the packaging.

Seriously: I don't know what to do with "No time" and *shrug* answers
from package monkeys and distro vendors and "standards" organizations
that refuse to change.
--- http://permalink.gmane.org/gmane.comp.package-management.rpm.devel/4752

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

На эту тему стоит пообщаться (и состыковаться) с Русланом Шевченко:
http://www.foss-sea.org.ua/programma/doklady-i-dokladchiki/analiz-koda-pochemu-ehto-interesno-i-kogda-ehto-nuzhno/
(он рассказывал в т.ч. про автоматическое переписывание кода,
а также как раз адаптирует доклад для киевской конференции --
там будет ещё минимум два доклада на перекликающуюся тематику)

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] Угрозы развитию дистрибутива. Пути решения.

[Vitaly Kuznetsov]

On Sun, 25 Sep 2011 01:35:21 +0300, Igor Vlasenko wrote:
> Уважаемые коллеги,
>
> хочу поделиться в devel@ своим проектом
> доклада на OSDN-2011 в Киеве, так как тема касается проблем
> развития дистрибутива, и, думаю, будет всем интересна.
> Прошу читать и комментировать.
>
Just IMHO.

Мне кажется, что проблема Сизифа состоит не в том, что у нас 120 
пакетов/ майнтейнера, и ему сложно следить за выходом новых версий, 
обновлять spec, искать патчи в других дистрибутивах. Мейнтейнер, который 
не знает о том, что вышла новая версия поддерживаемого им пакета - это 
не мейнтейнер, а роботоподобный сборщик пакетов. Он не читает даже 
списка софтина-announce, не говоря уж о софтина-devel и софтина-users. 
Ценность его работы заключается только в том, что пользователь, 
захотевший использовать софтину не сбежит сразу на другой дистрибутив. 
Возможно, он это сделает в тот момент, когда попробует использовать этот 
софт. Дабы никого не обижать, приведу примеры из поддерживаемых (по воле 
случая) в таком виде мною пакетов:
samba
squid
MySQL
openldap
...
В этом смысле импорт пакетов из федоры не сильно лучше/хуже.

Проблема Сизифа заключается в том, что у нас крайне мало реально 
поддерживаемых подсистем. Таких, где люди хорошо разбираются в коде, 
могут предоставить поддержку пользователю, общаются с апстримом, знают 
состояние дел и направление развития проектов, готовы принимать и 
обрабатывать баги. Чрезмерная роботизация нарушает основопологающий 
принцип "тебе надо - ты и делай". Роботу ничего не надо, качество 
результата его волнует не более, чем прогноз погоды на Марсе. И, что 
самое главное, ему не стыдно перед пользователями.

Мне кажется, что наша (Team) цель состоит не в том, чтобы завтра у 
среднего мейнтейнера было 500 поддерживаемых в роботизированном режиме 
пакетов, а в том, чтоб
было больше майнтейнеров у которых пусть 1-2 пакета, но которые им 
реально поддерживаются. Тогда повысится число людей, которые будут 
пользоваться решениями на основе Сизифа "Потому, что у них Вася 
мейнтейнит 'Софтину'. А Вася - известный апстрим-разработчик, ему можно 
и баг отрепортить, и совета от него в рассылке получить". Для этого 
нужно пропагандировать не использование роботизации, позволяющее 
новопришедшему мейнтейнеру собрать несколько сотен пакетов за полдня, а 
максимальное погружение в тему, участие в делах апстрима.

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

Re: [devel] Угрозы развитию дистрибутива. Пути решения.

[Michael Shigorin]

On Sun, Sep 25, 2011 at 11:47:40PM +0400, Vitaly Kuznetsov wrote:
> Мне кажется, что наша (Team) цель состоит не в том, чтобы
> завтра у среднего мейнтейнера было 500 поддерживаемых в
> роботизированном режиме пакетов, а в том, чтоб было больше
> майнтейнеров у которых пусть 1-2 пакета, но которые им реально
> поддерживаются.

Для этого надо их беречь и слушать, с этим порой проблемы.
Не косить всех под одну гребёнку (опытных и новичков,
сишников и админов).  Сам знаешь, связки уж надорвал :)

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

PS: а ещё хорошо бы собраться с силами, посмотреть на
использование git для сборки пакетов в Fedora/Debian,
отметить различия в разумную сторону и по возможности
адаптировать (например, у нас до сих пор много "диких"
gear-репозиториев, в то время как опыта поддержки за
пять лет накопилось будто бы достаточно для выделения
общих случаев и подпирания их инструментарием). И это
тоже отдельная тема, хотя и про автоматизацию рутины 
со снижением шанса глупых ошибок...

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] Угрозы развитию дистрибутива. Пути решения.

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 4136 bytes --]

On Sun, Sep 25, 2011 at 11:47:40PM +0400, Vitaly Kuznetsov wrote:

VK> Мне кажется, что проблема Сизифа состоит не в том, что у нас 120 
VK> пакетов/ майнтейнера, и ему сложно следить за выходом новых версий, 
VK> обновлять spec, искать патчи в других дистрибутивах. Мейнтейнер, который 
VK> не знает о том, что вышла новая версия поддерживаемого им пакета - это 
VK> не мейнтейнер, а роботоподобный сборщик пакетов. 

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

Например cronbuild позволяет работу, которуя тривиальна и у меня требует
15-30 минут в неделю делать за... 0. Итого 1ч жизни.

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

VK> В этом смысле импорт пакетов из федоры не сильно лучше/хуже.

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

Очень грустно, конечно, что у нас есть объективная необходимость
импортировать так ключевые пакеты. Но очевидно, что скажем игрушки всякие
в дистрибутиве тоже нужны, а тратить время на их красивую правильную
ручную сборку -- откровенно жалко. И роботы тут справятся объективно
лучше, с учетом соотношения затраты сил/результат.

VK> Проблема Сизифа заключается в том, что у нас крайне мало реально 
VK> поддерживаемых подсистем. Таких, где люди хорошо разбираются в коде, 
VK> могут предоставить поддержку пользователю, общаются с апстримом, знают 
VK> состояние дел и направление развития проектов, готовы принимать и 
VK> обрабатывать баги. Чрезмерная роботизация нарушает основопологающий 
VK> принцип "тебе надо - ты и делай". Роботу ничего не надо, качество 
VK> результата его волнует не более, чем прогноз погоды на Марсе. И, что 
VK> самое главное, ему не стыдно перед пользователями.

Роботизация позволяет разоврвать замкнутый круг типа "вот этого пакета
здесь нет, этого нет и этого нет, а этот не обновлялся 10 лет -- поэтому я
уйду на Ubuntu и буду мантейнить свой любимый пакет там".

VK> Мне кажется, что наша (Team) цель состоит не в том, чтобы завтра у 
VK> среднего мейнтейнера было 500 поддерживаемых в роботизированном режиме 
VK> пакетов, а в том, чтоб
VK> было больше майнтейнеров у которых пусть 1-2 пакета, но которые им 
VK> реально поддерживаются. Тогда повысится число людей, которые будут 
VK> пользоваться решениями на основе Сизифа "Потому, что у них Вася 
VK> мейнтейнит 'Софтину'. А Вася - известный апстрим-разработчик, ему можно 
VK> и баг отрепортить, и совета от него в рассылке получить". Для этого 
VK> нужно пропагандировать не использование роботизации, позволяющее 
VK> новопришедшему мейнтейнеру собрать несколько сотен пакетов за полдня, а 
VK> максимальное погружение в тему, участие в делах апстрима.
VK> Хотя возможно, что людей настолько мало, что предлагаемый мною подход 
VK> не даст критической массы софта, а мейнтейнеры, реально занимающиеся 
VK> делом будут незаметны на фоне тысяч пакетов, перепакованных из федоры.

Дело не в том что людей мало, дело в том что отток активных мантейнеров
превышает приток.

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

У мантейнера может не быть времени нормально сопровождать пакет. Но может
быть время проконтролировать робота :)

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

Причем у них как раз часто времени и нет на конкретно поддержку в Сизифе
(см. samba, или пляски вокруг bind).

-- 
С уважением, Денис

http://mithraen.ru/
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] Угрозы развитию дистрибутива. Пути решения.

[Ildar Mulyukov]

On 26.09.2011 11:16:38, Денис Смирнов wrote:
> Кроме того -- роботы это хорошо, если за ними присматривать. То есть  
> робот
> обновляет пакет, а мантейнер потом смотрит что за фигню сделал робот,  
> и
> поправляет если надо. Это экономит время на тупом ручном труде.
> 
> У мантейнера может не быть времени нормально сопровождать пакет. Но  
> может
> быть время проконтролировать робота :)

Если позволите, это работа не мэйнтейнера, а QA. И если это учесть, то  
картина может быть совсем иной...
-- 
Ildar Mulyukov,
   free SW designer/programmer/packager
=========================================
email: ildar@altlinux.ru
Jabber: ildar.mulyukov@gmail.com
ICQ: 4334029
ALT Linux Sisyphus http://www.sisyphus.ru
=========================================

Re: [devel] Угрозы развитию дистрибутива. Пути решения.

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 1049 bytes --]

On Mon, Sep 26, 2011 at 04:47:42PM +0600, Ildar Mulyukov wrote:

>> У мантейнера может не быть времени нормально сопровождать пакет. Но  
>> может быть время проконтролировать робота :)
IM> Если позволите, это работа не мэйнтейнера, а QA. И если это учесть, то  
IM> картина может быть совсем иной...

Это так в случае, если все мантейнеры и QA являются сотрудниками одной
организации и действуют согласно соответствующим инструкциям.

В реальности же ситуация совсем другая -- каждый человек делает для своих
пакетов то, что ему надо. И для распределенной разработки just for fun,
или "исключительно ради производственной необходимости в своих проектах"
работают совсем другие правила.

Это может быть решено, если QA будет работать одной командой. Но брать на
себя функции QA на общественных началах желающих мало.

А вот приглядеть за роботом, который собирает _мой_ пакет -- вполне себе
возможно.

-- 
С уважением, Денис

http://mithraen.ru/
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] Угрозы развитию дистрибутива. Пути решения.

[Мал Скрылёв]

26 сентября 2011 г. 9:16 пользователь Денис Смирнов
<mithraen@freesource.info> написал:
> On Sun, Sep 25, 2011 at 11:47:40PM +0400, Vitaly Kuznetsov wrote:
>
> Кроме того -- роботы это хорошо, если за ними присматривать. То есть робот
> обновляет пакет, а мантейнер потом смотрит что за фигню сделал робот, и
> поправляет если надо. Это экономит время на тупом ручном труде.
>
> У мантейнера может не быть времени нормально сопровождать пакет. Но может
> быть время проконтролировать робота :)
>

Немного конкретики о самодейном обновлении пакета, если позволите сюда.
Собственно нужно два скрипта (напр, башевских ну или каких иных,
требования можно в том же спеке описать) getver и getdata. Первый
будет получать правильную последнюю версию пакета, а второй, если
версия новая там есть уже, собственно, получать пакет и
преобразовывать его в нужный вид (архивировать или наборот, и
выцапытвать только то, что нужно от него).
Поместить их можно, например, в папку .gear: .gear/getver, .gear/getdata


26 сентября 2011 г. 19:50 пользователь Paul Wolneykien
<manowar@altlinux.org> написал:
> 26.09.2011 19:38, Michael Shigorin пишет:
>  Наши пакеты содержат много автоматически вычисляемых метаданных и
> потенциально могут служить хорошим источником для изготовления пакета для
> любого другого дистрибутива. Поэтому я считаю, что лучше не нам идти в
> другой build service, а напротив, реализовать его у себя для других.

Да, правильно, е всё пользоваться "их" разработками.


27 сентября 2011 г. 15:42 пользователь Igor Vlasenko
<vlasenko@imath.kiev.ua> написал:
> On Mon, Sep 26, 2011 at 06:36:01PM +0400, Denis  Medvedev wrote:
>> Гораздо лучше было бы, если бы сами разработчики софта (1-st tier) могли бы просто генерировать пакеты для ALT вкупе с пакетами для других дистрибутивов. Кто бы добавил ALT в список дистрибутивов, поддерживаемых http://en.wikipedia.org/wiki/Open_Build_Service ?!
>
> Тарбол чем не coвceм удобен, что из него непонятно как брать
> Summary, Description.

Ну в слаке же как-то берут эту информацию?

-- 
Малъ Зануда, Скрылёвъ сынъ

Re: [devel] Угрозы развитию дистрибутива. Пути решения.

[Igor Vlasenko]

On Thu, Sep 29, 2011 at 11:29:49AM +0400, Мал Скрылёв wrote:
> Немного конкретики о самодейном обновлении пакета, если позволите сюда.
> Собственно нужно два скрипта (напр, башевских ну или каких иных,
> требования можно в том же спеке описать) getver и getdata. Первый
> будет получать правильную последнюю версию пакета, а второй, если
> версия новая там есть уже, собственно, получать пакет и
> преобразовывать его в нужный вид (архивировать или наборот, и
> выцапытвать только то, что нужно от него).
> Поместить их можно, например, в папку .gear: .gear/getver, .gear/getdata

таким образом действует cronbuild,
можно поставить gear-cronbuild и поиграть с ним.
документация по cronbuild на wiki.


-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: [devel] Угрозы развитию дистрибутива. Пути решения.

[Мал Скрылёв]

29 сентября 2011 г. 13:55 пользователь Igor Vlasenko
<vlasenko@imath.kiev.ua> написал:
> On Thu, Sep 29, 2011 at 11:29:49AM +0400, Мал Скрылёв wrote:
>> Немного конкретики о самодейном обновлении пакета, если позволите сюда.
>> Собственно нужно два скрипта (напр, башевских ну или каких иных,
>> требования можно в том же спеке описать) getver и getdata. Первый
>> будет получать правильную последнюю версию пакета, а второй, если
>> версия новая там есть уже, собственно, получать пакет и
>> преобразовывать его в нужный вид (архивировать или наборот, и
>> выцапытвать только то, что нужно от него).
>> Поместить их можно, например, в папку .gear: .gear/getver, .gear/getdata
>
> таким образом действует cronbuild,
> можно поставить gear-cronbuild и поиграть с ним.
> документация по cronbuild на wiki.

Я имел ввиду, что процедура обновления для некоторых сайтов подобна,
напр. для googlecode, github, sourceforge. т.е. тут просто нужен один
скрипт системный, а в настройках .gear/rules просто указать вид (там:
gc, gh, sf ли полностью).
А если не стандартно, то с использованием некоей общей процедуры, с
вызовом скриптов получения версий и пакета. А сейчас, я так уразумел
что, есть только один скрипт, который предоставляется или нет в самом
пакете. т.е. только 1 вид его и поедствлен.

-- 
Малъ Зануда, Скрылёвъ сынъ

Re: [devel] Угрозы развитию дистрибутива. Пути решения.

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 645 bytes --]

On Sat, Oct 01, 2011 at 09:53:09AM +0400, Мал Скрылёв wrote:

> Я имел ввиду, что процедура обновления для некоторых сайтов подобна,
> напр. для googlecode, github, sourceforge. т.е. тут просто нужен один
> скрипт системный, а в настройках .gear/rules просто указать вид (там:
> gc, gh, sf ли полностью).

Так в .gear кладутся скрипты для cronbuild. Если есть какие-то общие
компоненты -- так их можно вынести отдельно и использовать.

Сейчас-то у нас пакетов собирающихся с помощью cronbuild ой как мало.

-- 
С уважением, Денис

http://mithraen.ru/
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] Угрозы развитию дистрибутива. Пути решения.

[Aleksey Avdeev]

[-- Attachment #1: Type: text/plain, Size: 719 bytes --]

01.10.2011 11:34, Денис Смирнов пишет:
> On Sat, Oct 01, 2011 at 09:53:09AM +0400, Мал Скрылёв wrote:
> 
>> Я имел ввиду, что процедура обновления для некоторых сайтов подобна,
>> напр. для googlecode, github, sourceforge. т.е. тут просто нужен один
>> скрипт системный, а в настройках .gear/rules просто указать вид (там:
>> gc, gh, sf ли полностью).
> 
> Так в .gear кладутся скрипты для cronbuild. Если есть какие-то общие
> компоненты -- так их можно вынести отдельно и использовать.
> 
> Сейчас-то у нас пакетов собирающихся с помощью cronbuild ой как мало.

  Сейчас в эту компанию я moodle* добавляю.

PS: Похоже мне придётся патчить cronbuild-rear для этого.

-- 

С уважением. Алексей.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]

Re: [devel] Угрозы развитию дистрибутива. Пути решения.

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 614 bytes --]

On Sat, Oct 01, 2011 at 07:08:28PM +0400, Aleksey Avdeev wrote:

AA> PS: Похоже мне придётся патчить cronbuild-rear для этого.

Мне сейчас в cronbuild больше всего нехватает возможности собирать
несколько пакетов одной транзакцией. Например пересборка asterisk требует
пересборки с ним в одной транзакции всех модулей, а этого cronbuild не
умеет.

Только поэтому asterisk до сих пор не собирается cronbuild'ом (за
исключением trunk, который собирается без сторонних модулей)

-- 
С уважением, Денис

http://mithraen.ru/
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] Угрозы развитию дистрибутива. Пути решения.

[Aleksey Avdeev]

[-- Attachment #1: Type: text/plain, Size: 1161 bytes --]

02.10.2011 11:24, Денис Смирнов пишет:
> On Sat, Oct 01, 2011 at 07:08:28PM +0400, Aleksey Avdeev wrote:
> 
> AA> PS: Похоже мне придётся патчить cronbuild-rear для этого.
> 
> Мне сейчас в cronbuild больше всего нехватает возможности собирать
> несколько пакетов одной транзакцией. Например пересборка asterisk требует
> пересборки с ним в одной транзакции всех модулей, а этого cronbuild не
> умеет.
> 
> Только поэтому asterisk до сих пор не собирается cronbuild'ом (за
> исключением trunk, который собирается без сторонних модулей)

  Меня подобная проблема с moodle*-lang-* ждёт. Сейчас я их собираю
скриптом (см.
<http://git.altlinux.org/people/solo/packages/?p=moodle-lang.git;a=blob;f=robot.sh;h=16c0b5844e7e68bed13a4de0eb9ad36b5003cd9a;hb=robot>).
Что именно обновлять -- решаю по информации на странице закачки
(обновляю всё, что старше уже собранных тегов).

  На данный момент -- не думаю, что переходить на индивидуальную
обработку каждого из пакетов (как того требует текущий cronbild) осмысленно.

PS: Ещё не хватает возможности обновления пакетов в бранчах, после
обновления в сизифе.

-- 

С уважением. Алексей.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]

Re: [devel] Угрозы развитию дистрибутива. Пути решения.

[Igor Vlasenko]

On Sun, Oct 02, 2011 at 02:22:38PM +0400, Aleksey Avdeev wrote:
> PS: Ещё не хватает возможности обновления пакетов в бранчах, после
> обновления в сизифе.

у меня есть такая функция, называется croncopy и копирует в t6.

-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: [devel] Угрозы развитию дистрибутива. Пути решения.

[Aleksey Avdeev]

[-- Attachment #1: Type: text/plain, Size: 568 bytes --]

03.10.2011 17:09, Igor Vlasenko пишет:
> On Sun, Oct 02, 2011 at 02:22:38PM +0400, Aleksey Avdeev wrote:
>> PS: Ещё не хватает возможности обновления пакетов в бранчах, после
>> обновления в сизифе.
> 
> у меня есть такая функция, называется croncopy и копирует в t6.

Как её использовать?

PS: Раскатываю губу:

1. Есть ли что-то подобное для p6 и 5.1/p5?

2. Есть ли нечто подобное, но не копирующее пакет, а запускающее сборку
из git, со скриптом автобэкпорта (у меня это мерж с типовыми
конфликтами) для бранча?

-- 

С уважением. Алексей.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]

Re: [devel] Угрозы развитию дистрибутива. Пути решения.

[Igor Vlasenko]

On Mon, Oct 03, 2011 at 05:20:07PM +0400, Aleksey Avdeev wrote:
> > у меня есть такая функция, называется croncopy и копирует в t6.
> 
> Как её использовать?

выслать мне имя пакета 

> PS: Раскатываю губу:
 
> 1. Есть ли что-то подобное для p6 и 5.1/p5?

для p6 p5 у робота нет прав,
для 5.1 не уверен, нужно ли кому-нибудь
 
> 2. Есть ли нечто подобное, но не копирующее пакет, а запускающее сборку
> из git, со скриптом автобэкпорта (у меня это мерж с типовыми
> конфликтами) для бранча?

нет. хотя сделать можно, те же autoports пример.

-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: [devel] Угрозы развитию дистрибутива. Пути решения.

[Андрей Черепанов]

[-- Attachment #1: Type: Text/Plain, Size: 549 bytes --]

3 октября 2011 Igor Vlasenko написал:
> On Mon, Oct 03, 2011 at 05:20:07PM +0400, Aleksey Avdeev wrote:
> > > у меня есть такая функция, называется croncopy и копирует в t6.
> > 
> > Как её использовать?
> 
> выслать мне имя пакета
> 
> > PS: Раскатываю губу:
> > 
> > 1. Есть ли что-то подобное для p6 и 5.1/p5?
> 
> для p6 p5 у робота нет прав,
И не будет. В p5 и p6 перекладывание сопровождается проверкой вручную.
Незачем для стабильных репозиториев прикручивать автоматическую эскалацию 
ошибок.

-- 
Андрей Черепанов
ALT Linux
cas@altlinux.ru

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] Угрозы развитию дистрибутива. Пути решения.

[Aleksey Avdeev]

[-- Attachment #1: Type: text/plain, Size: 1160 bytes --]

03.10.2011 20:02, Андрей Черепанов пишет:
> 3 октября 2011 Igor Vlasenko написал:
>> On Mon, Oct 03, 2011 at 05:20:07PM +0400, Aleksey Avdeev wrote:
>>>> у меня есть такая функция, называется croncopy и копирует в t6.
>>>
>>> Как её использовать?
>>
>> выслать мне имя пакета
>>
>>> PS: Раскатываю губу:
>>>
>>> 1. Есть ли что-то подобное для p6 и 5.1/p5?
>>
>> для p6 p5 у робота нет прав,
> И не будет. В p5 и p6 перекладывание сопровождается проверкой вручную.
> Незачем для стабильных репозиториев прикручивать автоматическую эскалацию 
> ошибок.

  Как быть с такими вещами, как moodle*-lang-*:

1. Обновляются апстримом они часто (несколько обновлений в неделю,
иногда -- в день).

2. Все ошибки правит апстрим (команда переводчиков). Глазами я смотрю
только ru и если его нужно править -- делаю это через апстрим.

  Не думаю, что из техническое обновление, т. е. обновление
предоставляемого апстримом zip архива без значимого обновления спека
(только дата и запись в changelog`е), разумно пропускать через человека,
даже в стабильных бранчах... (Я сейчас эти пакеты скриптом обновляю.)

-- 

С уважением. Алексей.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]

Re: [devel] Угрозы развитию дистрибутива. Пути решения.

[Igor Vlasenko]

On Mon, Oct 03, 2011 at 08:25:35PM +0400, Aleksey Avdeev wrote:
> >> для p6 p5 у робота нет прав,
> > И не будет. В p5 и p6 перекладывание сопровождается проверкой вручную.
> > Незачем для стабильных репозиториев прикручивать автоматическую эскалацию 
> > ошибок.
> 
>   Как быть с такими вещами, как moodle*-lang-*:
> 
> 1. Обновляются апстримом они часто (несколько обновлений в неделю,
> иногда -- в день).

Я думаю, t6 самое правильное место для этого.
Тем пользователям, которым нужен свежий moodle, стоит переехать на t6.
p6 и t6 -- это tradeoff между стабильностью и инновациями.

-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: [devel] Угрозы развитию дистрибутива. Пути решения.

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 365 bytes --]

On Mon, Oct 03, 2011 at 04:35:10PM +0300, Igor Vlasenko wrote:
>>> у меня есть такая функция, называется croncopy и копирует в t6.
>> Как её использовать?
IV> выслать мне имя пакета 

А можешь включить croncopy для /^asterisk.*/ ?

-- 
С уважением, Денис

http://mithraen.ru/
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] Угрозы развитию дистрибутива. Пути решения.

[Igor Vlasenko]

On Tue, Oct 04, 2011 at 08:16:10PM +0400, Денис Смирнов wrote:
> On Mon, Oct 03, 2011 at 04:35:10PM +0300, Igor Vlasenko wrote:
> >>> у меня есть такая функция, называется croncopy и копирует в t6.
> >> Как её использовать?
> IV> выслать мне имя пакета 
> 
> А можешь включить croncopy для /^asterisk.*/ ?

сейчас можно только явный список пакетов указать.

-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: [devel] Угрозы развитию дистрибутива. Пути решения.

[Igor Vlasenko]

On Sun, Oct 02, 2011 at 11:24:26AM +0400, Денис Смирнов wrote:
> Мне сейчас в cronbuild больше всего нехватает возможности собирать
> несколько пакетов одной транзакцией. Например пересборка asterisk требует
> пересборки с ним в одной транзакции всех модулей, а этого cronbuild не
> умеет.

Ок, буду думать. 
Модули нужно просто пересобрать?


-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: [devel] Угрозы развитию дистрибутива. Пути решения.

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 1535 bytes --]

On Sun, Oct 02, 2011 at 09:16:19PM +0300, Igor Vlasenko wrote:

IV> Ок, буду думать. 
IV> Модули нужно просто пересобрать?

Внизу пример скрипта, который это делает у меня. Раньше еще обновлялся макрос
ast_version, но теперь я его тупо беру из %get_version. Так что я только
увеличиваю release на 1 и добавляю строчку в %changelog.

Да, а еще есть ghc. Который вообще очень бы надо отдать cronbuild'у, но
там есть аналогичная проблема -- после сборки любого модуля надо
пересобирать с ним все от него зависящие. И так итеративно...

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


#!/bin/bash -e
T=`mktemp`
rpmbuild -bE ../asterisk1.6.2/asterisk1.6.2.spec > $T
VER=`grep ^Version: $T | sed 's/Version:[[:space:]]*//' | head -n 1`
REL=`grep ^Release: $T | sed 's/Release:[[:space:]]*//' | head -n 1`


SPECNAME=`ls -1 *.spec | head -1`

MYREL=$(rpmbuild -bE $SPECNAME | grep Release | head -1 | sed 's/Release:[[:space:]]*alt//')
MYREL=$(($MYREL+1))

sed -i "s/^Release:.*/Release: alt$MYREL/" $SPECNAME
#sed -i "s/%define ast_version.*/%define ast_version $VER/" $SPECNAME
add_changelog -e '- Asterisk update' $SPECNAME
gear-commit -a --no-edit
gear-rel

rm -f "$T"


-- 
С уважением, Денис

http://mithraen.ru/
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] Угрозы развитию дистрибутива. Пути решения.

[Paul Wolneykien]

03.10.2011 06:58, Денис Смирнов пишет:
> Да, а еще есть ghc. Который вообще очень бы надо отдать cronbuild'у, но
> там есть аналогичная проблема -- после сборки любого модуля надо
> пересобирать с ним все от него зависящие. И так итеративно...

   Вообще говоря, мне кажется, что это проблема не отдельных пакетов, не 
cronbuild, а всего Сизифа в целом. То, что нет пересборки по 
зависимостям. Точнее, это не проблема даже, а просто особенность 
поведения. Частично неблагоприятные последствия компенсируются тем, что 
Сизиф регулярно пересобирается весь целиком. Но пересборка проходит 
гладко не во всех случаях и многие транзакции приходится выстраивать 
вручную, чтобы собрать пакеты в правильном порядке.

   Посему предлагаю поднять вопрос о добавлении в Сизиф/girar 
возможности создавать некоторые «правила пересборки подсистем». Так, 
чтобы пользователь мог указать, в каком порядке должно пересобираться 
некоторое подмножество пакетов в рамках процедуры регулярной пересборки 
Сизифа. Тогда не придётся ничего прикручивать к cronbuild.


     Паша.

Re: [devel] Угрозы развитию дистрибутива. Пути решения.

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 5029 bytes --]

On Mon, Oct 03, 2011 at 01:11:32PM +0400, Paul Wolneykien wrote:

PW>    Вообще говоря, мне кажется, что это проблема не отдельных пакетов, не 
PW> cronbuild, а всего Сизифа в целом. То, что нет пересборки по 
PW> зависимостям. 

А она далеко не всегда нужна. После обновления, скажем, gcc нет
необходимости пересобирать _все_, от чего зависит gcc.

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

PW> Точнее, это не проблема даже, а просто особенность  поведения.

Я не представляю себе как эту проблему можно решить.

PW> Частично неблагоприятные последствия компенсируются тем, что 
PW> Сизиф регулярно пересобирается весь целиком. 

Это не так. Это исключительно тестовые пересборки, их результат не
попадает в Сизиф. У нас до сих пор есть пакеты без debuginfo, например.

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

Для этого тоже есть робот от viy@, который я и использую для выстраивания
порядка сборки модулей ghc.

PW>    Посему предлагаю поднять вопрос о добавлении в Сизиф/girar 
PW> возможности создавать некоторые «правила пересборки подсистем». Так, 
PW> чтобы пользователь мог указать, в каком порядке должно пересобираться 
PW> некоторое подмножество пакетов в рамках процедуры регулярной пересборки 
PW> Сизифа. Тогда не придётся ничего прикручивать к cronbuild.

Увы, это не так.

Поясняю -- вот cronbuild пытается пересобрать asterisk. Необходимо
обязательно _в той же транзакции_ пересобрать модули. С чего это girar
должен чего-то додумывать, и добавлять в транзакцию пакеты, которые его не
просили?

Это совершенно недопустимо. Низкоуровневые решения должны выполнять четко
команды, а не пытаться добавлять к ним свой интеллект. А имитировать
мышление, это уже дело для роботов, которые работают поверх girar. Таких
как cronbuild.

А уж с ghc все еще грустнее -- надо учитывать тот факт, что обновление
одного модуля может потребовать обновить другой. А может и не потребовать.
И это надо иногда даже тестировать -- делая пробные сборки. И робот,
который сможет сам мантейнить ghc должен быть весьма умный. Я бы очень
хотел чтобы такой был, но не думаю что столь умного робота кто-нибудь
станет писать :)

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

Так что поддержку перловых модулей можно хоть сейчас передать на
растерзание роботам.

-- 
С уважением, Денис

http://mithraen.ru/
----------------------------------------------------------------------------


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] Угрозы развитию дистрибутива. Пути решения.

[Paul Wolneykien]

03.10.2011 15:55, Денис Смирнов пишет:
> On Mon, Oct 03, 2011 at 01:11:32PM +0400, Paul Wolneykien wrote:
>
> PW>     Вообще говоря, мне кажется, что это проблема не отдельных пакетов, не
> PW>  cronbuild, а всего Сизифа в целом. То, что нет пересборки по
> PW>  зависимостям.
>
> А она далеко не всегда нужна. После обновления, скажем, gcc нет
> необходимости пересобирать _все_, от чего зависит gcc.

   Я и не говорю, что это всегда нужно — как раз наоборот: можно 
подсистему создать, а можно и не создавать.

> ...

>
> Поясняю -- вот cronbuild пытается пересобрать asterisk. Необходимо
> обязательно _в той же транзакции_ пересобрать модули. С чего это girar
> должен чего-то додумывать, и добавлять в транзакцию пакеты, которые его не
> просили?

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


     Паша.

Re: [devel] Угрозы развитию дистрибутива. Пути решения.

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 1068 bytes --]

On Mon, Oct 03, 2011 at 05:11:41PM +0400, Paul Wolneykien wrote:

PW>    Я и не говорю, что это всегда нужно — как раз наоборот: можно 
PW> подсистему создать, а можно и не создавать.

Так как это должно выглядеть?

PW>    Если мы, в ряде случаев, перейдём от обновления отдельных пакетов к 
PW> обновлению подсистем как единых сущностей, то и cronbuild будет 
PW> обновлять подсистему целиком, а girar её пересобирать, согласно 
PW> установленным для данной подсистемы правилам.

Каким правилам?

Hint: чтобы что-то закодить, нужно это очень четко описать.

-- 
С уважением, Денис

http://mithraen.ru/
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] Угрозы развитию дистрибутива. Пути решения: gear-subsystem

[Paul Wolneykien]

04.10.2011 20:14, Денис Смирнов пишет:
> On Mon, Oct 03, 2011 at 05:11:41PM +0400, Paul Wolneykien wrote:
>
> PW>     Я и не говорю, что это всегда нужно — как раз наоборот: можно
> PW>  подсистему создать, а можно и не создавать.
>
> Так как это должно выглядеть?
>
> PW>     Если мы, в ряде случаев, перейдём от обновления отдельных пакетов к
> PW>  обновлению подсистем как единых сущностей, то и cronbuild будет
> PW>  обновлять подсистему целиком, а girar её пересобирать, согласно
> PW>  установленным для данной подсистемы правилам.
>
> Каким правилам?
>
> Hint: чтобы что-то закодить, нужно это очень четко описать.

   А чтобы что-то чётко описать, нужно сначала это хотя-бы примерно 
представить. :)

   Идея в том, чтобы совершать действия не с отдельным пакетом, а с 
группой пакетов — подсистемой ­— как с единым целым. Я представляю что 
подсистема — это:

   1. список gear-репозиториев, из которых собираются пакеты;

   2. сценарий для вычисления и сортировки набора всех требующих 
обновления пакетов;

   3. сценарий — единая точка входа для обновления версий и истории 
изменения в каждом из требующих обновления пакетов.

   Хранить информацию о наборе gear (git)-репозиториев (п. 1.) можно 
было бы, наверное, используя git-submodule. Тогда главный репозиторий 
хранил бы в себе пп. 2 и 3. Для выполнения обновления и сборки можно 
было бы завести команды-обёртки, использующие код пп. 2 и 3. Тогда 
обновление подсистемы может выглядеть примерно так:

   $ cd <dir>
   …
   обновляем код
   …
   $ git commit

   $ cd ..

   $ git submodule push

   $ gear subsystem add-changelog -m "Compiler update: v1.8.5"
# В результате чего обновляются релиз версии (-altN) и история
# изменений в каждом затрагиваемом пакете. Например, если
# обновляется компилятор и сценарий из п.2 выбирает ещё несколько
# библиотек для обновления, то в каждой из них релиз будет увеличен
# на единицу, а в истории изменений записано стандартное сообщение:
# "Update due to compiler update: v1.8.5", полученное на основе
# сообщения, указанного пользователем.

   $ gear subsystem tag -s -a -m "Version 1.8.5" v1.8.5
# В результате чего ставятся (подписанные) теги в каждом
# затрагиваемом git-репозитории.

   $ gear subsystem build sisyphus v1.8.5
# В результате чего формируется сборочное задание из всех
# затрагиваемых репозиториев (и тегов), отсортированное в
# правильном порядке.

   Как-то так. Это должно быть удобно и человеку и роботу (cronbuild). 
Или нет?


     Паша.

Re: [devel] Угрозы развитию дистрибутива. Пути решения: gear-subsystem

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 2586 bytes --]

On Tue, Oct 04, 2011 at 09:38:50PM +0400, Paul Wolneykien wrote:

PW>    Идея в том, чтобы совершать действия не с отдельным пакетом, а с 
PW> группой пакетов — подсистемой ­— как с единым целым. Я представляю что 
PW> подсистема — это:
PW>    1. список gear-репозиториев, из которых собираются пакеты;
PW>    2. сценарий для вычисления и сортировки набора всех требующих 
PW> обновления пакетов;
PW>    3. сценарий — единая точка входа для обновления версий и истории 
PW> изменения в каждом из требующих обновления пакетов.
PW>    Хранить информацию о наборе gear (git)-репозиториев (п. 1.) можно 
PW> было бы, наверное, используя git-submodule. Тогда главный репозиторий 
PW> хранил бы в себе пп. 2 и 3. Для выполнения обновления и сборки можно 
PW> было бы завести команды-обёртки, использующие код пп. 2 и 3. Тогда 
PW> обновление подсистемы может выглядеть примерно так:

Итого это все равно превратиться в набор сценариев поверх girar-nmu.

PW>    Как-то так. Это должно быть удобно и человеку и роботу (cronbuild). 
PW> Или нет?

Скажу так -- встроить по крайней мере часть функционала girar-nmu в girar
было бы полезно. А столь высокоуровневые вещи туда встраивать бесполезно,
ибо они будут либо слишком ограниченными, либо слишком гибкими (и не
пройдут требований ldv@ по безопасности и качеству кода).

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

-- 
С уважением, Денис

http://mithraen.ru/
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] Угрозы развитию дистрибутива. Пути решения: gear-subsystem

[Paul Wolneykien]

04.10.2011 21:50, Денис Смирнов пишет:
> On Tue, Oct 04, 2011 at 09:38:50PM +0400, Paul Wolneykien wrote:
>
> PW>     Идея в том, чтобы совершать действия не с отдельным пакетом, а с
> PW>  группой пакетов — подсистемой ­— как с единым целым. Я представляю что
> PW>  подсистема — это:
> PW>     1. список gear-репозиториев, из которых собираются пакеты;
> PW>     2. сценарий для вычисления и сортировки набора всех требующих
> PW>  обновления пакетов;
> PW>     3. сценарий — единая точка входа для обновления версий и истории
> PW>  изменения в каждом из требующих обновления пакетов.
> PW>     Хранить информацию о наборе gear (git)-репозиториев (п. 1.) можно
> PW>  было бы, наверное, используя git-submodule. Тогда главный репозиторий
> PW>  хранил бы в себе пп. 2 и 3. Для выполнения обновления и сборки можно
> PW>  было бы завести команды-обёртки, использующие код пп. 2 и 3. Тогда
> PW>  обновление подсистемы может выглядеть примерно так:
>
> Итого это все равно превратиться в набор сценариев поверх girar-nmu.
>
> PW>     Как-то так. Это должно быть удобно и человеку и роботу (cronbuild).
> PW>  Или нет?
>
> Скажу так -- встроить по крайней мере часть функционала girar-nmu в girar
> было бы полезно. А столь высокоуровневые вещи туда встраивать бесполезно,
> ибо они будут либо слишком ограниченными, либо слишком гибкими (и не
> пройдут требований ldv@ по безопасности и качеству кода).

   А причём тут girar? Он тут уже не причём. Есть просто git-репозиторий 
с подключёнными модулями, некоторый набор скриптов в, предположим, 
.gear/subsystem, и программы-обёртки к ним (gear-subsystem-*). Всё что я 
пока предлагаю, это сделать единую точку входа для обновления версий и 
истории изменения набора связанных пакетов, и для расстановки сборочных 
тегов. Для этого нужен скрипт, умеющий выбирать требующие пересборки 
пакеты (как уже писалось выше, не всегда нужно пересобирать все пакеты). 
Как и в случае с cronbuild-update-source, такой сценарий будет в каждом 
случае свой. Но вот остальную часть механизма можно было бы сделать 
стандартной.

>
> В первом случае окажется что оно пригодно только для небольшого количества
> пакетов, которые прекрасно обойдутся без этого.
>
>
>
>
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

Re: [devel] Угрозы развитию дистрибутива. Пути решения: gear-subsystem

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 1216 bytes --]

On Tue, Oct 04, 2011 at 10:33:58PM +0400, Paul Wolneykien wrote:

PW>    А причём тут girar? Он тут уже не причём. Есть просто git-репозиторий 
PW> с подключёнными модулями, некоторый набор скриптов в, предположим, 
PW> .gear/subsystem, и программы-обёртки к ним (gear-subsystem-*). Всё что я 
PW> пока предлагаю, это сделать единую точку входа для обновления версий и 
PW> истории изменения набора связанных пакетов, и для расстановки сборочных 
PW> тегов. Для этого нужен скрипт, умеющий выбирать требующие пересборки 
PW> пакеты (как уже писалось выше, не всегда нужно пересобирать все пакеты). 
PW> Как и в случае с cronbuild-update-source, такой сценарий будет в каждом 
PW> случае свой. Но вот остальную часть механизма можно было бы сделать 
PW> стандартной.

До этого речь шла о том, чтобы это было внутри сборочницы (т.е. girar).

А зачем тут монстрить всякие submodule я не очень понимаю. По крайней мере
я сильно сомневаюсь что буду таким монстром пользоваться. В отличии от
girar-nmu, который прямо сейчас мне уже помогает, экономя десятки _часов_
времени.

-- 
С уважением, Денис

http://mithraen.ru/
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] Угрозы развитию дистрибутива. Пути решения.

[Igor Vlasenko]

On Sun, Oct 02, 2011 at 11:24:26AM +0400, Денис Смирнов wrote:
> Мне сейчас в cronbuild больше всего нехватает возможности собирать
> несколько пакетов одной транзакцией. Например пересборка asterisk требует
> пересборки с ним в одной транзакции всех модулей, а этого cronbuild не
> умеет.

Я подумал, такую функцию реализовать можно.
что-то вроде вызова girar-nmu на модули,
внутри чего-то вроде .gear/cronbuild-run-task <taskame> hook-a.

-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: [devel] Муть moodle в cronbild (was: Угрозы развитию дистрибутива. Пути решения.)

[Aleksey Avdeev]

[-- Attachment #1: Type: text/plain, Size: 3321 bytes --]

01.10.2011 19:08, Aleksey Avdeev пишет:
> 01.10.2011 11:34, Денис Смирнов пишет:
...
>> Так в .gear кладутся скрипты для cronbuild. Если есть какие-то общие
>> компоненты -- так их можно вынести отдельно и использовать.
>>
>> Сейчас-то у нас пакетов собирающихся с помощью cronbuild ой как мало.
> 
>   Сейчас в эту компанию я moodle* добавляю.
> 
> PS: Похоже мне придётся патчить cronbuild-rear для этого.

  Прототип cronbuild`овских скриптов готов (см.
<http://git.altlinux.org/people/solo/packages/?p=moodle.git;a=tree;f=.gear;h=9e9b7b43b93dd705a12bddb0f7547ea194e23b98;hb=3df59e6b4bb7498697a01cabd919cd6166cc2d30>)
и тестовое обновление сборочного бранча gear-cronbuild`ом выполнено (см.
<http://git.altlinux.org/people/solo/packages/?p=moodle.git;a=commit;h=40041eb6e5a8ed63743a928969b3dfe8993b3145>).

  По свежим следам:

1. Всю логику пришлось выносить в cronbuild-update-source (см.
<http://git.altlinux.org/people/solo/packages/?p=moodle.git;a=blob;f=.gear/cronbuild-update-source;h=e65098fe3c6a1241c593ac61c4756ace0b5a3f10;hb=3df59e6b4bb7498697a01cabd919cd6166cc2d30>),
а cronbuild-{update-version,add-changelog} -- низводить до состаяния
заглушек, тупо выполняющих exit 0 (см.
<http://git.altlinux.org/people/solo/packages/?p=moodle.git;a=blob;f=.gear/cronbuild-update-version;h=a3c4c486aa2464f097cd5716ea817121b8ad44d6;hb=3df59e6b4bb7498697a01cabd919cd6166cc2d30>).
Причины опишу ниже.

2. При использовании gear-commit -m <msg> _необходимо_ учитывать
находящийся в потрохах gear-commit`а eval => сложные <msg> нужно квотить
=> это нужно учитывать в cronbuild-commitmsg (в моём случаи -- см.
<http://git.altlinux.org/people/solo/packages/?p=moodle.git;a=commitdiff;h=3df59e6b4bb7498697a01cabd919cd6166cc2d30>)...
Думаю, стоит перенести оквочивание на уровень gear-cronbuild*.

3. Думаю, в скрипты cronbuild-{commitmsg,tag{name,msg}} стоить
передавать имя спека.

  Для п. п. 2-3 готов подготовить патчи.

  По п. 1 (обещание данное выше).

  gear-cronbuild заточен на реализацию следующего алгоритма:

1. Обновление сорцов (cronbuild-update-source).

2. Правка спека на предмет версий (cronbuild-update-version).

3. Обновление changelog`а (cronbuild-add-changelog).

4. Финальный (сборочный) коммит (gear-commit).

  Причём, подразумевается что всё действо происходит в одном бранче
(если cronbuild-update-source не внесёт изменений в начальный бранч --
git diff изменений не покажет => gear-cronbuild-apply-hooks обновления
сорцов не заметит). П. 3 должен выполнить подготовку к коммиту, но не
выполнять его (иначе gear-commit в п. 4 завершиться с ошибкой).

  Я же использую пачку бранчей, и следующий алгоритм:

1. Обновление бранчей с сорцами. Это последовательность pull`ов и
мержей, _не_затрагивающая_ основной (сборочный) бранч.

2. Правка спека на предмет версий в основном бранче (в конечном итоге).

3. Мерж сорцовых бранчей в основной (-s ours).

4. Выставление тегов на исходники.

5. gear-update-tag

6. Финальный (сборочный) коммит.

  В общем, законопачивание п. п. 1-5 в cronbuild-update-source (хотя, по
хорошему, там только п. 1 место) позволило применить данный алгоритм
cronbuild`ом, и реализовать откат на исходное состояние бранчей (если
что-то пошло не так) малой кровью.

-- 

С уважением. Алексей.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]

Re: [devel] Муть moodle в cronbild

[Aleksey Avdeev]

[-- Attachment #1: Type: text/plain, Size: 548 bytes --]

05.10.2011 00:53, Aleksey Avdeev пишет:
> 01.10.2011 19:08, Aleksey Avdeev пишет:
...
> 
>   По свежим следам:
> 
...
> 
> 3. Думаю, в скрипты cronbuild-{commitmsg,tag{name,msg}} стоить
> передавать имя спека.

  Поправка: Для cronbuild-commitmsg передавать имя спека параметром не
нужно, т. к.:

1. Скрипты использующие cronbuild-commitmsg этой информации не имеют.

2. В тот момент, когда происходит вызов cronbuild-commitmsg репозиторий
находится в состоянии допускающем использование gear.

-- 

С уважением. Алексей.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]

Re: [devel] Муть moodle в cronbild

[Aleksey Avdeev]

[-- Attachment #1: Type: text/plain, Size: 730 bytes --]

05.10.2011 01:36, Aleksey Avdeev пишет:
> 05.10.2011 00:53, Aleksey Avdeev пишет:
>> 01.10.2011 19:08, Aleksey Avdeev пишет:
> ...
>>
>>   По свежим следам:
>>
> ...
>>
>> 3. Думаю, в скрипты cronbuild-{commitmsg,tag{name,msg}} стоить
>> передавать имя спека.
> 
>   Поправка: Для cronbuild-commitmsg передавать имя спека параметром не
> нужно, т. к.:
> 
> 1. Скрипты использующие cronbuild-commitmsg этой информации не имеют.
> 
> 2. В тот момент, когда происходит вызов cronbuild-commitmsg репозиторий
> находится в состоянии допускающем использование gear.

  Придложение вообще снимаю: в repocop-cronbuild-{git,srpm} заниматься
определением имени спека не осмысленно.

-- 

С уважением. Алексей.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]

Re: [devel] Путь moodle в cronbild (was: Муть moodle в cronbild)

[Aleksey Avdeev]

[-- Attachment #1: Type: text/plain, Size: 1242 bytes --]

05.10.2011 00:53, Aleksey Avdeev пишет:
> 01.10.2011 19:08, Aleksey Avdeev пишет:
...
> 
>   Прототип cronbuild`овских скриптов готов (см.
> <http://git.altlinux.org/people/solo/packages/?p=moodle.git;a=tree;f=.gear;h=9e9b7b43b93dd705a12bddb0f7547ea194e23b98;hb=3df59e6b4bb7498697a01cabd919cd6166cc2d30>)
> и тестовое обновление сборочного бранча gear-cronbuild`ом выполнено (см.
> <http://git.altlinux.org/people/solo/packages/?p=moodle.git;a=commit;h=40041eb6e5a8ed63743a928969b3dfe8993b3145>).
> 
>   По свежим следам:
> 
...
> 
> 2. При использовании gear-commit -m <msg> _необходимо_ учитывать
> находящийся в потрохах gear-commit`а eval => сложные <msg> нужно квотить
> => это нужно учитывать в cronbuild-commitmsg (в моём случаи -- см.
> <http://git.altlinux.org/people/solo/packages/?p=moodle.git;a=commitdiff;h=3df59e6b4bb7498697a01cabd919cd6166cc2d30>)...
> Думаю, стоит перенести оквочивание на уровень gear-cronbuild*.

  См. <https://bugzilla.altlinux.org/show_bug.cgi?id=26412>

> 
> 3. Думаю, в скрипты cronbuild-{commitmsg,tag{name,msg}} стоить
> передавать имя спека.

  Предложение снимаю (см. соседнее письмо).

> 
>   Для п. п. 2-3 готов подготовить патчи.

-- 

С уважением. Алексей.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]

Re: [devel] Путь moodle в cronbild (was: Муть moodle в cronbild)

[Igor Vlasenko]

On Wed, Oct 05, 2011 at 02:04:02AM +0400, Aleksey Avdeev wrote:
>   Предложение снимаю (см. соседнее письмо).

Ок, я патчи втянул, когда отправите в Сизиф сборку,
у которой в .gear нужные скрипты cronbuild, 
напишите, я добавлю ее к роботу.

-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: [devel] Путь moodle в cronbild

[Aleksey Avdeev]

[-- Attachment #1: Type: text/plain, Size: 505 bytes --]

05.10.2011 13:49, Igor Vlasenko пишет:
> On Wed, Oct 05, 2011 at 02:04:02AM +0400, Aleksey Avdeev wrote:
>>   Предложение снимаю (см. соседнее письмо).
> 
> Ок, я патчи втянул, когда отправите в Сизиф сборку,
> у которой в .gear нужные скрипты cronbuild, 
> напишите, я добавлю ее к роботу.

  Сделано -- см.
<http://git.altlinux.org/tasks/archive/done/_54/56262/logs/events.2.1.log>
(ACL для cronbuild выданы.)

  Также, прошу подключить moodle к croncopy.
-- 

С уважением. Алексей.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]

Re: [devel] Путь moodle в cronbild

[Aleksey Avdeev]

[-- Attachment #1: Type: text/plain, Size: 854 bytes --]

05.10.2011 14:56, Aleksey Avdeev пишет:
> 05.10.2011 13:49, Igor Vlasenko пишет:
>> On Wed, Oct 05, 2011 at 02:04:02AM +0400, Aleksey Avdeev wrote:
>>>   Предложение снимаю (см. соседнее письмо).
>>
>> Ок, я патчи втянул, когда отправите в Сизиф сборку,
>> у которой в .gear нужные скрипты cronbuild, 
>> напишите, я добавлю ее к роботу.
> 
>   Сделано -- см.
> <http://git.altlinux.org/tasks/archive/done/_54/56262/logs/events.2.1.log>
> (ACL для cronbuild выданы.)

  moodle2.0 (см.
<http://git.altlinux.org/tasks/archive/done/_54/56272/logs/events.2.2.log>)
и moodle2.1 (см.
<http://git.altlinux.org/tasks/archive/done/_54/56277/logs/events.1.1.log>)
тоже сделаны. (ACL для cronbuild выданы.)

> 
>   Также, прошу подключить moodle к croncopy.

  moodle2.0 и moodle2.1 прошу подключить тоже.

-- 

С уважением. Алексей.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]

Re: [devel] Муть moodle в cronbild (was: Угрозы развитию дистрибутива. Пути решения.)

[Igor Vlasenko]

On Wed, Oct 05, 2011 at 12:53:10AM +0400, Aleksey Avdeev wrote:
> 1. Всю логику пришлось выносить в cronbuild-update-source
> а cronbuild-{update-version,add-changelog} -- низводить до состаяния
> заглушек, тупо выполняющих exit 0

Действительно, что-то часто приходится так делать.

Хочу в следующей версии дописать интеллект, 
который вызывает cronbuild-{update-version,add-changelog}
только в случае необходимости.

-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: [devel] Муть moodle в cronbild (was: Угрозы развитию дистрибутива. Пути решения.)

[Igor Vlasenko]

On Wed, Oct 05, 2011 at 12:43:56PM +0300, Igor Vlasenko wrote:
> On Wed, Oct 05, 2011 at 12:53:10AM +0400, Aleksey Avdeev wrote:
> > 1. Всю логику пришлось выносить в cronbuild-update-source
> > а cronbuild-{update-version,add-changelog} -- низводить до состаяния
> > заглушек, тупо выполняющих exit 0
> 
> Действительно, что-то часто приходится так делать.
> 
> Хочу в следующей версии дописать интеллект, 
> который вызывает cronbuild-{update-version,add-changelog}
> только в случае необходимости.

Сделал. теперь хаглушки можно не создавать.

-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: [devel] Угрозы развитию дистрибутива. Пути решения.

[Igor Vlasenko]

On Sat, Oct 01, 2011 at 09:53:09AM +0400, Мал Скрылёв wrote:
> Я имел ввиду, что процедура обновления для некоторых сайтов подобна,
> напр. для googlecode, github, sourceforge. т.е. тут просто нужен один
> скрипт системный, а в настройках .gear/rules просто указать вид (там:
> gc, gh, sf ли полностью).

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

-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

[devel] Пробел в архитектуре gear репозиториев, мешающий совместной работе.

[Igor Vlasenko]

On Sat, Oct 01, 2011 at 09:53:09AM +0400, Мал Скрылёв wrote:
> >> Немного конкретики о самодейном обновлении пакета,
> >> Собственно нужно два скрипта [...]

Я хотел бы напомнить, что у нас при работе
с пакетом c помощью git+gear репозиториев
вылезает грабля в gear, мешающая совместной работе.

Не только с роботом, но и между людьми.

Именно, при клонировании git+gear репозитария,
который не обновляется из тарболов, а берет коммиты напрямую
из апстримного SCM, теряется информация, откуда предыдущий
майнтайнер брал коммиты.

В результате, чтобы работать с таким репозитарием,
нужно потратить время, догадаться, откуда с какого сайта
взялись коммиты и выставить этот сайт локально в remotes,
в случае git-svn надо еще догадаться, какая там корректная 
конфигурация для git-svn.
А есть еще git-cvs, bzr, ...

gear спроектирован так, что он не надеется на git, а хранит 
свои теги в .gear/tags. Это хорошо. К сожалению, 
с remotes различных типов такого не сделано. 
В результате, git+gear репозитарии, использующие remote SCM, 
к совместному использованию малопригодны.

В случае с SRPM пакетом или простым git+gear репозитарием,
если майнтайнер в отпуске в тропиках, а для пакета выпущана
новая версия с горящим security fix, то QA тим может 
за 5 минут выложить новую версию.

А в случае с git+gear репозитарием, у которого в публичном
доступе только часть информации, а информация о источниках
обновления является приватной и недоступна,
придется потратить на порядок больше времени, только для того,
чтобы дешифровать то, что gear забыл/не сумел сохранить.

Или забИть на структуру git+gear репозитария, создать его
из тарбола заново (пройдет, если майнтайнер совсем забросил
пакет; но если он в тропиках, то по возвращении будет в шоке :(

Я бы сохранял git remotes в .gear/remotes/git/
git-svn настройки в .gear/remotes/svn/
и т.д.

и утилиты
gear-remotes-save
gear-remotes-restore


-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: [devel] Пробел в архитектуре gear репозиториев, мешающий совместной работе.

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 538 bytes --]

On Sat, Oct 01, 2011 at 11:32:49PM +0300, Igor Vlasenko wrote:

IV> Я бы сохранял git remotes в .gear/remotes/git/
IV> git-svn настройки в .gear/remotes/svn/

Думаю это слишком. Достаточно файла .gear/remotes, в котором несколько
секций.

IV> и т.д.
IV> и утилиты
IV> gear-remotes-save
IV> gear-remotes-restore

Этот же скрипт можно научить создавать автоматом бранчи основываясь на
.gear/tags.

-- 
С уважением, Денис

http://mithraen.ru/
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] Пробел в архитектуре gear репозиториев, мешающий совместной работе.

[Igor Vlasenko]

On Sun, Oct 02, 2011 at 11:22:33AM +0400, Денис Смирнов wrote:
> On Sat, Oct 01, 2011 at 11:32:49PM +0300, Igor Vlasenko wrote:
> 
> IV> Я бы сохранял git remotes в .gear/remotes/git/
> IV> git-svn настройки в .gear/remotes/svn/
> 
> Думаю это слишком. Достаточно файла .gear/remotes, в котором несколько
> секций.

а не будет ли файл с секциями слишком роботонечитабельным?

> IV> gear-remotes-save
> IV> gear-remotes-restore

> Этот же скрипт можно научить создавать автоматом бранчи основываясь на
> .gear/tags.
+1

-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: [devel] Пробел в архитектуре gear репозиториев, мешающий совместной работе.

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 801 bytes --]

On Sun, Oct 02, 2011 at 09:15:06PM +0300, Igor Vlasenko wrote:

IV> а не будет ли файл с секциями слишком роботонечитабельным?

Ну, .gitconfig оказывается вполне себе читабельным, например.

Только один раз написать утилиту для работы с произвольными файлами этого
формата по аналогии с git config (если его нельзя для этой цели
приспособить).

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

А множество каталогов и файликов тоже не очень-то удобно -- быстрого
обзора глазами нет, ручное редактирование требует бегать по каталогам.

-- 
С уважением, Денис

http://mithraen.ru/
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] Угрозы развитию дистрибутива. Пути решения.

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 822 bytes --]

On Thu, Sep 29, 2011 at 11:29:49AM +0400, Мал Скрылёв wrote:

> Немного конкретики о самодейном обновлении пакета, если позволите сюда.
> Собственно нужно два скрипта (напр, башевских ну или каких иных,
> требования можно в том же спеке описать) getver и getdata. Первый
> будет получать правильную последнюю версию пакета, а второй, если
> версия новая там есть уже, собственно, получать пакет и
> преобразовывать его в нужный вид (архивировать или наборот, и
> выцапытвать только то, что нужно от него).
> Поместить их можно, например, в папку .gear: .gear/getver, .gear/getdata

http://www.altlinux.org/Gear/cronbuild

Уже есть и работает.

И замечательно, кстати, работает.

-- 
С уважением, Денис

http://mithraen.ru/
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] Угрозы развитию дистрибутива. Пути решения.

[Paul Wolneykien]

25.09.2011 02:35, Igor Vlasenko пишет:
> = Конвертирование пакетов как альтернатива универсальному пакету.

   Игорь, спасибо за доклад. Почти со всем согласен и поддерживаю. Но 
давайте вместе подумаем, к чему это приведёт.

   Появление "Диалектов Linux", на мой взгляд, процесс в большей степени 
социальный, чем технический: здесь замешаны и амбиции, моральные и 
коммерческие обязательства, много всего. Если идеализировать ситуацию, 
то казалось бы, нужно просто собраться всем-всем-всем по всему миру и 
договориться делать единый дистрибутив сообща. Но люди не смогут, да и 
не должны так строго организовываться. А вот на "переводчик спеков" 
могут и "клюнуть", поскольку такой инструмент потенциально не 
ограничивает свободу сопровождения пакета. Я бы назвал конвертирование 
"умным копированием".

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


     Павел.

Re: [devel] Угрозы развитию дистрибутива. Пути решения.

[Denis Medvedev]

26 сентября 2011, 10:32 от Boris Savelev <boris@altlinux.org>:
> >> и дать
> >> возможность получать пакеты не только для ALT Linux, но и для
> >> других дистрибутвов (экономя время разработчику приложений).
> >
> > Это есть, Corinf oт Евгения Синельникова (sin@)
> 
> когда я работал в etersoft, это был Korinf от Виталия Липатова (lav@)
> 
Гораздо лучше было бы, если бы сами разработчики софта (1-st tier) могли бы просто генерировать пакеты для ALT вкупе с пакетами для других дистрибутивов. Кто бы добавил ALT в список дистрибутивов, поддерживаемых http://en.wikipedia.org/wiki/Open_Build_Service ?!

Re: [devel] Угрозы развитию дистрибутива. Пути решения.

[Michael Shigorin]

On Mon, Sep 26, 2011 at 06:36:01PM +0400, Denis  Medvedev wrote:
> Кто бы добавил ALT в список дистрибутивов, поддерживаемых
> http://en.wikipedia.org/wiki/Open_Build_Service ?!

Если будет ответ на вопрос "зачем", то над вопросом "как"
можно подумать со знакомым в suse...

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] Угрозы развитию дистрибутива. Пути решения.

[Paul Wolneykien]

26.09.2011 19:38, Michael Shigorin пишет:
> On Mon, Sep 26, 2011 at 06:36:01PM +0400, Denis  Medvedev wrote:
>> Кто бы добавил ALT в список дистрибутивов, поддерживаемых
>> http://en.wikipedia.org/wiki/Open_Build_Service ?!
>
> Если будет ответ на вопрос "зачем", то над вопросом "как"
> можно подумать со знакомым в suse...

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

Re: [devel] Угрозы развитию дистрибутива. Пути решения.

[Igor Vlasenko]

On Mon, Sep 26, 2011 at 06:36:01PM +0400, Denis  Medvedev wrote:
> Гораздо лучше было бы, если бы сами разработчики софта (1-st tier) могли бы просто генерировать пакеты для ALT вкупе с пакетами для других дистрибутивов. Кто бы добавил ALT в список дистрибутивов, поддерживаемых http://en.wikipedia.org/wiki/Open_Build_Service ?!

Тарбол чем не coвceм удобен, что из него непонятно как брать 
Summary, Description.

дальше уже
BuildRequires: можно вычислить по configure.ac,
а разбивку на подпакеты по результатам 
make install

-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: [devel] Угрозы развитию дистрибутива. Пути решения.

[Egor Vyscrebentsov]

On Tue, 27 Sep 2011 14:42:36 +0300 Igor Vlasenko wrote:

> можно вычислить 
...
> разбивку на подпакеты по результатам 
> make install

В общем случае - нельзя.

$ rpm -qf /usr/bin/tolua++ 
tolua++-devel-1.0.93-alt1

=====

В отношении ранее сказанного, мне почему-то вспомнилась история
с freeciv, когда gtk-клиент с current stable gtk2 сегфолтился
будучи скомпилирован с -O2. Я не уверен, что подобное легко отследить
автоматическими методами. А главное - насколько я помню, оно ушло
собранным подобным образом в какой-то из [не альтовских] дистрибутивов.

-- 
WBR, Egor Vyscrebentsov

Re: [devel] Угрозы развитию дистрибутива. Пути решения.

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 1094 bytes --]

On Tue, Sep 27, 2011 at 05:34:07PM +0400, Egor Vyscrebentsov wrote:

EV> В отношении ранее сказанного, мне почему-то вспомнилась история
EV> с freeciv, когда gtk-клиент с current stable gtk2 сегфолтился
EV> будучи скомпилирован с -O2. Я не уверен, что подобное легко отследить
EV> автоматическими методами. А главное - насколько я помню, оно ушло
EV> собранным подобным образом в какой-то из [не альтовских] дистрибутивов.

Робот не может отследить все.
Робот не может гарантировать работу пакета.
Робот вообще не человек :)

Но робот может и должен сэкономить человеку времени на тупой,
повторяющейся работе, оставив ему место для поиска нетривиальных граблей
своим собственным лбом, ибо лоб робота недостаточно чувствительный для
этого :)

Идеальный подход, это когда роботы собирают вообще все подряд в
репозиторий a-la Daedalus, откуда потом умные мантейнеры либо делают copy,
либо пересобирают уже с конкретными исправлениями/улучшениями.

-- 
С уважением, Денис

http://mithraen.ru/
----------------------------------------------------------------------------


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]