[devel] Стабильный Сизиф

[devel] Стабильный Сизиф

[Fr. Br. George]

		Доколе?

0. Трудно работать, используя текущий Сизиф. Вечно в нём кто-нибудь что-нибудь
   разломает. А потом настанет лето, и оно так и залипнет. Плохо всем.
1. Хорошо бы, чтобы Сизиф хотя бы пару раз в год был неразломанный. Чтобы мы
   знали, когда экспериментировать с пакетами, а когда дотачивать их и гнать блох.
2. Это называется freeze, правда? Сначла догоняем usptream и синхронизируемся,
   потом ловим только блох, потом доводим и тестируем, потом отпускаем дальше.
3. Примерный график: месяц (или побольше) догоняем, месяц отлаживаем и месяц
   (или поменьше) тестируем. Даты должны быть известны всем заранее.
4. Лучшее время для всего цикла: сентябрь -- ноябрь и февраль -- апрель, плюс
   полмесяца запаса. Летом и зимой -- время разбрасывать камни.
5. Ещё раз: sync, freeze, testing, release -- это стадии Сизифа, а не
   какого-либо дистрибутива. Это для сообщества, для нас самих.
6. Дистрибутив -- это _отличия_ от Сизифа, которые его авторы доводят
   параллельно. Накатим отличия на стабильный Сизиф -- получим стабильный
   дистрибутив. Хоть сейчас в release.


		Примерный план-график рабочего цикла.

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

Июнь-Август		Эксперименты, сессия и отпуска.
Сентябрь		Sync
		Кидается клич: "Народ! Через месяц freeze! У вас всё готово?"
		Со словами "Какой там готово!" отдохнувший с лета народ
		принимается приводить в порядок дела. Возможно, сентября будет
		мало, заедем на октябрь.
Октябрь			Freeze
		Когда всё более-менее на уровне, объявляется заморозка.
		Все на блох! Обновления _версий_ пакетов допускаются только в
		крайнем случае (дыра в безопасности) или для специального
		класса пакетов (документация). Длится до тех пор, пока все
		release critical блохи не будут удушены.
Ноябрь			Testing
		Объявляется первый release candidate. Кидается клич:
		"Сообщество! Ты боялось нестабильного Сизифа? Этот --
		стабильный! Кто найдёт ошибку сегодня -- исправим завтра, кто
		поленится -- исправим только через полгода!". RC продолжают
		выпускаться до тех пор, пока не перестанут приходить release
		critical блохи, или пока не надоест.
Декабрь			Release
		(не позже середины декабря). Выпуск. Стабильный Сизиф
		оформляется в виде ветки. Если на ней выпущены какие-то
		дистрибутивы, ветка даже оказывается отчасти поддерживаемой.
		Сам Сизиф семимильными шагами движется в гору, навстречу
		новым блохам, зимней сессии и рождественским каникулам.
Январь			Эксперименты и сессия
Февраль			Sync
Март			Freeze
Апрель			Testing
Май			Release

-- 
			George V Kouryachy (aka Fr. Br. George)
			mailto:george at altlinux_ru

Re: [devel] [sisyphus -> devel] Стабильный Сизиф

[Fr. Br. George]

X-Post from sisyphus@
> > On Thu, Jun 15, 2006 at 10:01:50AM +0400, Anton Farygin wrote:
> Branch == стабилизированый Sisyphus. И работа над пакетами (ошибками) в 
> Branch'е должна быть более приоритетной, чем работа над пакетами в 
> Sisyphus. Ибо в данный момент речь идёт о том, что зачастую Sisyphus 
> пользоваться невозможно.
Полностью поддерживаю. Человека, который добровольно выбрал работу с
_таким_ Сизифом, трудно заставить работать на какую-то его ветку, из
которой ничего, кроме дистрибутива и техподдержки по нему, уже не
вырастет. Я не знаю, чем (кроме денег) можно заставить, например, меня.

Хуже того. Мне, как пользователю Сизифа, очень неудобно
переезжать время от времени на "ветку", сколь бы стабильной её не
обещали делать какие-то люди, к числу которых я не отношусь. Так что
стоит объявить, что Сизиф, дескать, нестабилен, а стабильны его "ветки",
и я немедленно потеряю интерес к release workflow -- зачем это мне?

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

> > При таком раскладе Branch становится твоей инициативой, а ты выступаешь
> > как release manager и берёшь большую часть ответственности на себя, а не
> > взваливаешь ее на других.  В общем-то кто угодно может сделать branch.
> Такой подход мне не нужен. Лопатить единолично несколько тысяч пакетов я 
> не собираюсь.
Это произойдёт в любом случае, если только ты не заставишь всё
сообщество каким-то чудом работать не на Сизиф, а на ветку. "После этого
чудо опухло и долго мешало ходить..." ((C) М.М.Исаев). И вот ветку-то
надо отщеплять от _стабильного_ Сизифа, чтобы вкручивать туда _только_ штуки,
необходимые для дистрибутива, но такие, которые сообществу сравнительно
по фигу. Дизайн, специальные настройки, искуйственный интеллект...

> >> При этом branch'и нужно делать более долгоиграющими.. что бы, например, 
> >> через полгода можно было выкладывать пакет не в updates, а в branch.
> > Можно сформулировать критерии, при которых "достаточно хорошие" пакеты
> > из сизифа (которые "ничего не ломают") автоматически перекладываются в
> > branch.
> автоматически ничего не бывает. Критерии стабильности должны определять 
> исключительно мантейнеры этих пакетов.
Вот именно. И покажите мне этих майнтейнеров. А главное -- заинтересуйте
их. Это следующий шаг, он требует намного больше дисциплины, чем у нас
есть. И средств мотивации, между прочим.

> Но для этого для начала нужно сделать что-то вроде GIT репозитария.
Да, это необходимо. Кстати, тем, кто ужасно хочет иметь Сизиф со всегда
незамороженными пакетами собственного производства GIT поможет как
родным.

-- 
			George V Kouryachy (aka Fr. Br. George)
			mailto:george at altlinux_ru

Re: [devel] [sisyphus -> devel] Стабильный Сизиф

[Valery V. Inozemtsev]

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

В сообщении от 15 июня 2006 14:22 Fr. Br. George написал(a):
> X-Post from sisyphus@
>
> > > On Thu, Jun 15, 2006 at 10:01:50AM +0400, Anton Farygin wrote:
> >
> > Branch == стабилизированый Sisyphus. И работа над пакетами (ошибками) в
> > Branch'е должна быть более приоритетной, чем работа над пакетами в
> > Sisyphus. Ибо в данный момент речь идёт о том, что зачастую Sisyphus
> > пользоваться невозможно.
>
> Полностью поддерживаю. Человека, который добровольно выбрал работу с
> _таким_ Сизифом, трудно заставить работать на какую-то его ветку, из
> которой ничего, кроме дистрибутива и техподдержки по нему, уже не
> вырастет. Я не знаю, чем (кроме денег) можно заставить, например, меня.
>
> Хуже того. Мне, как пользователю Сизифа, очень неудобно
> переезжать время от времени на "ветку", сколь бы стабильной её не
> обещали делать какие-то люди, к числу которых я не отношусь. Так что
> стоит объявить, что Сизиф, дескать, нестабилен, а стабильны его "ветки",
> и я немедленно потеряю интерес к release workflow -- зачем это мне?
>
> А вот выдержать месяц-два заморозки самого Сизифа, да и поработать в
> это время не на гонку за фичами, а на совместимость и более плотный
> багфикс, я вполне способен. Хотя бы just for fun, из соображений
> разнообразия видов деятельности. Важно только заранее знать, когда это
> время наступит, и не планировать ничего революционного.
>

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

-- 
Valery V. Inozemtsev

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

Re: [devel] [sisyphus -> devel] Стабильный Сизиф

[Led]

В сообщении от 15 июня 2006 13:22 Fr. Br. George написал(a):
> X-Post from sisyphus@
>
> > > On Thu, Jun 15, 2006 at 10:01:50AM +0400, Anton Farygin wrote:
> >
> > Branch == стабилизированый Sisyphus. И работа над пакетами (ошибками) в
> > Branch'е должна быть более приоритетной, чем работа над пакетами в
> > Sisyphus. Ибо в данный момент речь идёт о том, что зачастую Sisyphus
> > пользоваться невозможно.
>
> Полностью поддерживаю. Человека, который добровольно выбрал работу с
> _таким_ Сизифом, трудно заставить работать на какую-то его ветку, из
> которой ничего, кроме дистрибутива и техподдержки по нему, уже не
> вырастет. Я не знаю, чем (кроме денег) можно заставить, например, меня.

+1

>
> Хуже того. Мне, как пользователю Сизифа, очень неудобно
> переезжать время от времени на "ветку", сколь бы стабильной её не
> обещали делать какие-то люди, к числу которых я не отношусь. Так что
> стоит объявить, что Сизиф, дескать, нестабилен, а стабильны его "ветки",
> и я немедленно потеряю интерес к release workflow -- зачем это мне?
>
> А вот выдержать месяц-два заморозки самого Сизифа, да и поработать в
> это время не на гонку за фичами, а на совместимость и более плотный
> багфикс, я вполне способен.

ещё +1, но... Для более плотного багфикса бранча/фриза/или-как-там-его ИМХО 
необходим инструмент быстрой и минимально проблемной 
инсталляции/переинсталляции системы с ним; нужен иструмент, с помощью 
которого выполнив одну-две-три команды получить образ ISO9660 (CD, DVD, ...) 
с инсталляционной базой текущего бранча и инсталлятором. Методика "Установите 
Compact 3.0 и накатайте apt'ом до текущего состояния репозитария" довольно 
быстро исчерпывает терпение и после подобной "инсталляции" желание что-либо 
тестировать быстро пропадает; а когда в следующий раз думаешь 
что-либо "потестировать", "воспоминания" о том, как придётся опять "удобно 
инсталлировать" приводит к мыслям "а может позже? а может в следующий раз? а 
может его и тестировать не надо - и так вроде работает?".
Я понимаю, что здесь может получится некий конфликт интересов: любой сможет за 
несколько минут изготовить себе дистрибутив из текущего репозитария. Поэтому 
и не настаиваю на своём предложении :(

-- 
Led.

Re: [devel] [sisyphus -> devel] Стабильный Сизиф

[Anton Farygin]

Led wrote:
> В сообщении от 15 июня 2006 13:22 Fr. Br. George написал(a):
>> X-Post from sisyphus@
>>
>>>> On Thu, Jun 15, 2006 at 10:01:50AM +0400, Anton Farygin wrote:
>>> Branch == стабилизированый Sisyphus. И работа над пакетами (ошибками) в
>>> Branch'е должна быть более приоритетной, чем работа над пакетами в
>>> Sisyphus. Ибо в данный момент речь идёт о том, что зачастую Sisyphus
>>> пользоваться невозможно.
>> Полностью поддерживаю. Человека, который добровольно выбрал работу с
>> _таким_ Сизифом, трудно заставить работать на какую-то его ветку, из
>> которой ничего, кроме дистрибутива и техподдержки по нему, уже не
>> вырастет. Я не знаю, чем (кроме денег) можно заставить, например, меня.
> 
> +1
> 
>> Хуже того. Мне, как пользователю Сизифа, очень неудобно
>> переезжать время от времени на "ветку", сколь бы стабильной её не
>> обещали делать какие-то люди, к числу которых я не отношусь. Так что
>> стоит объявить, что Сизиф, дескать, нестабилен, а стабильны его "ветки",
>> и я немедленно потеряю интерес к release workflow -- зачем это мне?
>>
>> А вот выдержать месяц-два заморозки самого Сизифа, да и поработать в
>> это время не на гонку за фичами, а на совместимость и более плотный
>> багфикс, я вполне способен.
> 
> ещё +1, но... Для более плотного багфикса бранча/фриза/или-как-там-его ИМХО 
> необходим инструмент быстрой и минимально проблемной 
> инсталляции/переинсталляции системы с ним; нужен иструмент, с помощью 
> которого выполнив одну-две-три команды получить образ ISO9660 (CD, DVD, ...) 
> с инсталляционной базой текущего бранча и инсталлятором. Методика "Установите 
> Compact 3.0 и накатайте apt'ом до текущего состояния репозитария" довольно 
> быстро исчерпывает терпение и после подобной "инсталляции" желание что-либо 
> тестировать быстро пропадает; а когда в следующий раз думаешь 
> что-либо "потестировать", "воспоминания" о том, как придётся опять "удобно 
> инсталлировать" приводит к мыслям "а может позже? а может в следующий раз? а 
> может его и тестировать не надо - и так вроде работает?".
> Я понимаю, что здесь может получится некий конфликт интересов: любой сможет за 
> несколько минут изготовить себе дистрибутив из текущего репозитария. Поэтому 
> и не настаиваю на своём предложении :(
> 

Предложение правильное и у нас есть для этого сепаратор. Если не считать 
нескольких НО:

1) Не всегда содержимое Sisyphus настолько стабильно, что бы на его базе 
можно было бы собрать инсталяционный образ. Например - в данный момент 
это возможно только теоретически. На практике ничего не получится.
2) Для использования сепаратора необходимо постоянно иметь под рукой 
Sisyphus.

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

Rgds,
Rider

Re: [devel] [sisyphus -> devel] Стабильный Сизиф

[Led]

В сообщении от 15 июня 2006 14:03 Anton Farygin написал(a):
> Led wrote:
> > В сообщении от 15 июня 2006 13:22 Fr. Br. George написал(a):
> >> X-Post from sisyphus@
> >>
> >>>> On Thu, Jun 15, 2006 at 10:01:50AM +0400, Anton Farygin wrote:
> >>>
> >>> Branch == стабилизированый Sisyphus. И работа над пакетами (ошибками) в
> >>> Branch'е должна быть более приоритетной, чем работа над пакетами в
> >>> Sisyphus. Ибо в данный момент речь идёт о том, что зачастую Sisyphus
> >>> пользоваться невозможно.
> >>
> >> Полностью поддерживаю. Человека, который добровольно выбрал работу с
> >> _таким_ Сизифом, трудно заставить работать на какую-то его ветку, из
> >> которой ничего, кроме дистрибутива и техподдержки по нему, уже не
> >> вырастет. Я не знаю, чем (кроме денег) можно заставить, например, меня.
> >
> > +1
> >
> >> Хуже того. Мне, как пользователю Сизифа, очень неудобно
> >> переезжать время от времени на "ветку", сколь бы стабильной её не
> >> обещали делать какие-то люди, к числу которых я не отношусь. Так что
> >> стоит объявить, что Сизиф, дескать, нестабилен, а стабильны его "ветки",
> >> и я немедленно потеряю интерес к release workflow -- зачем это мне?
> >>
> >> А вот выдержать месяц-два заморозки самого Сизифа, да и поработать в
> >> это время не на гонку за фичами, а на совместимость и более плотный
> >> багфикс, я вполне способен.
> >
> > ещё +1, но... Для более плотного багфикса бранча/фриза/или-как-там-его
> > ИМХО необходим инструмент быстрой и минимально проблемной
> > инсталляции/переинсталляции системы с ним; нужен иструмент, с помощью
> > которого выполнив одну-две-три команды получить образ ISO9660 (CD, DVD,
> > ...) с инсталляционной базой текущего бранча и инсталлятором. Методика
> > "Установите Compact 3.0 и накатайте apt'ом до текущего состояния
> > репозитария" довольно быстро исчерпывает терпение и после подобной
> > "инсталляции" желание что-либо тестировать быстро пропадает; а когда в
> > следующий раз думаешь
> > что-либо "потестировать", "воспоминания" о том, как придётся опять
> > "удобно инсталлировать" приводит к мыслям "а может позже? а может в
> > следующий раз? а может его и тестировать не надо - и так вроде
> > работает?".
> > Я понимаю, что здесь может получится некий конфликт интересов: любой
> > сможет за несколько минут изготовить себе дистрибутив из текущего
> > репозитария. Поэтому и не настаиваю на своём предложении :(
>
> Предложение правильное и у нас есть для этого сепаратор.

Он есть, но далеко не всегда срабатывает даже с минимальным набором пакетов.

> Если не считать 
> нескольких НО:
>
> 1) Не всегда содержимое Sisyphus настолько стабильно, что бы на его базе
> можно было бы собрать инсталяционный образ. Например - в данный момент
> это возможно только теоретически. На практике ничего не получится.

А как на счёт внедрения схемы TRANSACT/COMMIT в incoming или между incoming и 
Sisyphus? Это вроде могло бы стабилизировать репозитарий хотя бы в плане 
целостности...

> 2) Для использования сепаратора необходимо постоянно иметь под рукой
> Sisyphus.

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

>
> Мне кажется что вариант с выпуском инсталлеров более интересен. Дельты
> маленькие. а выпуск инсталлера после того, как более-менее устаканится с
> альтератором и второй стадией - я могу поставить на поток - чуть ли не
> каждый день.

Хоть так бы. Хотя, "живой" сепаратор с набором скриптов тоже было бы 
неплохо...

-- 
Led.

Re: [devel] [sisyphus -> devel] Стабильный Сизиф

[Anton Farygin]

Led wrote:
> В сообщении от 15 июня 2006 14:03 Anton Farygin написал(a):
>> Led wrote:
>>> В сообщении от 15 июня 2006 13:22 Fr. Br. George написал(a):
>>>> X-Post from sisyphus@
>>>>
>>>>>> On Thu, Jun 15, 2006 at 10:01:50AM +0400, Anton Farygin wrote:
>>>>> Branch == стабилизированый Sisyphus. И работа над пакетами (ошибками) в
>>>>> Branch'е должна быть более приоритетной, чем работа над пакетами в
>>>>> Sisyphus. Ибо в данный момент речь идёт о том, что зачастую Sisyphus
>>>>> пользоваться невозможно.
>>>> Полностью поддерживаю. Человека, который добровольно выбрал работу с
>>>> _таким_ Сизифом, трудно заставить работать на какую-то его ветку, из
>>>> которой ничего, кроме дистрибутива и техподдержки по нему, уже не
>>>> вырастет. Я не знаю, чем (кроме денег) можно заставить, например, меня.
>>> +1
>>>
>>>> Хуже того. Мне, как пользователю Сизифа, очень неудобно
>>>> переезжать время от времени на "ветку", сколь бы стабильной её не
>>>> обещали делать какие-то люди, к числу которых я не отношусь. Так что
>>>> стоит объявить, что Сизиф, дескать, нестабилен, а стабильны его "ветки",
>>>> и я немедленно потеряю интерес к release workflow -- зачем это мне?
>>>>
>>>> А вот выдержать месяц-два заморозки самого Сизифа, да и поработать в
>>>> это время не на гонку за фичами, а на совместимость и более плотный
>>>> багфикс, я вполне способен.
>>> ещё +1, но... Для более плотного багфикса бранча/фриза/или-как-там-его
>>> ИМХО необходим инструмент быстрой и минимально проблемной
>>> инсталляции/переинсталляции системы с ним; нужен иструмент, с помощью
>>> которого выполнив одну-две-три команды получить образ ISO9660 (CD, DVD,
>>> ...) с инсталляционной базой текущего бранча и инсталлятором. Методика
>>> "Установите Compact 3.0 и накатайте apt'ом до текущего состояния
>>> репозитария" довольно быстро исчерпывает терпение и после подобной
>>> "инсталляции" желание что-либо тестировать быстро пропадает; а когда в
>>> следующий раз думаешь
>>> что-либо "потестировать", "воспоминания" о том, как придётся опять
>>> "удобно инсталлировать" приводит к мыслям "а может позже? а может в
>>> следующий раз? а может его и тестировать не надо - и так вроде
>>> работает?".
>>> Я понимаю, что здесь может получится некий конфликт интересов: любой
>>> сможет за несколько минут изготовить себе дистрибутив из текущего
>>> репозитария. Поэтому и не настаиваю на своём предложении :(
>> Предложение правильное и у нас есть для этого сепаратор.
> 
> Он есть, но далеко не всегда срабатывает даже с минимальным набором пакетов.
естественно не всегда. Сизиф то не стабилен. А выделять 100% времени на 
то, что бы фиксить все пакеты, необходимые сепаратору постоянно - я не 
могу.

Могу только пообещать сделать его работоспособным к фризу/бранчу.

> 
>> Если не считать 
>> нескольких НО:
>>
>> 1) Не всегда содержимое Sisyphus настолько стабильно, что бы на его базе
>> можно было бы собрать инсталяционный образ. Например - в данный момент
>> это возможно только теоретически. На практике ничего не получится.
> 
> А как на счёт внедрения схемы TRANSACT/COMMIT в incoming или между incoming и 
> Sisyphus? Это вроде могло бы стабилизировать репозитарий хотя бы в плане 
> целостности...

Нам бы для начала GIT внедрить...

> 
>> 2) Для использования сепаратора необходимо постоянно иметь под рукой
>> Sisyphus.
> 
> Для мэйнтейнера тоже нужно иметь под рукой текущий сизиф, а ещё лучше - с 
> ежедневными его "бэкапами" (у меня, например, это реализовано автоматически - 
> перед миррорингом сизифа делается бекап с помощью cp --link (для экономии 
> места)).

Для мантейнера совсем не обязательно иметь _весь_ сизиф.

> 
>> Мне кажется что вариант с выпуском инсталлеров более интересен. Дельты
>> маленькие. а выпуск инсталлера после того, как более-менее устаканится с
>> альтератором и второй стадией - я могу поставить на поток - чуть ли не
>> каждый день.
> 
> Хоть так бы. Хотя, "живой" сепаратор с набором скриптов тоже было бы 
> неплохо...
> 

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

Rgds,
Rider

Re: [devel] [sisyphus -> devel] Стабильный Сизиф

[Alexey Tourbin]

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

On Thu, Jun 15, 2006 at 02:50:05PM +0300, Led wrote:
> > 1) Не всегда содержимое Sisyphus настолько стабильно, что бы на его базе
> > можно было бы собрать инсталяционный образ. Например - в данный момент
> > это возможно только теоретически. На практике ничего не получится.
> 
> А как на счёт внедрения схемы TRANSACT/COMMIT в incoming или между incoming и 
> Sisyphus? Это вроде могло бы стабилизировать репозитарий хотя бы в плане 
> целостности...

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

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

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

Re: [devel] [sisyphus -> devel] Стабильный Сизиф

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

On Sat, Jun 17, 2006 at 02:17:45AM +0400, Алексей Турбин wrote:

AT> Какое количество априорной информации необходимо, чтобы автоматически
AT> начать транзакцию?  Любой unmet начинает транзакцию, которая завершается
AT> с его исчезновением?  В этом месте возникает "бифуркация", то есть сизиф
AT> "расслаивается" на две части.  В контексте каких транзакций тогда нужно
AT> собирать вновь поступающие пакеты?

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

Для разработчиков удобно иногда совершать действия, которые приводят к
появлению множества unmet'ов. Значит в сизифе наличие unmet'ов не
рекомендовано, но выносить в orphaned неустанавливаемый пакет можно не
ранее чем через 2 месяца (то бишь 8 недель), иначе разработчики в отпусках
по прибытию будут иметь проблемы.

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

Нам нужен второй репозиторий. В этот второй репозитория будут копироваться
группы пакетов (от одного и более) из Сизифа таким образом, чтобы в этом
репозитории не образовывалось unmet'ов. Никогда. Пакеты переносятся сразу
и исходные, и собраные из них _в контексте Сизифа_ бинарные.

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

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

Ответственно заявляю -- пакет, который нельзя установить, очень трудно
тестировать :)

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

http://freesource.info

Re: [devel] [sisyphus -> devel] Стабильный Сизиф

[Sergey Bolshakov]

>>>>> "mithraen" == mithraen  <mithraen@altlinux.ru> writes:
[skipped]

 > Нам нужен второй репозиторий. В этот второй репозитория будут копироваться
 > группы пакетов (от одного и более) из Сизифа таким образом, чтобы в этом
 > репозитории не образовывалось unmet'ов. Никогда. Пакеты переносятся сразу
 > и исходные, и собраные из них _в контексте Сизифа_ бинарные.

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

Бишь, предполагается, что в таком репозитарии будет соблюдаться
условие замкнутости и по сборочным зависимостям ? 

-- 

Re: [devel] [sisyphus -> devel] Стабильный Сизиф

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

On Sat, Jun 17, 2006 at 03:27:37PM +0400, Sergey Bolshakov wrote:

SB> Бишь, предполагается, что в таком репозитарии будет соблюдаться
SB> условие замкнутости и по сборочным зависимостям ? 

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

Собираемости -- однозначно нет.

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

http://freesource.info
----------------------------------------------------------------------------
Какой-то патч страшненький у тебя получился.
		-- ldv in #6099

Re: [devel] [sisyphus -> devel] Стабильный Сизиф

[Alexey Tourbin]

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

On Sat, Jun 17, 2006 at 03:20:59PM +0400, Денис Смирнов wrote:
> AT> Какое количество априорной информации необходимо, чтобы автоматически
> AT> начать транзакцию?  Любой unmet начинает транзакцию, которая завершается
> AT> с его исчезновением?  В этом месте возникает "бифуркация", то есть сизиф
> AT> "расслаивается" на две части.  В контексте каких транзакций тогда нужно
> AT> собирать вновь поступающие пакеты?
> 
> Сизиф -- репозитория для разработчиков. Это я беру за аксиому. Он должен
> быть максимально удобен для разработчиков и мантейнеров, и мнение всех
> остальных в контексте Сизифа учитываться не должно.

С такими аксиомами мы далеко не уедем.
Это вообще не аксиома в более точном смысле.
Я предлагаю обсуждать более алгоритмические идеи.

> Для разработчиков удобно иногда совершать действия, которые приводят к
> появлению множества unmet'ов. Значит в сизифе наличие unmet'ов не
> рекомендовано, но выносить в orphaned неустанавливаемый пакет можно не
> ранее чем через 2 месяца (то бишь 8 недель),

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

> Вывод -- Sisyphus это репозиторий где целостность _рекомендована_, но _не
> гарантируется_.

Это не дает ничего нового.

Я задаюсь вопросом: как блокировать unmet'ы на входе (в incominger'е)?

Допустим, пришёл пакет, после которого количество unmet'ов увеличивается.
По логике вещей такому пакету надо дать reject.  Но следом за ним идёт
другой пакет, после которого количество unmet'ов опять становится на
место.  Эти два пакета могут образовать "транзакцию".  Но если и после
двух этих пакетов количество unmet'ов станет более высоким, тогда уже
нелегко определить, какой именно из этих пакетов виноват.  Тогда
остается зарубить всю транзакцию.

В общем случае ситуация может быть ещё сложнее: пакет разрешает один
старый unmet и добавляет один новый.  Хороший это пакет или плохой?

> Нам нужен второй репозиторий. В этот второй репозитория будут копироваться
> группы пакетов (от одного и более) из Сизифа таким образом, чтобы в этом
> репозитории не образовывалось unmet'ов. Никогда.  Пакеты переносятся сразу
> и исходные, и собраные из них _в контексте Сизифа_ бинарные.

А пересобираемость в этом репозитарии важна?
И откуда уверенность, что процесс сходится?  Другими словами, откуда
уверенность, что в этот репозитарий через некоторое время хоть что-то
можно будет перенести?

И вообще, как определить "группы пакетов (от одного и более) из Сизифа",
после копирования которых в репозитарии не будет unmet'ов?   Это что
NP-полная задача?  Hint: при копировании пакета A или пакета B в
репозитарий unmet'ов не появляется, а при копировании A и B одновременно
unmet появляется.  Может такое быть?

Это остается только вручную всё делать, но вручную никто не будет.

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

Полную гарантию может дать только страховой полис.

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

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

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

Re: [devel] [sisyphus -> devel] Стабильный Сизиф

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

On Sat, Jun 17, 2006 at 04:33:13PM +0400, Алексей Турбин wrote:

>> Сизиф -- репозитория для разработчиков. Это я беру за аксиому. Он должен
>> быть максимально удобен для разработчиков и мантейнеров, и мнение всех
>> остальных в контексте Сизифа учитываться не должно.
AT> С такими аксиомами мы далеко не уедем.
AT> Это вообще не аксиома в более точном смысле.
AT> Я предлагаю обсуждать более алгоритмические идеи.

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

>> Для разработчиков удобно иногда совершать действия, которые приводят к
>> появлению множества unmet'ов. Значит в сизифе наличие unmet'ов не
>> рекомендовано, но выносить в orphaned неустанавливаемый пакет можно не
>> ранее чем через 2 месяца (то бишь 8 недель),
AT> Ты рассматриваешь простейший вариант, когда имеется непосредственный
AT> unmet, в котором виноват сам этот пакет, содержащий unmet.  Существуют
AT> другие варианты, когда пакет нельзя установить из-за unmet'ов в других
AT> пакетах "вниз по дереву" (или "вверх"?).

Обрати внимание на слова "не ранее". Ранее нельзя выносить даже виновных.

>> Вывод -- Sisyphus это репозиторий где целостность _рекомендована_, но _не
>> гарантируется_.
AT> Это не дает ничего нового.

Это описание того что есть сегодня.

AT> Я задаюсь вопросом: как блокировать unmet'ы на входе (в incominger'е)?
AT> Допустим, пришёл пакет, после которого количество unmet'ов увеличивается.
AT> По логике вещей такому пакету надо дать reject.  Но следом за ним идёт
AT> другой пакет, после которого количество unmet'ов опять становится на
AT> место.  Эти два пакета могут образовать "транзакцию".  Но если и после
AT> двух этих пакетов количество unmet'ов станет более высоким, тогда уже
AT> нелегко определить, какой именно из этих пакетов виноват.  Тогда
AT> остается зарубить всю транзакцию.

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

AT> В общем случае ситуация может быть ещё сложнее: пакет разрешает один
AT> старый unmet и добавляет один новый.  Хороший это пакет или плохой?

Мое мнение -- это не важно. Для репозитория который используют
разработчики это не имеет значения. Я выложил новую версию библиотеки,
которую я поддерживаю, значит все должны с этим смириться. Или положить
эту же библиотеку под другим именем другой версии. Это -- безусловный
факт, и наличие unmet'ов этот процесс тормозить не должно.

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

>> Нам нужен второй репозиторий. В этот второй репозитория будут копироваться
>> группы пакетов (от одного и более) из Сизифа таким образом, чтобы в этом
>> репозитории не образовывалось unmet'ов. Никогда.  Пакеты переносятся сразу
>> и исходные, и собраные из них _в контексте Сизифа_ бинарные.
AT> А пересобираемость в этом репозитарии важна?

Нет.

AT> И откуда уверенность, что процесс сходится?  Другими словами, откуда
AT> уверенность, что в этот репозитарий через некоторое время хоть что-то
AT> можно будет перенести?

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

AT> И вообще, как определить "группы пакетов (от одного и более) из Сизифа",
AT> после копирования которых в репозитарии не будет unmet'ов?   Это что
AT> NP-полная задача?  Hint: при копировании пакета A или пакета B в
AT> репозитарий unmet'ов не появляется, а при копировании A и B одновременно
AT> unmet появляется.  Может такое быть?
AT> Это остается только вручную всё делать, но вручную никто не будет.

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

>> Этот репозиторий может быть в любой момент использован кем угодно для
>> построения своих решений, потому как его целостность _гарантирована_.
AT> Полную гарантию может дать только страховой полис.

И хорошо продуманые алгоритмы с тестами на результат :)

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

Скриптом не напишу, логики шибко много. Это может написать либо тот, кто
умеет пользоваться libapt, либо кто имеет силы реализовать самостоятельно
всю логику проверки наличия unmet'ов в новом репозитории, не создавая его
физически.

А логика, которую я предлагаю, простая:

1. циклически проходимся по всему списку пакетов, которые есть в sisyphus
но их нет в этом репозитории, и пытаемся перенести пакеты поштучно.
Проходимся до тех пор, пока не окажется что не можем перевести ни один.

2. строим ассоциативных массив, в котором ключ это provides из sisyphus, а данные это список пакетов его предоставляющих.

3. опять проходимся по списку пакетов, пытаясь перенести пакет, вместе с
пакетами, которые ему требуются.

Есть идеи как это можно ещё оптимизировать, да и обрабатывать некоторые
сложные случаи. Для меня сложна пока задача, как быстро определить будет
ли новый репозиторий содержать unmet'ы, не создавая руками этот
репозиторий и не натравливая на него apt.

Вынесение пакета из репозитория обрабатывается тоже просто -- если
транзакция порождает unmet'ы для пакета, которого уже нет в sisyphus, то
эта транзакция является допустимой, и в ней же мы выносим этот пакет.

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

http://freesource.info
----------------------------------------------------------------------------
Настоящие демоны могут так fork'аться, что их потом без pid-файла не
найти.
		-- ldv in devel@

Re: [devel] [sisyphus -> devel] Стабильный Сизиф

[Michael Shigorin]

On Sun, Jun 18, 2006 at 04:36:50PM +0400, Денис Смирнов wrote:
> AT> Я предлагаю обсуждать более алгоритмические идеи.
> Нам нужен репозиторий для разработчиков. Sisyphus по факту
> выполняет эту задачу. Так как всех мантейнеров сажать на
> зарплату никто не собирается, им должно быть удобно. Иначе они
> просто уйдут.

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

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

> >> Для разработчиков удобно иногда совершать действия, которые
> >> приводят к появлению множества unmet'ов. Значит в сизифе
> >> наличие unmet'ов не рекомендовано, но выносить в orphaned
> >> неустанавливаемый пакет можно не ранее чем через 2 месяца
> >> (то бишь 8 недель),
> AT> Ты рассматриваешь простейший вариант, когда имеется непосредственный
> AT> unmet, в котором виноват сам этот пакет, содержащий unmet.  Существуют
> AT> другие варианты, когда пакет нельзя установить из-за unmet'ов в других
> AT> пакетах "вниз по дереву" (или "вверх"?).
> Обрати внимание на слова "не ранее". Ранее нельзя выносить даже виновных.

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

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

> AT> В общем случае ситуация может быть ещё сложнее: пакет разрешает один
> AT> старый unmet и добавляет один новый.  Хороший это пакет или плохой?
> Мое мнение -- это не важно. Для репозитория который используют
> разработчики это не имеет значения. Я выложил новую версию
> библиотеки, которую я поддерживаю, значит все должны с этим
> смириться. Или положить эту же библиотеку под другим именем
> другой версии. Это -- безусловный факт, и наличие unmet'ов этот
> процесс тормозить не должно.

Факт, но не согласующийся с заботой о коллегах.  Иногда бывают
дохлые, хотя полезные апстримы, и недостаток знаний для починки.
Выход -- параллельные версии библиотек, как это ни неприятно.
Но это тоже труд, особенно с учётом того, что предыдущая версия
скорее сломается в бегущем вперёд окружении (e.g. gcc).

> Такая ситуация может быть, и мне кажется что нам надо искать не
> "лучшее" решение, а просто приемлимое.

+1

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

Re: [devel] [sisyphus -> devel] Стабильный Сизиф

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

On Mon, Jun 19, 2006 at 11:44:10AM +0300, Michael Shigorin wrote:

MS> Бишь если более алгоритмические реализации создадут совсем много
MS> неудобств, то ещё несколько человек могут решить, что им такое
MS> качество не по карману.  Это уже бывало просто.  Не знаю, стоило
MS> ли того.
MS> В качестве решения может быть педаль для _человека_, поскольку
MS> автоматизировать принятие _любых_ решений невозможно.

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

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

Поэтому надо эти репозитории разделить.

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

Поэтому нужна автоматика. Которая не будет мешать ни одной стороне, а даст
результат. И логику такой автоматики я описал. Это не идеал, но
существенно лучше чем сложившаяся сейчас ситуация.

>>>> Для разработчиков удобно иногда совершать действия, которые
>>>> приводят к появлению множества unmet'ов. Значит в сизифе
>>>> наличие unmet'ов не рекомендовано, но выносить в orphaned
>>>> неустанавливаемый пакет можно не ранее чем через 2 месяца
>>>> (то бишь 8 недель),
> AT>> Ты рассматриваешь простейший вариант, когда имеется непосредственный
> AT>> unmet, в котором виноват сам этот пакет, содержащий unmet.  Существуют
> AT>> другие варианты, когда пакет нельзя установить из-за unmet'ов в других
> AT>> пакетах "вниз по дереву" (или "вверх"?).
>> Обрати внимание на слова "не ранее". Ранее нельзя выносить даже виновных.
MS> Бишь мы получаем, что разгребение бардака методом несоздания на
MS> данном этапе скорее просто заступорит разработку вообще.  Без
NS> рабочего варианта решения "как плюхнуть новую библиотеку, которая
MS> цепляет пол-сизифа".

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

MS> В принципе, когда-то Sisyphus характеризовался как замкнутый
MS> репозиторий.  Не знаю, насколько это соответствовало реальности, 
MS> но сейчас давно не соответствует (и стоило бы убрать из
MS> официальных страничек).

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

> AT>> В общем случае ситуация может быть ещё сложнее: пакет разрешает один
> AT>> старый unmet и добавляет один новый.  Хороший это пакет или плохой?
>> Мое мнение -- это не важно. Для репозитория который используют
>> разработчики это не имеет значения. Я выложил новую версию
>> библиотеки, которую я поддерживаю, значит все должны с этим
>> смириться. Или положить эту же библиотеку под другим именем
>> другой версии. Это -- безусловный факт, и наличие unmet'ов этот
>> процесс тормозить не должно.
MS> Факт, но не согласующийся с заботой о коллегах.  Иногда бывают
MS> дохлые, хотя полезные апстримы, и недостаток знаний для починки.
MS> Выход -- параллельные версии библиотек, как это ни неприятно.
MS> Но это тоже труд, особенно с учётом того, что предыдущая версия
MS> скорее сломается в бегущем вперёд окружении (e.g. gcc).

Я это понимаю :) Но обычно с этой библиотекой действительно _надо_
пересобрать пол сизифа. Только на пользователях другой половины Сизифа это
отражаться не должно.

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

http://freesource.info
----------------------------------------------------------------------------

[devel] debian query language (was: Стабильный Сизиф)

[Michael Shigorin]

On Sat, Jun 17, 2006 at 04:33:13PM +0400, Alexey Tourbin wrote:
> Я предлагаю обсуждать более алгоритмические идеи.

(abusing the thread)  Кстати, попалось тут на глаза:

---

Debian Query Language. Berke Durak from the French National
[7]Institute for Research in Computer Science and Control is
[8]seeking feedback and ideas for defining a query language that
would be useful to maintainers, power-users and researchers. They have
already developed a [9]dependency checker based on boolean form.
Tools for handling the Debian meta data with its evolution in time are
also being implemented.

 7. http://www.inria.fr/
 8. http://lists.debian.org/debian-devel/2006/05/msg01912.html
 9. http://bugs.debian.org/365087
---

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

-- 
PS: единственный старый ламер-дантист,
к которому меня угораздило попасть
в лапы, имел фамилию Криворук...
но тогда это предупреждение
было проигнорировано.

Re: [devel] debian query language (was: Стабильный Сизиф)

[Michael Shigorin]

On Wed, Jun 28, 2006 at 08:47:48AM +0300, I wrote:
> > Я предлагаю обсуждать более алгоритмические идеи.
> (abusing the thread)  Кстати, попалось тут на глаза:

И ещё оттуда же (http://lwn.net/Articles/189364/):

http://packages.debian.org/unstable/devel/edos-rpmcheck
edos-rpmcheck -- Checks whether dependencies of Red Hat packages
can be satisfied.

http://packages.debian.org/unstable/devel/mock
mock -- Build RPM packages inside a chroot.

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

Re: [devel] debian query language (was: Стабильный Сизиф)

[Alexey Tourbin]

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

On Wed, Jun 28, 2006 at 09:05:10AM +0300, Michael Shigorin wrote:
> http://packages.debian.org/unstable/devel/edos-rpmcheck
> edos-rpmcheck -- Checks whether dependencies of Red Hat packages
> can be satisfied.

+.SH OPTIONS                                                                                                                                 
+.TP                                                                                                                                         
+.B -check                                                                                                                                   
+Double-check the results                                                                                                                    

Гы-гы.  Я не верю судьбе а себе ещё меньше.

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

Re: [devel] [sisyphus -> devel] Стабильный Сизиф

[Michael Shigorin]

On Sat, Jun 17, 2006 at 03:20:59PM +0400, Денис Смирнов wrote:
> Сизиф -- репозитория для разработчиков. Это я беру за аксиому.
> Он должен быть максимально удобен для разработчиков и
> мантейнеров, и мнение всех остальных в контексте Сизифа
> учитываться не должно.

Но может.

> Например компакту гарантии возможности пересобрать любой пакет
> в своем окружении не обязательны (AFAIK).

Но очень помогает, если всё-таки получается... долго думал, когда
поймал непересобираемость gnome2-utils на 3.0 (а надо было патчить).

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

Re: [devel] [sisyphus -> devel] Стабильный Сизиф

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

On Mon, Jun 19, 2006 at 11:33:57AM +0300, Michael Shigorin wrote:
>> Сизиф -- репозитория для разработчиков. Это я беру за аксиому.
>> Он должен быть максимально удобен для разработчиков и
>> мантейнеров, и мнение всех остальных в контексте Сизифа
>> учитываться не должно.
MS> Но может.

Может. Но приоритетны для именно Сизифа -- разработчики и их удобство.

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

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

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

http://freesource.info
----------------------------------------------------------------------------

Re: [devel] [sisyphus -> devel] Стабильный Сизиф

[Michael Shigorin]

On Sat, Jun 17, 2006 at 02:17:45AM +0400, Alexey Tourbin wrote:
> Как вы себе представляете идею с транзакциями?  Напишите подробнее.

Поищи мои письма про RPMS.incoming.  И поспрошай Большакова про
карманы (pockets) в sandman.

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

Да, метод "пофантазировать" порой неплохо помогает :-)
Если его применением не заканчивается.

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

По-умолчанию -- в "большом" сизифе.  Возможно, получится как-то
автоматизировать процесс перемещения пакета в песочницу с новой
libA (где её как раз колбасят), если в его BuildRequires она
прямо (или даже косвенно) висит.

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

Re: [devel] [sisyphus -> devel] Стабильный Сизиф

[Alexey I. Froloff]

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

* Michael Shigorin <mike@> [060619 12:40]:
> > Как вы себе представляете идею с транзакциями?  Напишите подробнее.
> Поищи мои письма про RPMS.incoming.  И поспрошай Большакова про
> карманы (pockets) в sandman.
Это взаимоперпендикулярные понятия.  pocket в sandman это аналог
--repo + --with-stuff в hasher.  А RPMS.incoming это общий repo
для всех hasher'ов (beehive таки распределённая система в отличие
от).

-- 
Regards,
Sir Raorn.

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

Re: [devel] [sisyphus -> devel] Стабильный Сизиф

[Michael Shigorin]

On Mon, Jun 19, 2006 at 12:54:40PM +0400, Alexey I. Froloff wrote:
> > > Как вы себе представляете идею с транзакциями?  Напишите
> > > подробнее.
> > Поищи мои письма про RPMS.incoming.  И поспрошай Большакова
> > про карманы (pockets) в sandman.
> Это взаимоперпендикулярные понятия.

Не совсем, скорее тонко/толсторезаное одно и то же.

> pocket в sandman это аналог --repo + --with-stuff в hasher.
> А RPMS.incoming это общий repo для всех hasher'ов (beehive таки
> распределённая система в отличие от).

Предлагался как по крайней мере big repo lock, который на самом
деле unlock по части unmets.  Вроде бы вполне понятно, что такое
может помочь при ситуации "упала 1 (одна) бомба, жертв и
разрушений -- полсизифе".

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

Последний раз проблемы были вроде как в apt, но с другой стороны 
-- дистрибутив + updates разве не ту же проблему ставят? (двойные
версии)

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

Re: [devel] [sisyphus -> devel] Стабильный Сизиф

[Alexey I. Froloff]

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

* Michael Shigorin <mike@> [060619 13:31]:
> Предлагался как по крайней мере big repo lock, который на самом
> деле unlock по части unmets.
Попытайся описать цикл работы с этим repo в виде пригодном к
скриптованию.

P.S. Описание должно быть пригодно с скриптованию, а не собсно
цикл ;-)

-- 
Regards,
Sir Raorn.

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

Re: [devel] [sisyphus -> devel] Стабильный Сизиф

[Michael Shigorin]

On Mon, Jun 19, 2006 at 01:34:49PM +0400, Alexey I. Froloff wrote:
> > Предлагался как по крайней мере big repo lock, который на
> > самом деле unlock по части unmets.
> Попытайся описать цикл работы с этим repo в виде пригодном к
> скриптованию.

0. исходное состояние: в этом repo пусто.
1. возникает надобность временно насоздавать unmets, о чём
   делается объявление в devel@ со списком задетых пакетов 
   и востребованных майнтейнеров (хорошо -- с уже известными
   типами проблем, характерными ошибками сборки/работы и совсем
   идеально -- с рекомендациями по исправлению таковых).
2. корневая причина (e.g. libA новой версии) вливается в пусть
   /incoming/Sisyphus/sandbox/; туда же заливаются по мере
   подготовки пакеты, которые требуют пересборки с новой libA,
   майнтейнерами по мере исправления и роботами по мере
   подтверждения успеха (?)
3. идут оперативные автоматические пересборки этого repo с ним
   самим включительно (это было ключевым, когда incoming
   запускался на обработку вручную раз в сутки; сейчас может
   быть проще ввесить отдельную разгребалку, поскольку по факту
   она уже создана -- так, Лёш?); логи "как сейчас сделано для
   Sisyphus" рассылаются так же.
4. когда список исходных пакетов, который был выделен по
   результатам тестовой пересборки или спрогнозирован по пакетным
   зависимостям на уходящий soname или иной признак, совпадает
   со списком в песочнице+orphaned полностью (что определяемо
   автоматически?) или в достаточной мере, определяемой incoming@
   -- происходит перекладывание пакетов в Sisyphus, очистка
   sandbox/ и объявляется техническая возможность для следующего
   переворота.
5. init 0 ;-)

Здесь есть несколько мест, которые мне с моими знаниями о
технической стороне текущей организации не нравятся или непонятны
(2 legion: нет, не добрался почитать); плюс временные рамки на
существование такого переездного репозитория тоже чем-то надо
ограничить (месяцем? -- за сколько у нас более-менее исправляются
крупные разломы?).

Вот ещё по теме:
http://lists.altlinux.org/pipermail/devel/2004-October/014806.html
http://lists.altlinux.org/pipermail/sisyphus/2004-January/034511.html
http://lists.altlinux.org/pipermail/devel/2005-October/025144.html
http://lists.altlinux.org/pipermail/devel/2006-March/030521.html

Также под руку попалось:
http://lists.altlinux.org/pipermail/devel/2005-April/019638.html
http://lists.altlinux.org/pipermail/devel/2004-October/014815.html
http://lists.altlinux.org/pipermail/sisyphus/2004-January/034675.html

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

Re: [devel] [sisyphus -> devel] Стабильный Сизиф

[Led]

В сообщении от 17 июня 2006 01:17 Alexey Tourbin написал(a):
> On Thu, Jun 15, 2006 at 02:50:05PM +0300, Led wrote:
> > > 1) Не всегда содержимое Sisyphus настолько стабильно, что бы на его
> > > базе можно было бы собрать инсталяционный образ. Например - в данный
> > > момент это возможно только теоретически. На практике ничего не
> > > получится.
> >
> > А как на счёт внедрения схемы TRANSACT/COMMIT в incoming или между
> > incoming и Sisyphus? Это вроде могло бы стабилизировать репозитарий хотя
> > бы в плане целостности...
>
> Как вы себе представляете идею с транзакциями?  Напишите подробнее.
> Причем (сразу хинт) исходите не из желаемого, а попытайтесь понять,
> какие трудности могут возникнуть в реализации.  Это интересно.
>
> Какое количество априорной информации необходимо, чтобы автоматически
> начать транзакцию?  Любой unmet начинает транзакцию, которая завершается
> с его исчезновением?  В этом месте возникает "бифуркация", то есть сизиф
> "расслаивается" на две части.  В контексте каких транзакций тогда нужно
> собирать вновь поступающие пакеты?

-- 
Led.

Re: [devel] [sisyphus -> devel] Стабильный Сизиф

[Led]

В сообщении от 17 июня 2006 01:17 Alexey Tourbin написал(a):
> On Thu, Jun 15, 2006 at 02:50:05PM +0300, Led wrote:
> > > 1) Не всегда содержимое Sisyphus настолько стабильно, что бы на его
> > > базе можно было бы собрать инсталяционный образ. Например - в данный
> > > момент это возможно только теоретически. На практике ничего не
> > > получится.
> >
> > А как на счёт внедрения схемы TRANSACT/COMMIT в incoming или между
> > incoming и Sisyphus? Это вроде могло бы стабилизировать репозитарий хотя
> > бы в плане целостности...
>
> Как вы себе представляете идею с транзакциями?  Напишите подробнее.
> Причем (сразу хинт) исходите не из желаемого, а попытайтесь понять,
> какие трудности могут возникнуть в реализации.  Это интересно.
>
> Какое количество априорной информации необходимо, чтобы автоматически
> начать транзакцию?  Любой unmet начинает транзакцию, которая завершается
> с его исчезновением?  В этом месте возникает "бифуркация", то есть сизиф
> "расслаивается" на две части.  В контексте каких транзакций тогда нужно
> собирать вновь поступающие пакеты?

Основные проблемы возникать могут при поступлении в incoming библиотеки с 
новым soname.
Упрощённо алгоритм обработки "транзакции" вижу таким образом
1) Была libfoo с libfoo.so.x, от которой зависят пакеты в репозитарии.
2) В incoming пришла libfoo м libfoo.so.y.
3) Попытка пересобрать зависимые пакеты роботом с вновь поступившей libfoo
4) Если попытка полностью успешна - commit
5) Если попытка (п.3) полностью или частично НЕуспешна - уведомить мэйнтейнера 
libfoo и зависимых пакетов.
6) После уведомления мэйнтейнера libfoo (п.5), он должен собрать libfoo_X 
(очень желателен скрипт-инструмент для изготовления libfoo_X.spec из 
libfoo.spec, хотя бы частично автоматизирующий эту работу).
7) После уведомления мэйнтейнеры зависимых от libfoo пакетов пересобирают свои 
пакеты с libfoo.so.y.
8) В случае невозможности п.7 - мэйнтейнеры зависимых от libfoo пересобирают 
свои пакеты с libfoo_X, или (как вариант, на котором я не настаиваю, потому 
как "закидают гнилыми помидорами" - с libfoo.a версии X).
9) Если п.7 или п.8 успешны - commit.

Сорри, может что-то упустил - со стороны будет виднее.

Можете "пинать" ("пинки" с оскрблениями, в т.ч. в личку будут 
проигнорированны).

-- 
Led.

Re: [devel] [sisyphus -> devel] Стабильный Сизиф

[Alexey Tourbin]

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

On Mon, Jun 19, 2006 at 01:12:37PM +0300, Led wrote:
> Основные проблемы возникать могут при поступлении в incoming библиотеки с 
> новым soname.
> Упрощённо алгоритм обработки "транзакции" вижу таким образом
> 1) Была libfoo с libfoo.so.x, от которой зависят пакеты в репозитарии.
> 2) В incoming пришла libfoo м libfoo.so.y.
> 3) Попытка пересобрать зависимые пакеты роботом с вновь поступившей libfoo
> 4) Если попытка полностью успешна - commit
> 5) Если попытка (п.3) полностью или частично НЕуспешна - уведомить мэйнтейнера 
> libfoo и зависимых пакетов.
> 6) После уведомления мэйнтейнера libfoo (п.5), он должен собрать libfoo_X 
> (очень желателен скрипт-инструмент для изготовления libfoo_X.spec из 
> libfoo.spec, хотя бы частично автоматизирующий эту работу).

Либо помочь исправить пакеты, которые не удается собрать с libfoo.so.y.

> 7) После уведомления мэйнтейнеры зависимых от libfoo пакетов пересобирают свои 
> пакеты с libfoo.so.y.
> 8) В случае невозможности п.7 - мэйнтейнеры зависимых от libfoo пересобирают 
> свои пакеты с libfoo_X, или (как вариант, на котором я не настаиваю, потому 
> как "закидают гнилыми помидорами" - с libfoo.a версии X).
> 9) Если п.7 или п.8 успешны - commit.

Это разумно.  Это наводит на кое-какие мысли насчет модульной структуры
incominger'а.  То есть в данном случае после сборки каждого пакета
incominger должен попытаться обнаружить смену сонейма.  Если смена
сонейма обнаружена, в репозитарии генерируется некоторый абстрактный
"сигнал", который распространяется (propagate) на все остальные пакеты
и который система пытается обработать.  Зачатки этого подхода описаны
здесь: http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-22.html#%_sec_3.3.4

По существу не ясно, чем гарантируется смена сонейма в конечное время.
То есть пункты 6, 7, 8 могут занять месяц, два, три...  Если для смены
каждого сонейма формировать отдельный отстойник и коммитить его целиком
только тогда, когда проблема будет полностью решена, тогда возможны
новые проблемы.  Допустим приходит новый пакет, который зависит от двух
отстойников ("транзакций").  Вопрос такой: к какому отстойнку его
отнести?  Нужно уже формировать "объединение" двух отстойников.
Если развить мысль (исходя из того, что полная смена сонейма занимает
довольно долгое время), то "объединение" нескольких отстойников
в конечном счете даст один большой новый отстойник, который до конца
переместить в сизиф никогда не удатся.  То есть будет "затык" в
альтернативном сизифе, который никак не удается слить в основной сизиф.

> Можете "пинать" ("пинки" с оскрблениями, в т.ч. в личку будут 
> проигнорированны).

Уже лучше чем про фортран и sisyphus-full. :)

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

Re: [devel] [sisyphus -> devel] Стабильный Сизиф

[Led]

В сообщении от 19 июня 2006 15:12 Alexey Tourbin написал(a):
> On Mon, Jun 19, 2006 at 01:12:37PM +0300, Led wrote:
> > Основные проблемы возникать могут при поступлении в incoming библиотеки с
> > новым soname.
> > Упрощённо алгоритм обработки "транзакции" вижу таким образом
> > 1) Была libfoo с libfoo.so.x, от которой зависят пакеты в репозитарии.
> > 2) В incoming пришла libfoo м libfoo.so.y.
> > 3) Попытка пересобрать зависимые пакеты роботом с вновь поступившей
> > libfoo 4) Если попытка полностью успешна - commit
> > 5) Если попытка (п.3) полностью или частично НЕуспешна - уведомить
> > мэйнтейнера libfoo и зависимых пакетов.
> > 6) После уведомления мэйнтейнера libfoo (п.5), он должен собрать libfoo_X
> > (очень желателен скрипт-инструмент для изготовления libfoo_X.spec из
> > libfoo.spec, хотя бы частично автоматизирующий эту работу).
>
> Либо помочь исправить пакеты, которые не удается собрать с libfoo.so.y.
>
> > 7) После уведомления мэйнтейнеры зависимых от libfoo пакетов пересобирают
> > свои пакеты с libfoo.so.y.
> > 8) В случае невозможности п.7 - мэйнтейнеры зависимых от libfoo
> > пересобирают свои пакеты с libfoo_X, или (как вариант, на котором я не
> > настаиваю, потому как "закидают гнилыми помидорами" - с libfoo.a версии
> > X).
> > 9) Если п.7 или п.8 успешны - commit.
>
> Это разумно.  Это наводит на кое-какие мысли насчет модульной структуры
> incominger'а.  То есть в данном случае после сборки каждого пакета
> incominger должен попытаться обнаружить смену сонейма.  Если смена
> сонейма обнаружена, в репозитарии генерируется некоторый абстрактный
> "сигнал", который распространяется (propagate) на все остальные пакеты
> и который система пытается обработать.  Зачатки этого подхода описаны
> здесь:
> http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-22.html#%_sec_3.3.4
>
> По существу не ясно, чем гарантируется смена сонейма в конечное время.
> То есть пункты 6, 7, 8 могут занять месяц, два, три...

А это и есть пресловутый "человеческий фактор" - без него никак :( Чтоб не 
было "месяц-два-три" и привёл пункт 6. Либо новая libfoo не пропускается 
вобще, либо мэйнтейнеру нужно немножко озадачиться изготовлением libfoo_X 
(думаю, если продумать policy на libfoo => libfoo_X, то и "заскриптовать" это 
будет возможно).

> Если для смены 
> каждого сонейма формировать отдельный отстойник и коммитить его целиком
> только тогда, когда проблема будет полностью решена, тогда возможны
> новые проблемы.  Допустим приходит новый пакет, который зависит от двух
> отстойников ("транзакций").  Вопрос такой: к какому отстойнку его
> отнести?  Нужно уже формировать "объединение" двух отстойников.
> Если развить мысль (исходя из того, что полная смена сонейма занимает
> довольно долгое время), то "объединение" нескольких отстойников
> в конечном счете даст один большой новый отстойник, который до конца
> переместить в сизиф никогда не удатся.  То есть будет "затык" в
> альтернативном сизифе, который никак не удается слить в основной сизиф.

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

>
> > Можете "пинать" ("пинки" с оскрблениями, в т.ч. в личку будут
> > проигнорированны).
>
> Уже лучше чем про фортран и sisyphus-full. :)

Я уже понял, что кроме смайликов надо ещё слово "ЛОПАТА" ставить, чтоб не 
нарваться:)

-- 
Led.

Re: [devel] [sisyphus -> devel] Стабильный Сизиф

[Alexey Tourbin]

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

On Mon, Jun 19, 2006 at 03:26:26PM +0300, Led wrote:
> > По существу не ясно, чем гарантируется смена сонейма в конечное время.
> > То есть пункты 6, 7, 8 могут занять месяц, два, три...
> 
> А это и есть пресловутый "человеческий фактор" - без него никак :( Чтоб не 
> было "месяц-два-три" и привёл пункт 6. Либо новая libfoo не пропускается 
> вобще, либо мэйнтейнеру нужно немножко озадачиться изготовлением libfoo_X 
> (думаю, если продумать policy на libfoo => libfoo_X, то и "заскриптовать" это 
> будет возможно).

Кстати изготовление отдельного пакета libfoo_X в ряде случаев
нежелательно.  Потому что библиотеки libfoo_X и libfoo_Y могут оказаться
в одном адресном пространстве, что может быть фатальным.  Гипотетический
пример: библиотека libbar зависит от glib1, а библиотека libbaz зависит
от glib2.  Приложение, которое использует libbar и libbaz одновременно,
загружает в свое адресное пространство сразу glib1 и glib2.  Я не знаю,
насклько ELF/ld.so умеет или пытается разруливать такие ситуации, но в
общем-то ясно, что это может кончиться очень плохо.

> > Если для смены 
> > каждого сонейма формировать отдельный отстойник и коммитить его целиком
> > только тогда, когда проблема будет полностью решена, тогда возможны
> > новые проблемы.  Допустим приходит новый пакет, который зависит от двух
> > отстойников ("транзакций").  Вопрос такой: к какому отстойнку его
> > отнести?  Нужно уже формировать "объединение" двух отстойников.
> > Если развить мысль (исходя из того, что полная смена сонейма занимает
> > довольно долгое время), то "объединение" нескольких отстойников
> > в конечном счете даст один большой новый отстойник, который до конца
> > переместить в сизиф никогда не удатся.  То есть будет "затык" в
> > альтернативном сизифе, который никак не удается слить в основной сизиф.
> 
> Возможно "отстойник" стОит "залочить" от "внешего вмешательства", т.е. пока 
> транзакция не завершена, ничего увеличивающего энтропию в неё не добавлять.

Что значит залочить от внешнего вмешательства?  То есть допустим
сменился soname у libjpeg, и под это дело выделяется отдельный
отстойник, пока все пакеты не будут пересобраны с новым libjpeg.

Вновь посутпающие пакеты должны пересобираться в отстойнике или
на сизифе без отстойника?  Очевидно, в отстойнике, иначе не выполняется
требование завершения транзакции (все пакеты должны пересобраться с
новой библиотекой libjpeg).

Через месяц меняется soname у libssl.  Транзакция по libjpeg ещё не
завершена.  Нужно формировать новый отстойник для libssl, или вообще
зарубить libssl на том основании, что "отстойник залочен", т.е. в
отдельный момент времени нельзя допускать более одной тразакции по смене
сонейма?

Допустим, есть два отстойника (уже пересказываю) по libjpeg и libssl.
Теперь идёт пакет, который зависит одновременно от libjpeg и libssl.
В каком отстойнике собирать этот пакет?  Очевидно, что условие
завершения одной из транзакций будет нарушено.  Тогда нужно слить два
этих отстойника вместе и собирать этот пакет на объединенном отстойнике
libjpeg+libssl.  После этого условие завершения объединенной транзакции
становится гораздо сложнее.  Короче, слияние отстойников формирует
"параллельный сизиф", а транзакцию по объединенному отстойнику завершить
никогда не удается.

Так можно ли автоматически бороться с анметами (то есть существует ли
более тонкий автоматический критерий, чем просто давать reject пакетам,
которые увеличивают количество анметов)?

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

Re: [devel] [sisyphus -> devel] Стабильный Сизиф

[Led]

В сообщении от 19 июня 2006 16:03 Alexey Tourbin написал(a):
> On Mon, Jun 19, 2006 at 03:26:26PM +0300, Led wrote:
> > > По существу не ясно, чем гарантируется смена сонейма в конечное время.
> > > То есть пункты 6, 7, 8 могут занять месяц, два, три...
> >
> > А это и есть пресловутый "человеческий фактор" - без него никак :( Чтоб
> > не было "месяц-два-три" и привёл пункт 6. Либо новая libfoo не
> > пропускается вобще, либо мэйнтейнеру нужно немножко озадачиться
> > изготовлением libfoo_X (думаю, если продумать policy на libfoo =>
> > libfoo_X, то и "заскриптовать" это будет возможно).
>
> Кстати изготовление отдельного пакета libfoo_X в ряде случаев
> нежелательно.  Потому что библиотеки libfoo_X и libfoo_Y могут оказаться
> в одном адресном пространстве, что может быть фатальным.  Гипотетический
> пример: библиотека libbar зависит от glib1, а библиотека libbaz зависит
> от glib2.  Приложение, которое использует libbar и libbaz одновременно,
> загружает в свое адресное пространство сразу glib1 и glib2.  Я не знаю,
> насклько ELF/ld.so умеет или пытается разруливать такие ситуации, но в
> общем-то ясно, что это может кончиться очень плохо.
>
> > > Если для смены
> > > каждого сонейма формировать отдельный отстойник и коммитить его целиком
> > > только тогда, когда проблема будет полностью решена, тогда возможны
> > > новые проблемы.  Допустим приходит новый пакет, который зависит от двух
> > > отстойников ("транзакций").  Вопрос такой: к какому отстойнку его
> > > отнести?  Нужно уже формировать "объединение" двух отстойников.
> > > Если развить мысль (исходя из того, что полная смена сонейма занимает
> > > довольно долгое время), то "объединение" нескольких отстойников
> > > в конечном счете даст один большой новый отстойник, который до конца
> > > переместить в сизиф никогда не удатся.  То есть будет "затык" в
> > > альтернативном сизифе, который никак не удается слить в основной сизиф.
> >
> > Возможно "отстойник" стОит "залочить" от "внешего вмешательства", т.е.
> > пока транзакция не завершена, ничего увеличивающего энтропию в неё не
> > добавлять.
>
> Что значит залочить от внешнего вмешательства?  То есть допустим
> сменился soname у libjpeg, и под это дело выделяется отдельный
> отстойник, пока все пакеты не будут пересобраны с новым libjpeg.
>
> Вновь посутпающие пакеты должны пересобираться в отстойнике или
> на сизифе без отстойника?  Очевидно, в отстойнике, иначе не выполняется
> требование завершения транзакции (все пакеты должны пересобраться с
> новой библиотекой libjpeg).
>
> Через месяц меняется soname у libssl.  Транзакция по libjpeg ещё не
> завершена.  Нужно формировать новый отстойник для libssl, или вообще
> зарубить libssl на том основании, что "отстойник залочен", т.е. в
> отдельный момент времени нельзя допускать более одной тразакции по смене
> сонейма?
>
> Допустим, есть два отстойника (уже пересказываю) по libjpeg и libssl.
> Теперь идёт пакет, который зависит одновременно от libjpeg и libssl.
> В каком отстойнике собирать этот пакет?  Очевидно, что условие
> завершения одной из транзакций будет нарушено.  Тогда нужно слить два
> этих отстойника вместе и собирать этот пакет на объединенном отстойнике
> libjpeg+libssl.  После этого условие завершения объединенной транзакции
> становится гораздо сложнее.  Короче, слияние отстойников формирует
> "параллельный сизиф", а транзакцию по объединенному отстойнику завершить
> никогда не удается.
>
> Так можно ли автоматически бороться с анметами (то есть существует ли
> более тонкий автоматический критерий, чем просто давать reject пакетам,
> которые увеличивают количество анметов)?

Ок, попробую объяснить по другому (вариант libfoo_X для упрощения пока не 
учитываю - он был приведён как временное решение, "костыль" для быстрейшего 
(надеюсь, только в некоторых случаях) завершения транзакции в 
случае "ленивости" мэйнтейнеров зависимых пакетов):
1) Термин "отстойник" и то, что вы в него вкладываете не совсем подходит
2) Предлагается термины "очередь" и "триггер".
3) libfoo с новым soname, поступающая в incoming (и, естественно, прошедшая 
сборку в хешере), устанавливает триггер, по которому все собранные уже с ней 
пакеты ставятся в очередь, триггер снимается и эти пакеты проходят в основной 
репозитарий только после прохождения в этот репозитрарий самой libfoo.
4) Если какой-либо пакет зависит (в момент поступления в incoming) от двух или 
нескольких библиотек, находящихся в "режиме ожидания", то в очереди он будет 
нходиться, естественно, до тех пор, пока остаётся хотя бы один относящийся к 
нему триггер.

Сорри, если немного путанно, но ИМХО это как раз тот случай, когда "показать 
на пальцах" или "на картошке" (как В.И.Чапаев) проще, чем описать словами:)

-- 
Led.

Re: [devel] [sisyphus -> devel] Стабильный Сизиф

[Alexey Tourbin]

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

On Mon, Jun 19, 2006 at 04:44:35PM +0300, Led wrote:
> Ок, попробую объяснить по другому (вариант libfoo_X для упрощения пока не 
> учитываю - он был приведён как временное решение, "костыль" для быстрейшего 
> (надеюсь, только в некоторых случаях) завершения транзакции в 
> случае "ленивости" мэйнтейнеров зависимых пакетов):
> 1) Термин "отстойник" и то, что вы в него вкладываете не совсем подходит
> 2) Предлагается термины "очередь" и "триггер".
> 3) libfoo с новым soname, поступающая в incoming (и, естественно, прошедшая 
> сборку в хешере), устанавливает триггер, по которому все собранные уже с ней 
> пакеты ставятся в очередь, триггер снимается и эти пакеты проходят в основной 
> репозитарий только после прохождения в этот репозитрарий самой libfoo.
> 4) Если какой-либо пакет зависит (в момент поступления в incoming) от двух или 
> нескольких библиотек, находящихся в "режиме ожидания", то в очереди он будет 
> нходиться, естественно, до тех пор, пока остаётся хотя бы один относящийся к 
> нему триггер.

Зачем тогда нужен триггер?  Если отстойник всего один, тогда задача
сводится вот к чему: все входящие пакеты собираются в отстойнике (если
сборка не удается, пакет получает reject).  Из всех пакетов в отстойнике
нужно выделить максимальное подмножество этих пакетов, которое, будучи
перемещенных из отстойника в основной сизиф, не увеличивает в основном
сизифе количество анметов (и/или не ухудшает других характеристик).

Тогда возникает только вычислительная проблема.  Придется анализировать
т.н. power set отстойника (т.е. всевозможные подмножества, которые можно
составить из пакетов в отстойнике).  Т.е. если в отстойнике находится 10
пакетов, то в поисках максимального "хорошего" подмножества пакетов
придется анализировать 2^{10} = 1024 подмножества (включая полное и
пустое).  Если же в отстойнике 100 пакетов, то имеем порядка 10^{30}
вариантов, и задачу в строгом смысле вряд ли удастся решить.  Есть
конечно градиентные методы и всякая прочая хрень...

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

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

Re: [devel] [sisyphus -> devel] Стабильный Сизиф

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

On Mon, Jun 19, 2006 at 07:18:02PM +0400, Алексей Турбин wrote:

AT> Тогда возникает только вычислительная проблема.  Придется анализировать
AT> т.н. power set отстойника (т.е. всевозможные подмножества, которые можно
AT> составить из пакетов в отстойнике).  Т.е. если в отстойнике находится 10
AT> пакетов, то в поисках максимального "хорошего" подмножества пакетов
AT> придется анализировать 2^{10} = 1024 подмножества (включая полное и
AT> пустое).  Если же в отстойнике 100 пакетов, то имеем порядка 10^{30}
AT> вариантов, и задачу в строгом смысле вряд ли удастся решить.  Есть
AT> конечно градиентные методы и всякая прочая хрень...

Эта задача решается куда проще. При условии что у нас есть алгоритм,
который по группе пакетов дает четкий ответ есть там unmet'ы или нет. И
если есть, то какой пакет не устанавливается, и каких provides ему не
хватает. Ну и, разумеется, есть информация по requires/provides всех
пакетов.

Берем пакет. Если unmet'ов нет -- сразу переносим. Если unmet'ы есть, то
смотрим какие из пакетов во временном репозитории имеют соответствующие
provides, повторяя этот процесс рекурсивно до получения либо группы
пакетов, которые можно установить, либо информации о том, что этот пакет
нельзя установить вообще.

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

http://freesource.info
----------------------------------------------------------------------------
плохо закрыл - вот теперь закрываю :)
		-- lav in #575

Re: [devel] [sisyphus -> devel] Стабильный Сизиф

[Alexey Tourbin]

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

On Tue, Jun 20, 2006 at 08:11:47PM +0400, Денис Смирнов wrote:
> AT> Тогда возникает только вычислительная проблема.  Придется анализировать
> AT> т.н. power set отстойника (т.е. всевозможные подмножества, которые можно
> AT> составить из пакетов в отстойнике).  Т.е. если в отстойнике находится 10
> AT> пакетов, то в поисках максимального "хорошего" подмножества пакетов
> AT> придется анализировать 2^{10} = 1024 подмножества (включая полное и
> AT> пустое).  Если же в отстойнике 100 пакетов, то имеем порядка 10^{30}
> AT> вариантов, и задачу в строгом смысле вряд ли удастся решить.  Есть
> AT> конечно градиентные методы и всякая прочая хрень...
> 
> Эта задача решается куда проще. При условии что у нас есть алгоритм,
> который по группе пакетов дает четкий ответ есть там unmet'ы или нет. И
> если есть, то какой пакет не устанавливается, и каких provides ему не
> хватает. Ну и, разумеется, есть информация по requires/provides всех
> пакетов.

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

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

Если исходить только из предиката, то получается экспоненциально трудная
задача -- найти максимальное подмножество, удовлетворяющее критерию.
То есть перебор подмножеств B(U) aka булеан aka power set.

> Берем пакет. Если unmet'ов нет -- сразу переносим. Если unmet'ы есть, то
> смотрим какие из пакетов во временном репозитории имеют соответствующие
> provides, повторяя этот процесс рекурсивно до получения либо группы
> пакетов, которые можно установить, либо информации о том, что этот пакет
> нельзя установить вообще.

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

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

Re: [devel] [sisyphus -> devel] Стабильный Сизиф

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

On Wed, Jun 21, 2006 at 06:40:31AM +0400, Алексей Турбин wrote:

AT> Есть только предикат, который для данной группы (точнее, подмножества;
AT> слово группа здесь лучше не произносить) дает однозначный ответ:
AT> появились новые анметы или нет.
AT> Предикат не может дать ответ, какой пакет "виноват" в том, что появились
AT> новые анметы.  В общем случае это нетривиальная задача.  Есть некоторые
AT> соображения и на эту тему, могу вербализовать.

Это было бы очень хорошо.

AT> Если исходить только из предиката, то получается экспоненциально трудная
AT> задача -- найти максимальное подмножество, удовлетворяющее критерию.
AT> То есть перебор подмножеств B(U) aka булеан aka power set.

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

>> Берем пакет. Если unmet'ов нет -- сразу переносим. Если unmet'ы есть, то
>> смотрим какие из пакетов во временном репозитории имеют соответствующие
>> provides, повторяя этот процесс рекурсивно до получения либо группы
>> пакетов, которые можно установить, либо информации о том, что этот пакет
>> нельзя установить вообще.
AT> Я склоняюсь к тому, что автоматически ничего волшебно-простого сделать
AT> нельзя.  Сказывается также отсутствие постановки задачи.  Так может быть
AT> стоит посмотреть примеры анметов за последний год...

Дашь скриптик, могу прогнать его на истории за год.

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

http://freesource.info
----------------------------------------------------------------------------
*** Bug 3334 has been marked as a duplicate of this bug. ***
		-- mouse in #4443

Re: [devel] [sisyphus -> devel] Стабильный Сизиф

[Alexey I. Froloff]

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

* Alexey Tourbin <at@> [060619 17:03]:
> Так можно ли автоматически бороться с анметами (то есть существует ли
> более тонкий автоматический критерий, чем просто давать reject пакетам,
> которые увеличивают количество анметов)?
Ну вот такая идея мне в голову пришла:

Если пакет baz зависит от пакета libfoo, получаемого из исходного
пакета foobar, то пакет baz должен иметь сборочную зависимость на
пакет bar, тоже получаемый из исходного пакета foobar.  Примем
это за постулат.

((note: под это правило не попадают зависимости проставленные
вручную, зависимости на исполняемые файлы (/bin/ls -> coreutils)
и зависимости на модули (python, tcl, но попадает perl). ))

Пакет foobar, генерирующий libfoo у которого сменился SONAME
попадает в отстойник с именем FUBAR.  Далее мы имеем список
FUBAR-src с именами всех исходных пакетов и FUBAR-req-src с
именами исходных пакетов, предоставляющих сборочные зависимости
для FUBAR-src.

Для каждого нового пакета генерим список типа FUBAR-req-src и
если он пересекается с FUBAR-src, то помещаем этот пакет в
отстойник FUBAR.

Если этот новый пакет попадает в список FUBAR-req-src, то
обработка этого пакета блокируется до окончания обработки
отстойника.

Если ни то ни другое, пакет обрабатывается как обычно.


Что я в этой схеме не предусмотрел?  Например когда foo зависит
от libbar и libbaz, находящихся в разных отстойниках.  Есть
реальные примеры таких сочетаний пакетов?  Не раскрыто понятие
"как обычно".

Под "неувеличением количества unmet'ов" наверно лучше следует
понимать "недобавление новых unmet'ов", т.е. схема -2+1 под это
не попадает.

-- 
Regards,
Sir Raorn.

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

Re: [devel] [sisyphus -> devel] Стабильный Сизиф

[Alexey Tourbin]

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

On Mon, Jun 19, 2006 at 05:45:43PM +0400, Alexey I. Froloff wrote:
> Если пакет baz зависит от пакета libfoo, получаемого из исходного
> пакета foobar, то пакет baz должен иметь сборочную зависимость на
> пакет bar, тоже получаемый из исходного пакета foobar.  Примем
> это за постулат.

Не обязательно.

> ((note: под это правило не попадают зависимости проставленные
> вручную, зависимости на исполняемые файлы (/bin/ls -> coreutils)
> и зависимости на модули (python, tcl, но попадает perl). ))
> 
> Пакет foobar, генерирующий libfoo у которого сменился SONAME
> попадает в отстойник с именем FUBAR.  Далее мы имеем список
> FUBAR-src с именами всех исходных пакетов и FUBAR-req-src с
> именами исходных пакетов, предоставляющих сборочные зависимости
> для FUBAR-src.
> 
> Для каждого нового пакета генерим список типа FUBAR-req-src и
> если он пересекается с FUBAR-src, то помещаем этот пакет в
> отстойник FUBAR.
> 
> Если этот новый пакет попадает в список FUBAR-req-src, то
> обработка этого пакета блокируется до окончания обработки
> отстойника.
> 
> Если ни то ни другое, пакет обрабатывается как обычно.
> 
> 
> Что я в этой схеме не предусмотрел?  Например когда foo зависит
> от libbar и libbaz, находящихся в разных отстойниках.  Есть
> реальные примеры таких сочетаний пакетов?  Не раскрыто понятие
> "как обычно".
> 
> Под "неувеличением количества unmet'ов" наверно лучше следует
> понимать "недобавление новых unmet'ов", т.е. схема -2+1 под это
> не попадает.

Достаточно попробовать сделать initroot + полная установка сборочных
зависимостей вновь пришедшего пакета на каждом из отстойников.
Хешер напишет список пакетов, который он ставит в сборочную среду.
Если среди этого списка есть пересечение с пакетами из отстойника,
то пакет прописывается в отстойник. :)

В общем довольно сложно получается...

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

Re: [devel] [sisyphus -> devel] Стабильный Сизиф

[Alexey Tourbin]

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

On Mon, Jun 19, 2006 at 07:26:00PM +0400, Alexey Tourbin wrote:
> Достаточно попробовать сделать initroot + полная установка сборочных
> зависимостей вновь пришедшего пакета на каждом из отстойников.
> Хешер напишет список пакетов, который он ставит в сборочную среду.
> Если среди этого списка есть пересечение с пакетами из отстойника,
> то пакет прописывается в отстойник. :)

Вписывается.

> В общем довольно сложно получается...

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

Re: [devel] [sisyphus -> devel] Стабильный Сизиф

[Michael Shigorin]

On Mon, Jun 19, 2006 at 04:12:39PM +0400, Alexey Tourbin wrote:
> Допустим приходит новый пакет, который зависит от двух
> отстойников ("транзакций").  Вопрос такой: к какому отстойнку
> его отнести?

Вот поэтому я и говорил пока про один RPMS.incoming.  А там,
отдышавшись, городить далее.

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

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

Re: [devel] [sisyphus -> devel] Стабильный Сизиф

[Alexey I. Froloff]

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

* Michael Shigorin <mike@> [060619 17:03]:
> > Допустим приходит новый пакет, который зависит от двух
> > отстойников ("транзакций").  Вопрос такой: к какому отстойнку
> > его отнести?
> Вот поэтому я и говорил пока про один RPMS.incoming.  А там,
> отдышавшись, городить далее.
Любое число между единицей и бесконечностью не имеет никакого
смысла, а бесконечно количество отстойников бесконечно
увеличивает энтропию.

P.S. Какая полезная вещь - отпуск ;-)

-- 
Regards,
Sir Raorn.

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

Re: [devel] [sisyphus -> devel] Стабильный Сизиф

[Led]

В сообщении от 19 июня 2006 16:47 Alexey I. Froloff написал(a):
> * Michael Shigorin <mike@> [060619 17:03]:
> > > Допустим приходит новый пакет, который зависит от двух
> > > отстойников ("транзакций").  Вопрос такой: к какому отстойнку
> > > его отнести?
> >
> > Вот поэтому я и говорил пока про один RPMS.incoming.  А там,
> > отдышавшись, городить далее.
>
> Любое число между единицей и бесконечностью не имеет никакого
> смысла, а бесконечно количество отстойников бесконечно
> увеличивает энтропию.

ОтстойникИ не нужны. Один "отстойник" и в нём "очереди" и "триггеры". 
Фактически таким "отстойником" является сегодняшний Сизифус, осталось 
добавить в него очереди и триггеры:)

>
> P.S. Какая полезная вещь - отпуск ;-)

-- 
Led.

Re: [devel] [sisyphus -> devel] Стабильный Сизиф

[Alexey I. Froloff]

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

* Led <led@> [060619 18:07]:
> ОтстойникИ не нужны. Один "отстойник" и в нём "очереди" и "триггеры". 
> Фактически таким "отстойником" является сегодняшний Сизифус, осталось 
> добавить в него очереди и триггеры:)
Ты хочешь проверять пересобираемость пакета с новой библиотекой
заливкой этого пакета в инкаминг?  Это дороговато выходит.  И
очень небыстро.

-- 
Regards,
Sir Raorn.

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

Re: [devel] [sisyphus -> devel] Стабильный Сизиф

[Led]

В сообщении от 19 июня 2006 17:09 Alexey I. Froloff написал(a):
> * Led <led@> [060619 18:07]:
> > ОтстойникИ не нужны. Один "отстойник" и в нём "очереди" и "триггеры".
> > Фактически таким "отстойником" является сегодняшний Сизифус, осталось
> > добавить в него очереди и триггеры:)
>
> Ты хочешь проверять пересобираемость пакета с новой библиотекой
> заливкой этого пакета в инкаминг?

Ммм... честно говоря, не совсем понял о чём речь... Вроде бы разговор шёл пока 
только об избалении от unmet'ов. или я что-то пропустил?

> Это дороговато выходит.  И 
> очень небыстро.

-- 
Led.

Re: [devel] [sisyphus -> devel] Стабильный Сизиф

[Alexey I. Froloff]

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

* Led <led@> [060619 18:19]:
> > > ОтстойникИ не нужны. Один "отстойник" и в нём "очереди" и "триггеры".
> > > Фактически таким "отстойником" является сегодняшний Сизифус, осталось
> > > добавить в него очереди и триггеры:)
> > Ты хочешь проверять пересобираемость пакета с новой библиотекой
> > заливкой этого пакета в инкаминг?
> Ммм... честно говоря, не совсем понял о чём речь... Вроде бы разговор шёл пока 
> только об избалении от unmet'ов. или я что-то пропустил?
Как мне, простому мантейнеру foo, получить доступ к "очереди",
где лежит новая libbar, чтобы проверить что мой пакет с ней
соберётся?  Пересобирать у себя libbar?  Выкладывать foo как есть
и ловить сообщения об ошибке сборки?

-- 
Regards,
Sir Raorn.

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

Re: [devel] [sisyphus -> devel] Стабильный Сизиф

[Led]

В сообщении от 19 июня 2006 17:22 Alexey I. Froloff написал(a):
> * Led <led@> [060619 18:19]:
> > > > ОтстойникИ не нужны. Один "отстойник" и в нём "очереди" и "триггеры".
> > > > Фактически таким "отстойником" является сегодняшний Сизифус, осталось
> > > > добавить в него очереди и триггеры:)
> > >
> > > Ты хочешь проверять пересобираемость пакета с новой библиотекой
> > > заливкой этого пакета в инкаминг?
> >
> > Ммм... честно говоря, не совсем понял о чём речь... Вроде бы разговор шёл
> > пока только об избалении от unmet'ов. или я что-то пропустил?
>
> Как мне, простому мантейнеру foo, получить доступ к "очереди",
> где лежит новая libbar, чтобы проверить что мой пакет с ней
> соберётся?

Точно так же, как вы сейчас получаете доступ к Sisyphus. Я всего лишь 
предлагаю "прикрутить" очереди и триггеры к Сизифу (для чего - уже устал 
повторять:))

> Пересобирать у себя libbar?  Выкладывать foo как есть 
> и ловить сообщения об ошибке сборки?

-- 
Led.

Re: [devel] [sisyphus -> devel] Стабильный Сизиф

[Sergey V Turchin]

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

On Thursday 15 June 2006 14:41, Led wrote:

[...]
> помощью которого выполнив одну-две-три команды получить образ
> ISO9660 (CD, DVD, ...) с инсталляционной базой текущего бранча и
> инсталлятором.
IMHO не обязательно CD/DVD. Скорее, саму возможность инсталляции. С 
HDD, NFS или FTP

-- 
Regards, Sergey, ALT Linux Team, http://www.altlinux.ru
http://stinkfoot.org:11371/pks/lookup?op=get&search=0x1C2A3F08

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

Re: [devel] [sisyphus -> devel] Стабильный Сизиф

[Epiphanov Sergei]

В сообщении от Thursday 15 June 2006 14:41 Led написал(a):
> ...) с инсталляционной базой текущего бранча и инсталлятором. Методика
> "Установите Compact 3.0 и накатайте apt'ом до текущего состояния
> репозитария" довольно быстро исчерпывает терпение и после подобной
> "инсталляции" желание что-либо тестировать быстро пропадает; а когда в
> следующий раз думаешь

Я бы выразился, "...закатайте apt'ом до текущего состояния". 8-) Ибо чем 
дальше по времени Сизиф от Компакта, тем больше нужен каток (для некоторых, 
наверное, достаточно бООООльшого бубна), чтобы прийти к нужному виду.

Мне, например, ОЧЕНЬ желательны хотя раз в месяц-другой стабильные состояния 
Сизифа (я имею в виду хотя бы основные программы для меня вроде связок 
X+fglrx+gcc, чтобы kde не был сломан), так как за деньги пишу у других людей 
текущий срез Сизифа и мне совсем неохота платить лишние деньги из своего 
кармана только за то, что некоторые _вдруг_ без какого-либо объявления 
ломают основные связи или вбрасывают новейшую версию нужного пакета в 
Сизиф "на попробовать" без предварительного тестирования. Я сейчас вовсю 
слежу, когда же, наконец, смогу попросить людей записать диски, так как 
сейчас, по моим наблюдениям, в kde некоторая разруха, проблемы с openldap, 
samba, может, есть что-то ещё. Может кто дать отмашку а-ля более-менее 
работает?

-- 
С уважением, Епифанов Сергей

Re: [devel] [sisyphus -> devel] Стабильный Сизиф

[Anton Farygin]

Epiphanov Sergei wrote:
> В сообщении от Thursday 15 June 2006 14:41 Led написал(a):
>> ...) с инсталляционной базой текущего бранча и инсталлятором. Методика
>> "Установите Compact 3.0 и накатайте apt'ом до текущего состояния
>> репозитария" довольно быстро исчерпывает терпение и после подобной
>> "инсталляции" желание что-либо тестировать быстро пропадает; а когда в
>> следующий раз думаешь
> 
> Я бы выразился, "...закатайте apt'ом до текущего состояния". 8-) Ибо чем 
> дальше по времени Сизиф от Компакта, тем больше нужен каток (для некоторых, 
> наверное, достаточно бООООльшого бубна), чтобы прийти к нужному виду.
> 
> Мне, например, ОЧЕНЬ желательны хотя раз в месяц-другой стабильные состояния 
> Сизифа (я имею в виду хотя бы основные программы для меня вроде связок 
> X+fglrx+gcc, чтобы kde не был сломан), так как за деньги пишу у других людей 
> текущий срез Сизифа и мне совсем неохота платить лишние деньги из своего 
> кармана только за то, что некоторые _вдруг_ без какого-либо объявления 
> ломают основные связи или вбрасывают новейшую версию нужного пакета в 
> Сизиф "на попробовать" без предварительного тестирования. Я сейчас вовсю 
> слежу, когда же, наконец, смогу попросить людей записать диски, так как 
> сейчас, по моим наблюдениям, в kde некоторая разруха, проблемы с openldap, 
> samba, может, есть что-то ещё. Может кто дать отмашку а-ля более-менее 
> работает?
> 

Как только начну инсталлеры или livecd выпускать - значит более менее 
работает вышеперечисленное.

Rgds,
Rider

Re: [devel] [sisyphus -> devel] Стабильный Сизиф

[Epiphanov Sergei]

В сообщении от Thursday 15 June 2006 16:58 Anton Farygin написал(a):
> Как только начну инсталлеры или livecd выпускать - значит более менее
> работает вышеперечисленное.

Ок. Надеюсь, это не затянется на полгода.

-- 
С уважением, Епифанов Сергей

Re: [devel] [sisyphus -> devel] Стабильный Сизиф

[Sergey V Turchin]

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

On Thursday 15 June 2006 16:42, Epiphanov Sergei wrote:

[...]
> попросить людей записать диски, так как сейчас, по моим
> наблюдениям, в kde некоторая разруха
По моим, в incoming@, но это отдельная проблема.

-- 
Regards, Sergey, ALT Linux Team, http://www.altlinux.ru
http://stinkfoot.org:11371/pks/lookup?op=get&search=0x1C2A3F08

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

Re: [devel] [sisyphus -> devel] Стабильный Сизиф

[Led]

В сообщении от 15 июня 2006 16:00 Sergey V Turchin написал(a):
> On Thursday 15 June 2006 16:42, Epiphanov Sergei wrote:
>
> [...]
>
> > попросить людей записать диски, так как сейчас, по моим
> > наблюдениям, в kde некоторая разруха
>
> По моим, в incoming@, но это отдельная проблема.

ИМХО в любой большой и активно меняющейся базе связанных данных рано или 
поздно наступит разруха, если сервер БД не поддерживает транзакции...

-- 
Led.

Re: [devel] [sisyphus -> devel] Стабильный Сизиф

[Michael Shigorin]

On Thu, Jun 15, 2006 at 04:42:06PM +0400, Epiphanov Sergei wrote:
> Может кто дать отмашку а-ля более-менее работает?

Читайте wiki.sisyphus.ru/changes (интересно, Sisyphus@Etersoft
сейчас разливают в удачные моменты?)

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

Re: [devel] [sisyphus -> devel] Стабильный Сизиф

[Fr. Br. George]

On Thu, Jun 15, 2006 at 01:41:46PM +0300, Led wrote:
> ещё +1, но... Для более плотного багфикса бранча/фриза/или-как-там-его ИМХО 
> необходим инструмент быстрой и минимально проблемной 
> инсталляции/переинсталляции системы с ним
Нужен. Давайте сделаем. Возьмётесь?

-- 
			George V Kouryachy (aka Fr. Br. George)
			mailto:george at altlinux_ru

Re: [devel] [sisyphus -> devel] Стабильный Сизиф

[Led]

В сообщении от 15 июня 2006 19:40 Fr. Br. George написал(a):
> On Thu, Jun 15, 2006 at 01:41:46PM +0300, Led wrote:
> > ещё +1, но... Для более плотного багфикса бранча/фриза/или-как-там-его
> > ИМХО необходим инструмент быстрой и минимально проблемной
> > инсталляции/переинсталляции системы с ним
>
> Нужен. Давайте сделаем. Возьмётесь?

Мне сказали, что он и так уже есть (в виде separator'а). В любом случае такой 
инструмент заработает (ИМХО) только после того, как пакеты будут попадать в 
репозитарий не по принципу "собрался в хешере - ушёл в сизиф", а транзакциями 
(для поддержания целостности репозитария).

-- 
Led.

Re: [devel] [sisyphus -> devel] Стабильный Сизиф

[Fr. Br. George]

On Thu, Jun 15, 2006 at 07:57:49PM +0300, Led wrote:
> В сообщении от 15 июня 2006 19:40 Fr. Br. George написал(a):
> > On Thu, Jun 15, 2006 at 01:41:46PM +0300, Led wrote:
> > > ещё +1, но... Для более плотного багфикса бранча/фриза/или-как-там-его
> > > ИМХО необходим инструмент быстрой и минимально проблемной
> > > инсталляции/переинсталляции системы с ним
> >
> > Нужен. Давайте сделаем. Возьмётесь?
> 
> Мне сказали, что он и так уже есть (в виде separator'а). В любом случае такой 
> инструмент заработает (ИМХО) только после того, как пакеты будут попадать в 
> репозитарий не по принципу "собрался в хешере - ушёл в сизиф", а транзакциями 
> (для поддержания целостности репозитария).
Да. Это следующая стадия -- автоматизация целостности. Чтобы любой срез
становился сам как бы дистрибутивом. Но для начала нам бы просто
совместимости друг с другом, да непадучести добиться. А то обновил я тут
CUPS, блин.

-- 
			George V Kouryachy (aka Fr. Br. George)
			mailto:george at altlinux_ru

Re: [devel] [sisyphus -> devel] Стабильный Сизиф

[Led]

В сообщении от 15 июня 2006 20:02 Fr. Br. George написал(a):
> On Thu, Jun 15, 2006 at 07:57:49PM +0300, Led wrote:
> > В сообщении от 15 июня 2006 19:40 Fr. Br. George написал(a):
> > > On Thu, Jun 15, 2006 at 01:41:46PM +0300, Led wrote:
> > > > ещё +1, но... Для более плотного багфикса
> > > > бранча/фриза/или-как-там-его ИМХО необходим инструмент быстрой и
> > > > минимально проблемной
> > > > инсталляции/переинсталляции системы с ним
> > >
> > > Нужен. Давайте сделаем. Возьмётесь?
> >
> > Мне сказали, что он и так уже есть (в виде separator'а). В любом случае
> > такой инструмент заработает (ИМХО) только после того, как пакеты будут
> > попадать в репозитарий не по принципу "собрался в хешере - ушёл в сизиф",
> > а транзакциями (для поддержания целостности репозитария).
>
> Да. Это следующая стадия -- автоматизация целостности. Чтобы любой срез
> становился сам как бы дистрибутивом.

Мне кажется, что это должна быть как раз первая стадия (или даже нулевая).

> Но для начала нам бы просто 
> совместимости друг с другом,

Так я об этом и говорю, подразумевая под "целостностью" хотя бы отсутствие 
unmet'ов.

> да непадучести добиться.

"Непадучесть" - тут только рутинное тестирование... Вот только ИМХО качество и 
объёмы этого "рутинного тестирования" можно в несколько раз поднять, 
добившись элементарной целостности и непротиворечивости репозитария.

> А то обновил я тут  
> CUPS, блин.

Я рассылку стараюсь читать, потому на Hold его сразу поставил:)

-- 
Led.

Re: [devel] [sisyphus -> devel] Стабильный Сизиф

[Michael Shigorin]

On Thu, Jun 15, 2006 at 08:08:48PM +0300, Led wrote:
> > А то обновил я тут  CUPS, блин.
> Я рассылку стараюсь читать, потому на Hold его сразу поставил:)

Я обновил, хотя читаю.

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

Re: [devel] [sisyphus -> devel] Стабильный Сизиф

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

On Thu, Jun 15, 2006 at 09:02:50PM +0400, Fr. Br. George wrote:

FBG> Да. Это следующая стадия -- автоматизация целостности. Чтобы любой срез
FBG> становился сам как бы дистрибутивом. Но для начала нам бы просто
FBG> совместимости друг с другом, да непадучести добиться. А то обновил я тут
FBG> CUPS, блин.

У меня есть мнение, что техническую целостность (aka возможность
установить любой пакет из репозитория) создать и поддерживать куда проще
чем "совместимость".

А CUPS после обновления отлично работает, если пользователя в группу lp
добавить :)

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

http://freesource.info
----------------------------------------------------------------------------

Re: [devel] cups

[Dmitry V. Levin]

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

On Fri, Jun 16, 2006 at 02:29:49PM +0400, Денис Смирнов wrote:
> On Thu, Jun 15, 2006 at 09:02:50PM +0400, Fr. Br. George wrote:
> 
> FBG> Да. Это следующая стадия -- автоматизация целостности. Чтобы любой срез
> FBG> становился сам как бы дистрибутивом. Но для начала нам бы просто
> FBG> совместимости друг с другом, да непадучести добиться. А то обновил я тут
> FBG> CUPS, блин.
> 
> У меня есть мнение, что техническую целостность (aka возможность
> установить любой пакет из репозитория) создать и поддерживать куда проще
> чем "совместимость".
> 
> А CUPS после обновления отлично работает, если пользователя в группу lp
> добавить :)

Только делать этого нельзя.  Я объяснял причины в sisyphus@


-- 
ldv

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

Re: [devel] [sisyphus -> devel] Стабильный Сизиф

[Stanislav Ievlev]

On Fri, Jun 16, 2006 at 02:29:49PM +0400, Денис Смирнов wrote:
> On Thu, Jun 15, 2006 at 09:02:50PM +0400, Fr. Br. George wrote:
> 
> FBG> Да. Это следующая стадия -- автоматизация целостности. Чтобы любой срез
> FBG> становился сам как бы дистрибутивом. Но для начала нам бы просто
> FBG> совместимости друг с другом, да непадучести добиться. А то обновил я тут
> FBG> CUPS, блин.
> 
> У меня есть мнение, что техническую целостность (aka возможность
> установить любой пакет из репозитория) создать и поддерживать куда проще
> чем "совместимость".
> 
> А CUPS после обновления отлично работает, если пользователя в группу lp
> добавить :)
Может мне рандомайзер какой добавить на группы, чтобы никто так не делал?

Re: [devel] [sisyphus -> devel] Стабильный Сизиф

[Led]

В сообщении от 16 июня 2006 16:14 Stanislav Ievlev написал(a):
> On Fri, Jun 16, 2006 at 02:29:49PM +0400, Денис Смирнов wrote:
> > On Thu, Jun 15, 2006 at 09:02:50PM +0400, Fr. Br. George wrote:
> >
> > FBG> Да. Это следующая стадия -- автоматизация целостности. Чтобы любой
> > срез FBG> становился сам как бы дистрибутивом. Но для начала нам бы
> > просто FBG> совместимости друг с другом, да непадучести добиться. А то
> > обновил я тут FBG> CUPS, блин.
> >
> > У меня есть мнение, что техническую целостность (aka возможность
> > установить любой пакет из репозитория) создать и поддерживать куда проще
> > чем "совместимость".
> >
> > А CUPS после обновления отлично работает, если пользователя в группу lp
> > добавить :)
>
> Может мне рандомайзер какой добавить на группы, чтобы никто так не делал?

Лучше сразу соответствующий securyty-lp.patch на ядро:)

-- 
Led.

Re: [devel] [sisyphus -> devel] Стабильный Сизиф

[Sergey V Turchin]

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

On Friday 16 June 2006 17:14, Stanislav Ievlev wrote:

[...]
> Может мне рандомайзер какой добавить на группы, чтобы никто так
> не делал?
Лучше такие группы обзывать c подчеркиванием в начале, чтоб очевидно 
было.

-- 
Regards, Sergey, ALT Linux Team, http://www.altlinux.ru
http://stinkfoot.org:11371/pks/lookup?op=get&search=0x1C2A3F08

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

Re: [devel] [sisyphus -> devel] Стабильный Сизиф

[Michael Shigorin]

On Fri, Jun 16, 2006 at 06:38:50PM +0400, Sergey V Turchin wrote:
> > Может мне рандомайзер какой добавить на группы, чтобы никто
> > так не делал?
> Лучше такие группы обзывать c подчеркиванием в начале, чтоб
> очевидно было.

В смысле "технические".  Кстати, эта мода вроде как наблюдается
(уже?) не только у нас.

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

Re: [devel] [sisyphus -> devel] Стабильный Сизиф [JT]

[Slava Semushin]

--- Michael Shigorin 2006-06-19 11:46:51 +0300
+++ Vyacheslav Semushin 2006-06-19 16:48:07 +0700

MS> > Лучше такие группы обзывать c подчеркиванием в начале, чтоб
MS> > очевидно было.
MS> В смысле "технические".  Кстати, эта мода вроде как наблюдается
MS> (уже?) не только у нас.

    Видел подобную тенденцию в OpenBSD ;-)

    К примеру, у них mpd работает от имени пользователя _mpd:
    http://www.openbsd.org/cgi-bin/cvsweb/~checkout~/ports/audio/mpd/pkg/PLIST?rev=1.2&content-type=text/plain


-- 
+ Slava Semushin | php-coder @ ngs.ru
+ ALT Linux Team | php-coder @ altlinux.ru
+ Expand QA Team | vsemushin @ swsoft.com

Re: [devel] [sisyphus -> devel] Стабильный Сизиф

[Dmitry V. Levin]

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

On Fri, Jun 16, 2006 at 05:14:05PM +0400, Stanislav Ievlev wrote:
> On Fri, Jun 16, 2006 at 02:29:49PM +0400, Денис Смирнов wrote:
> > On Thu, Jun 15, 2006 at 09:02:50PM +0400, Fr. Br. George wrote:
> > 
> > FBG> Да. Это следующая стадия -- автоматизация целостности. Чтобы любой срез
> > FBG> становился сам как бы дистрибутивом. Но для начала нам бы просто
> > FBG> совместимости друг с другом, да непадучести добиться. А то обновил я тут
> > FBG> CUPS, блин.
> > 
> > У меня есть мнение, что техническую целостность (aka возможность
> > установить любой пакет из репозитория) создать и поддерживать куда проще
> > чем "совместимость".
> > 
> > А CUPS после обновления отлично работает, если пользователя в группу lp
> > добавить :)
> Может мне рандомайзер какой добавить на группы, чтобы никто так не делал?

Я написал, что надо было сделать, посмотри моё письмо в sisyphus@.


-- 
ldv

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

Re: [devel] [sisyphus -> devel] Стабильный Сизиф

[Fr. Br. George]

On Fri, Jun 16, 2006 at 02:29:49PM +0400, Денис Смирнов wrote:
> У меня есть мнение, что техническую целостность (aka возможность
> установить любой пакет из репозитория) создать и поддерживать куда проще
> чем "совместимость".
Скорее всего -- да. Только вот никто ж не пробовал :).

> А CUPS после обновления отлично работает, если пользователя в группу lp
> добавить :)
Ты знал! Ты знал!!

-- 
			George V Kouryachy (aka Fr. Br. George)
			mailto:george at altlinux_ru

Re: [devel] [sisyphus -> devel] Стабильный Сизиф

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

On Fri, Jun 16, 2006 at 05:51:36PM +0400, Fr. Br. George wrote:

>> А CUPS после обновления отлично работает, если пользователя в группу lp
>> добавить :)
FBG> Ты знал! Ты знал!!

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

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

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

http://freesource.info
----------------------------------------------------------------------------
Если кто захочет помочь/советовать -- willkommen.
		-- peet in sisyphus@

Re: [devel] [sisyphus -> devel] Стабильный Сизиф

[Fr. Br. George]

On Fri, Jun 16, 2006 at 06:20:57PM +0400, Денис Смирнов wrote:
> On Fri, Jun 16, 2006 at 05:51:36PM +0400, Fr. Br. George wrote:
> 
> >> А CUPS после обновления отлично работает, если пользователя в группу lp
> >> добавить :)
> FBG> Ты знал! Ты знал!!
> 
> Нет, я сначала потратил два часа, чтобы понять почему не могу распечатать
> нужный мне документ :(
А мне за пять минут  самба помогла -- она прямо так в логе и писала, что
сокет открыть не может. Я глянул на сокет -- а он, гад, 600. Кстати, lp
-- служебная группа, по идее в неё тлько некоторые setgid-ные программки
лазать должны, и после того, как inger пофиксит багу (а это именно
бага), надо будет всех из неё выкинуть.

-- 
			George V Kouryachy (aka Fr. Br. George)
			mailto:george at altlinux_ru

Re: [devel] [sisyphus -> devel] Стабильный Сизиф

[Stanislav Ievlev]

On Fri, Jun 16, 2006 at 07:46:50PM +0400, Fr. Br. George wrote:
> On Fri, Jun 16, 2006 at 06:20:57PM +0400, Денис Смирнов wrote:
> > On Fri, Jun 16, 2006 at 05:51:36PM +0400, Fr. Br. George wrote:
> > 
> > >> А CUPS после обновления отлично работает, если пользователя в группу lp
> > >> добавить :)
> > FBG> Ты знал! Ты знал!!
> > 
> > Нет, я сначала потратил два часа, чтобы понять почему не могу распечатать
> > нужный мне документ :(
> А мне за пять минут  самба помогла -- она прямо так в логе и писала, что
> сокет открыть не может. Я глянул на сокет -- а он, гад, 600. Кстати, lp
> -- служебная группа, по идее в неё тлько некоторые setgid-ные программки
> лазать должны, и после того, как inger пофиксит багу (а это именно
> бага), надо будет всех из неё выкинуть.
Надеюсь что пофиксил, как минимум у меня несгидный lpq работает в режиме
control - server.

Re: [devel] [sisyphus -> devel] Стабильный Сизиф

[Damir Shayhutdinov]

15.06.06, Fr. Br. George<george@altlinux.ru> написал(а):
> А вот выдержать месяц-два заморозки самого Сизифа, да и поработать в
> это время не на гонку за фичами, а на совместимость и более плотный
> багфикс, я вполне способен.
А что делать в период фриза тем, у кого пакеты в порядке? Плевать в
потолок? Новую версию с новыми фичами выложить "на потестировать" не
дадут...

Re: [devel] [sisyphus -> devel] Стабильный Сизиф

[Andrii Dobrovol`s`kii]

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

Damir Shayhutdinov пишет:
> 15.06.06, Fr. Br. George<george@altlinux.ru> написал(а):
>> А вот выдержать месяц-два заморозки самого Сизифа, да и поработать в
>> это время не на гонку за фичами, а на совместимость и более плотный
>> багфикс, я вполне способен.
> А что делать в период фриза тем, у кого пакеты в порядке? Плевать в
> потолок? Новую версию с новыми фичами выложить "на потестировать" не
> дадут...
Почему не дадут? Дедал всегда живой... Его никто и ни при каких
условиях замораживать не собирается. Если с Вашими пакетами полный
порядок, Вы можете "продолжать движение" с публикацией результатов в
Дедале. А как произойдет разморозка, влить всё нужное в оживший Сизиф.
-- 
Rgrds,
Andriy
*********************************************************************
email: dobr at iop dot kiev dot ua            Kyiv, Ukraine
Phone: (380-44)   525-7824            Department of Gas Electronics
Fax:   (380-44)   525-2329             Institute of Physics of NASU
*********************dobrATjabber.iop.kiev.ua************************


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

Re: [devel] [sisyphus -> devel] Стабильный Сизиф

[Damir Shayhutdinov]

15.06.06, Andrii Dobrovol`s`kii<dobr@iop.kiev.ua> написал(а):
> > А что делать в период фриза тем, у кого пакеты в порядке? Плевать в
> > потолок? Новую версию с новыми фичами выложить "на потестировать" не
> > дадут...
> Почему не дадут? Дедал всегда живой...
А по-моему, он всегда мертвый. В смысле тестируют пакеты из Дедала
исчезающее малое количество пользователей. К тому же он вроде
незамкнутый.
Мало пользователей -> плохое тестировование, что вместе с накопленным
различием размороженного сизифа и дедала может создать эффект
"разорвавшейся клизмы".

Re: [devel] [sisyphus -> devel] Стабильный Сизиф

[Epiphanov Sergei]

В сообщении от Thursday 15 June 2006 16:24 Damir Shayhutdinov написал(a):
> > Почему не дадут? Дедал всегда живой...
>
> А по-моему, он всегда мертвый. В смысле тестируют пакеты из Дедала
> исчезающее малое количество пользователей. К тому же он вроде
> незамкнутый.
> Мало пользователей -> плохое тестировование, что вместе с накопленным
> различием размороженного сизифа и дедала может создать эффект
> "разорвавшейся клизмы".

В фортунки!

-- 
С уважением, Епифанов Сергей

Re: [devel] Стабильный Сизиф

[Andrii Dobrovol`s`kii]

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

Damir Shayhutdinov пишет:
> 15.06.06, Andrii Dobrovol`s`kii<dobr@iop.kiev.ua> написал(а):
>>> А что делать в период фриза тем, у кого пакеты в порядке? Плевать в
>>> потолок? Новую версию с новыми фичами выложить "на потестировать" не
>>> дадут...
>> Почему не дадут? Дедал всегда живой...
> А по-моему, он всегда мертвый. В смысле тестируют пакеты из Дедала
> исчезающее малое количество пользователей. К тому же он вроде
> незамкнутый.
Не, не мертвый, спящий... ;) И ничего не мешает его разбудить.
> Мало пользователей -> плохое тестировование, что вместе с накопленным
> различием размороженного сизифа и дедала может создать эффект
> "разорвавшейся клизмы".
Сизиф временами тоже не замкнутый и что? Как замкнутость влияет на
сборку отдельных пакетов? Пользователей и у Сизифа мало и становится
всё меньше, увы... Этим и вызвана очередная попытка изменить что-то
к лучшему. ИМХО. А о каких различиях речь не очень понятно. Вы же
решаете с какими зависимостями собирать пакет. И к моменту
разморозки либо просто отправляете свежую сборку на существующей
базе, либо отправляете более одной сборки, что принципиально сути не
меняет.
-- 
Rgrds,
Andriy
*********************************************************************
email: dobr at iop dot kiev dot ua            Kyiv, Ukraine
Phone: (380-44)   525-7824            Department of Gas Electronics
Fax:   (380-44)   525-2329             Institute of Physics of NASU
*********************dobrATjabber.iop.kiev.ua************************


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

Re: [devel] Стабильный Сизиф

[Led]

В сообщении от 15 июня 2006 15:45 Andrii Dobrovol`s`kii написал(a):
> Damir Shayhutdinov пишет:
> > 15.06.06, Andrii Dobrovol`s`kii<dobr@iop.kiev.ua> написал(а):
> >>> А что делать в период фриза тем, у кого пакеты в порядке? Плевать в
> >>> потолок? Новую версию с новыми фичами выложить "на потестировать" не
> >>> дадут...
> >>
> >> Почему не дадут? Дедал всегда живой...
> >
> > А по-моему, он всегда мертвый. В смысле тестируют пакеты из Дедала
> > исчезающее малое количество пользователей. К тому же он вроде
> > незамкнутый.
>
> Не, не мертвый, спящий... ;) И ничего не мешает его разбудить.
>
> > Мало пользователей -> плохое тестировование, что вместе с накопленным
> > различием размороженного сизифа и дедала может создать эффект
> > "разорвавшейся клизмы".
>
> Сизиф временами тоже не замкнутый и что?

Вернее, "временами бывает замкнутый":)

> Как замкнутость влияет на 
> сборку отдельных пакетов?

Влияет. Не далее, как вчера, не получилось собрать пакет, использующий 
kdelibs - пришлось откатиться на репозитарий от 09.06.2006.

> Пользователей и у Сизифа мало и становится 
> всё меньше, увы... Этим и вызвана очередная попытка изменить что-то
> к лучшему. ИМХО. А о каких различиях речь не очень понятно. Вы же
> решаете с какими зависимостями собирать пакет. И к моменту
> разморозки либо просто отправляете свежую сборку на существующей
> базе, либо отправляете более одной сборки, что принципиально сути не
> меняет.

Как всё легко-то на словах получается!:) Выходит, что работа мэйтейнера 
ограничивается ТОЛЬКО изготовлением src.rpm и "отправкой"? Если это так, то 
никакие "бранчи/фризы" сизифу не помогут:)

-- 
Led.

Re: [devel] Стабильный Сизиф

[Damir Shayhutdinov]

15.06.06, Andrii Dobrovol`s`kii<dobr@iop.kiev.ua> написал(а):
> Не, не мертвый, спящий... ;) И ничего не мешает его разбудить.
Не понимаю, как увеличится число пользователей Дедала, если вы
отмечаете уменьшение пользователей Сизифа. При курсе на стабилизацию
по логике пользователей Сизифа должно увеличиваться, не так ли? Ведь
для этого все затевается.
Как при этом вообще удастся разбудить Дедал, в котором вообще QA как
класс отсутствует, если я правильно понимаю ситуацию?

> Сизиф временами тоже не замкнутый и что? Как замкнутость влияет на
> сборку отдельных пакетов?
Например, мне интересно, устраиваются ли регулярные пересборки Дедала?
Есть ли для него такой QA как в Сизифе? Анметы, bad_elf_symbols,
анализ собираемости по каждой из платформ?
Если все это будет, то чем это будет отличаться от создания бранча?

> И к моменту
> разморозки либо просто отправляете свежую сборку на существующей
> базе, либо отправляете более одной сборки, что принципиально сути не
> меняет.
Если у немногочисленных тесторов  в Дедале пакет работает, и _у меня_
этот пакет работает также на замороженном Сизифе, то как я могу быть
уверенным что он будет работать у _всех_ на размороженном Сизифе?
Вот отсюда и "клизма".

Re: [devel] Стабильный Сизиф

[Alexey Tourbin]

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

On Thu, Jun 15, 2006 at 03:45:44PM +0300, Andrii Dobrovol`s`kii wrote:
> Пользователей и у Сизифа мало и становится всё меньше, увы...

Откуда данные?  Давайте оценки.  Сравнительные.

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

Re: [devel] [sisyphus -> devel] Стабильный Сизиф

[Alexey Tourbin]

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

On Thu, Jun 15, 2006 at 04:24:42PM +0400, Damir Shayhutdinov wrote:
> Мало пользователей -> плохое тестировование, что вместе с накопленным

Нужно *исходить* из того, что пользователей мало и тестирование плохое.

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

[devel] Daedalus (was: [sisyphus -> devel] Стабильный Сизиф)

[Michael Shigorin]

On Thu, Jun 15, 2006 at 04:24:42PM +0400, Damir Shayhutdinov wrote:
> > Почему не дадут? Дедал всегда живой...
> А по-моему, он всегда мертвый.

У меня было как I, так и O по Daedalus.

> В смысле тестируют пакеты из Дедала исчезающее малое количество
> пользователей.

Мне почему-то кажется, что он создан не для широкого, а как раз
для узкоспециализированного тестирования.

Кстати, было бы хорошо вообще формализовать предназначение и цели
репозиториев, чтобы и пользователи, и майнтейнеры меньше
догадывались и больше знали.

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

Re: [devel] [sisyphus -> devel] Стабильный Сизиф

[Grigory Batalov]

On Thu, 15 Jun 2006 16:04:50 +0400
"Damir Shayhutdinov" <damir@altlinux.org> wrote:

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

> А что делать в период фриза тем, у кого пакеты в порядке? Плевать в
> потолок? Новую версию с новыми фичами выложить "на потестировать" не
> дадут...

  Если у Вас много свободного времени, возьмите в поддержку
  больше пакетов =).

-- 
 Григорий Баталов,
 программист
 ЗАО "Ланит-Терком"

Re: [devel] [sisyphus -> devel] Стабильный Сизиф

[Damir Shayhutdinov]

15.06.06, Grigory Batalov<bga@altlinux.ru> написал(а):
> > А что делать в период фриза тем, у кого пакеты в порядке? Плевать в
> > потолок? Новую версию с новыми фичами выложить "на потестировать" не
> > дадут...
>   Если у Вас много свободного времени, возьмите в поддержку
>   больше пакетов =).
В период фриза? ;)

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

Re: [devel] [sisyphus -> devel] Стабильный Сизиф

[Fr. Br. George]

On Thu, Jun 15, 2006 at 04:58:30PM +0400, Damir Shayhutdinov wrote:
> 15.06.06, Grigory Batalov<bga@altlinux.ru> написал(а):
> > > А что делать в период фриза тем, у кого пакеты в порядке? Плевать в
> > > потолок? Новую версию с новыми фичами выложить "на потестировать" не
> > > дадут...
> >   Если у Вас много свободного времени, возьмите в поддержку
> >   больше пакетов =).
> В период фриза? ;)
> 
> А так я поддерживаю только те пакеты, которыми сам регулярно использую
> или планирую использовать в недалеком будущем. Просто не считаю я
> хорошей проверкой собираемость в хэшере, а большего обеспечить не
> могу.
Знаете, у меня вот всегда руки чесались править чей-нибудь глюкавый
пакет. И останавливало два соображения -- не шибко удобное NMU и не
вполне понятный смысл править один глюкавый пакет, если завтра
насыплется дюжина новых, ещё более глюкавых.

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

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

И только повторю: если у вас и в самом деле пакет в порядке -- это
больше половины дела! Все бы были такими, как вы, никакого фриза не
понадобилось бы! Особенно когда пакеты в порядке именно во время
фриза... :)

-- 
			George V Kouryachy (aka Fr. Br. George)
			mailto:george at altlinux_ru

Re: [devel] [sisyphus -> devel] Стабильный Сизиф

[Led]

В сообщении от 15 июня 2006 20:17 Fr. Br. George написал(a):
> On Thu, Jun 15, 2006 at 04:58:30PM +0400, Damir Shayhutdinov wrote:
> > 15.06.06, Grigory Batalov<bga@altlinux.ru> написал(а):
> > > > А что делать в период фриза тем, у кого пакеты в порядке? Плевать в
> > > > потолок? Новую версию с новыми фичами выложить "на потестировать" не
> > > > дадут...
> > >
> > >   Если у Вас много свободного времени, возьмите в поддержку
> > >   больше пакетов =).
> >
> > В период фриза? ;)
> >
> > А так я поддерживаю только те пакеты, которыми сам регулярно использую
> > или планирую использовать в недалеком будущем. Просто не считаю я
> > хорошей проверкой собираемость в хэшере, а большего обеспечить не
> > могу.
>
> Знаете, у меня вот всегда руки чесались править чей-нибудь глюкавый
> пакет. И останавливало два соображения -- не шибко удобное NMU и не
> вполне понятный смысл править один глюкавый пакет, если завтра
> насыплется дюжина новых, ещё более глюкавых.

Аналогично. Поэтому или жду когда подобный пакет наконец-то попадёт в 
orphaned, или, если уж очень "руки чешутся" - кидаю в Daedalus.

-- 
Led.

Re: [devel] [sisyphus -> devel] Стабильный Сизиф

[Anton Farygin]

Grigory Batalov wrote:
> On Thu, 15 Jun 2006 16:04:50 +0400
> "Damir Shayhutdinov" <damir@altlinux.org> wrote:
> 
>>> А вот выдержать месяц-два заморозки самого Сизифа, да и поработать в
>>> это время не на гонку за фичами, а на совместимость и более плотный
>>> багфикс, я вполне способен.
> 
>> А что делать в период фриза тем, у кого пакеты в порядке? Плевать в
>> потолок? Новую версию с новыми фичами выложить "на потестировать" не
>> дадут...
> 
>   Если у Вас много свободного времени, возьмите в поддержку
>   больше пакетов =).
> 

А толку то ? Если Фриз ;)

Rgds,
Rider

Re: [devel] [sisyphus -> devel] Стабильный Сизиф

[Fr. Br. George]

On Thu, Jun 15, 2006 at 04:04:50PM +0400, Damir Shayhutdinov wrote:
> 15.06.06, Fr. Br. George<george@altlinux.ru> написал(а):
> > А вот выдержать месяц-два заморозки самого Сизифа, да и поработать в
> > это время не на гонку за фичами, а на совместимость и более плотный
> > багфикс, я вполне способен.
> А что делать в период фриза тем, у кого пакеты в порядке? Плевать в
> потолок? Новую версию с новыми фичами выложить "на потестировать" не
> дадут...
Подождать месяц-два. Пользоваться своими пакетами в своё удовльствие вам
же никто не сможет запретить! Поправить чужой, но нужный вам пакет --
GIT эту процедуру сделает намного более простой. Не все же такие
аккуратные, как вы -- или такие везучие, а релиз хочется иметь
стабильный. Вопрос в том, интересно ли нам делать стабильный Сизиф, или
только свой стабильный пакет.

-- 
			George V Kouryachy (aka Fr. Br. George)
			mailto:george at altlinux_ru

Re: [devel] [sisyphus -> devel] Стабильный Сизиф

[Led]

В сообщении от 15 июня 2006 19:44 Fr. Br. George написал(a):
> On Thu, Jun 15, 2006 at 04:04:50PM +0400, Damir Shayhutdinov wrote:
> > 15.06.06, Fr. Br. George<george@altlinux.ru> написал(а):
> > > А вот выдержать месяц-два заморозки самого Сизифа, да и поработать в
> > > это время не на гонку за фичами, а на совместимость и более плотный
> > > багфикс, я вполне способен.
> >
> > А что делать в период фриза тем, у кого пакеты в порядке? Плевать в
> > потолок? Новую версию с новыми фичами выложить "на потестировать" не
> > дадут...
>
> Подождать месяц-два. Пользоваться своими пакетами в своё удовльствие вам
> же никто не сможет запретить! Поправить чужой, но нужный вам пакет --
> GIT эту процедуру сделает намного более простой. Не все же такие
> аккуратные, как вы -- или такие везучие, а релиз хочется иметь
> стабильный. Вопрос в том, интересно ли нам делать стабильный Сизиф, или
> только свой стабильный пакет.

"только свой стабильный пакет" - интересно. "делать стабильный Сизиф" - 
неинтересно из-за расплывчатости самой сущности "Сизиф".

-- 
Led.

Re: [devel] [sisyphus -> devel] Стабильный Сизиф

[Fr. Br. George]

On Thu, Jun 15, 2006 at 07:50:34PM +0300, Led wrote:
> > Подождать месяц-два. Пользоваться своими пакетами в своё удовльствие вам
> > же никто не сможет запретить! Поправить чужой, но нужный вам пакет --
> > GIT эту процедуру сделает намного более простой. Не все же такие
> > аккуратные, как вы -- или такие везучие, а релиз хочется иметь
> > стабильный. Вопрос в том, интересно ли нам делать стабильный Сизиф, или
> > только свой стабильный пакет.
> 
> "только свой стабильный пакет" - интересно. "делать стабильный Сизиф" - 
> неинтересно из-за расплывчатости самой сущности "Сизиф".
Понятно, спасибо. То есть в ряды самопроизвольных NMUpdater-ов вас
записывать не надо. Но ведь в любом случае на вас можно рассчитываь,
верно? Что ваш пакет во время фриза будет стабилен? А это -- больше
половины дела. Это -- главное.

Что касается расплывчивости понятия "Сизиф"... Для меня "Сизиф" -- это
то, что стоит на моём компьютере после последнего dist-upgrade из Сизифа
:). А оно там стоит временами очень неохотно. И было бы хорошо, если бы
эти времена можно было предугадать, и совсем здорово, если бы можно было
предугадать времена, когда оно, наоборот, будет стоять железно, как
после двойной дозы препарата, названия которого не напишу по причине
антиспам-фильтров.

-- 
			George V Kouryachy (aka Fr. Br. George)
			mailto:george at altlinux_ru

Re: [devel] [sisyphus -> devel] Стабильный Сизиф

[Led]

В сообщении от 15 июня 2006 20:00 Fr. Br. George написал(a):
> On Thu, Jun 15, 2006 at 07:50:34PM +0300, Led wrote:
> > > Подождать месяц-два. Пользоваться своими пакетами в своё удовльствие
> > > вам же никто не сможет запретить! Поправить чужой, но нужный вам пакет
> > > -- GIT эту процедуру сделает намного более простой. Не все же такие
> > > аккуратные, как вы -- или такие везучие, а релиз хочется иметь
> > > стабильный. Вопрос в том, интересно ли нам делать стабильный Сизиф, или
> > > только свой стабильный пакет.
> >
> > "только свой стабильный пакет" - интересно. "делать стабильный Сизиф" -
> > неинтересно из-за расплывчатости самой сущности "Сизиф".
>
> Понятно, спасибо. То есть в ряды самопроизвольных NMUpdater-ов вас
> записывать не надо. Но ведь в любом случае на вас можно рассчитываь,
> верно? Что ваш пакет во время фриза будет стабилен? А это -- больше
> половины дела. Это -- главное.
>
> Что касается расплывчивости понятия "Сизиф"... Для меня "Сизиф" -- это
> то, что стоит на моём компьютере после последнего dist-upgrade из Сизифа
>
> :). А оно там стоит временами очень неохотно. И было бы хорошо, если бы
>
> эти времена можно было предугадать, и совсем здорово, если бы можно было
> предугадать времена, когда оно, наоборот, будет стоять железно, как
> после двойной дозы препарата, названия которого не напишу по причине
> антиспам-фильтров.

Пусть не "железно", но хотя бы непротиворечиво - это уже ИМХО как минимум 
полдела. Сейчас же эту "непротиворечивость" приходится поддерживать вручную 
путём регулярного отслеживания рассылки, развешивания Hold'ов, элементарной 
правки и пересборки в локалном хешере хотя бы части необходимых "вытесняемых" 
пакетов. Так вот, на эту (в принципе автоматизируемую на уровне репозитария) 
операцию поддержки непротиворечивости, к сожалению, уходит много времени, 
которое можно (и хотелось бы) потратить на другое, неавтоматизируемое (в том 
числе и на тестирование/исправление).

-- 
Led.

Re: [devel] [sisyphus -> devel] Стабильный Сизиф

[Fr. Br. George]

On Thu, Jun 15, 2006 at 08:16:15PM +0300, Led wrote:

> Пусть не "железно", но хотя бы непротиворечиво - это уже ИМХО как
> минимум полдела. Сейчас же эту "непротиворечивость" приходится
> поддерживать вручную путём регулярного отслеживания рассылки,
> развешивания Hold'ов, элементарной правки и пересборки в локалном
> хешере хотя бы части необходимых "вытесняемых" пакетов. Так вот, на
> эту (в принципе автоматизируемую на уровне репозитария) операцию
> поддержки непротиворечивости, к сожалению, уходит много времени,
> которое можно (и хотелось бы) потратить на другое, неавтоматизируемое
> (в том числе и на тестирование/исправление).
Правильно. Но давайте начнём хотя бы с этого. С того, чтобы Сизиф был
гарантированно непротиворечивым хотя бы два раза в год, притом известно
когда. Пускай вручную.

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

-- 
			George V Kouryachy (aka Fr. Br. George)
			mailto:george at altlinux_ru

Re: [devel] [sisyphus -> devel] Стабильный Сизиф

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

On Thu, Jun 15, 2006 at 09:25:21PM +0400, Fr. Br. George wrote:

FBG> А вопрос, надо ли _всегда_ держать эту непротиворечивость, и _не_
FBG> пускать пакеты, которые её ломают, предтавляется очень тонким и полным
FBG> подводных граблей. Если у кого-то получится сделать такой автомат,
FBG> сообщество скажет очень большое спасибо. Но это тема другой ветки
FBG> разговора.

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

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

http://freesource.info
----------------------------------------------------------------------------

Re: [devel] [sisyphus -> devel] Стабильный Сизиф

[Led]

В сообщении от 16 июня 2006 13:31 Денис Смирнов написал(a):
> On Thu, Jun 15, 2006 at 09:25:21PM +0400, Fr. Br. George wrote:
>
> FBG> А вопрос, надо ли _всегда_ держать эту непротиворечивость, и _не_
> FBG> пускать пакеты, которые её ломают, предтавляется очень тонким и полным
> FBG> подводных граблей. Если у кого-то получится сделать такой автомат,
> FBG> сообщество скажет очень большое спасибо. Но это тема другой ветки
> FBG> разговора.
>
> Когда я последний раз приезжал в офис мы долго говорили о возможности
> написать такую систему, которая бы автоматически поддерживала некий
> Sisyphus2, который был бы всегда замкнутым, и добавления в которой
> транзакционны.

Мне кажется, что репозитарий должен отличаться от проиндексированной свалки 
файлов как раз непротиворечивостью и целостностью...

-- 
Led.

Re: [devel] [sisyphus -> devel] Стабильный Сизиф

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

On Fri, Jun 16, 2006 at 01:44:05PM +0300, Led wrote:

L> Мне кажется, что репозитарий должен отличаться от проиндексированной свалки 
L> файлов как раз непротиворечивостью и целостностью...

Только понятия эти могут трактоваться по разному.

Автоматически мы можем проверить только целостность репозитория, как неких
объектов с некими зависимостями без учета их работоспособности, увы.

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

http://freesource.info
----------------------------------------------------------------------------
гм-м-м... я всё-таки добил последний Сизифный dia и он... заработал! :)
		-- mouse in #7254

Re: [devel] [sisyphus -> devel] Стабильный Сизиф

[Led]

В сообщении от 16 июня 2006 17:18 Денис Смирнов написал(a):
> On Fri, Jun 16, 2006 at 01:44:05PM +0300, Led wrote:
>
> L> Мне кажется, что репозитарий должен отличаться от проиндексированной
> свалки L> файлов как раз непротиворечивостью и целостностью...
>
> Только понятия эти могут трактоваться по разному.
>
> Автоматически мы можем проверить только целостность репозитория, как неких
> объектов с некими зависимостями без учета их работоспособности, увы.

Дык о чём и речь! Но хоть именно такую целостность бы! Просто пока натр... 
намучишся с глюками, вызванными "нецелостностью", проверять работоспособность 
(как правило) уже не остаётся ни времени, ни желания :(

-- 
Led.

Re: [devel] [sisyphus -> devel] Стабильный Сизиф

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

On Fri, Jun 16, 2006 at 06:00:56PM +0300, Led wrote:

L> Дык о чём и речь! Но хоть именно такую целостность бы! Просто пока натр... 
L> намучишся с глюками, вызванными "нецелостностью", проверять работоспособность 
L> (как правило) уже не остаётся ни времени, ни желания :(

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

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

http://freesource.info
----------------------------------------------------------------------------

Re: [devel] [sisyphus -> devel] Стабильный Сизиф

[Led]

В сообщении от 16 июня 2006 18:17 Денис Смирнов написал(a):
> On Fri, Jun 16, 2006 at 06:00:56PM +0300, Led wrote:
>
> L> Дык о чём и речь! Но хоть именно такую целостность бы! Просто пока
> натр... L> намучишся с глюками, вызванными "нецелостностью", проверять
> работоспособность L> (как правило) уже не остаётся ни времени, ни желания
> :(
>
> А это та идея, которую я периодически громко пытаюсь озвучить --
> необходимость создания второго репозитория, генерируемого на основе
> Сизифа, в котором производятся только транзакционные изменения всегда
> сохраняющие целостность.

И я об этом... почти. Но я всё же не считаю, что нужен "второй репозитарий". 
По причине того, что нецелостный - это ИМХО и не репозитарий по большому 
счёту. Эту "нецелостную" свалку файлов можно назвать incoming-свалка, 
post-incoming-свалка - не суть важно. А Sisyphus - да, нестабильный, глючный 
по-опредлению, но целостный.

-- 
Led.

Re: [devel] [sisyphus -> devel] Стабильный Сизиф

[Michael Shigorin]

On Thu, Jun 15, 2006 at 09:00:09PM +0400, Fr. Br. George wrote:
> И было бы хорошо, если бы эти времена можно было предугадать, и
> совсем здорово, если бы можно было предугадать времена, когда

Ты, разумеется, читаешь (а то и пополняешь)
http://wiki.sisyphus.ru/changes?

(был ещё проект Sisyphus newsletter, который помер не родившись;
в т.ч. из-за обсуждаемых здесь пользовательских эффектов, тогда
как раз касательно updates человек решил пойти на Debian)

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

[devel] Стабильный пакет > Стабильный Сизиф

[Slava Semushin]

--- Fr. Br. George 2006-06-15 20:44:44 +0400
+++ Vyacheslav Semushin 2006-06-16 10:08:44 +0700

FBG> Вопрос в том, интересно ли нам делать стабильный Сизиф, или
FBG> только свой стабильный пакет.

    На сей счет есть несколько соображений:

    - нельзя объять не объятное (с)
    - начинать менять мир лучше с себя

    На этом основании я 1) заинтересован в стабильном Сизифе б) понимаю,
    что своими силами я его таким полностью сделать не смогу и поэтому я
    просто делаю стабильными свои пакеты.

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


-- 
+ Slava Semushin | php-coder @ ngs.ru
+ ALT Linux Team | php-coder @ altlinux.ru
+ Expand QA Team | vsemushin @ swsoft.com

Re: [devel] Стабильный пакет > Стабильный Сизиф

[Led]

В сообщении от 16 июня 2006 06:14 Slava Semushin написал(a):
> --- Fr. Br. George 2006-06-15 20:44:44 +0400
> +++ Vyacheslav Semushin 2006-06-16 10:08:44 +0700
>
> FBG> Вопрос в том, интересно ли нам делать стабильный Сизиф, или
> FBG> только свой стабильный пакет.
>
>     На сей счет есть несколько соображений:
>
>     - нельзя объять не объятное (с)
>     - начинать менять мир лучше с себя
>
>     На этом основании я 1) заинтересован в стабильном Сизифе б) понимаю,
>     что своими силами я его таким полностью сделать не смогу и поэтому я
>     просто делаю стабильными свои пакеты.
>
>     Теоретически, если каждый будет очень внимательно следить за своими
>     пакетами и заботиться об их стабильности, то и весь Сизиф таким
>     станет, потому что он состоит из этих пакетов.

А практически, как ни старайся и не "вылизуй" свои пакеты, но ЦЕЛОСТНОСТЬ 
Сизифа отдельный и мейнтейнер, и все мейнтейнеры вместе обеспечить не смогут. 
А без целостности Сизиф стабильным никогда не станет:)

-- 
Led.

Re: [devel] Стабильный пакет > Стабильный Сизиф

[Dmitry V. Levin]

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

On Fri, Jun 16, 2006 at 12:18:50PM +0300, Led wrote:
> В сообщении от 16 июня 2006 06:14 Slava Semushin написал(a):
> > --- Fr. Br. George 2006-06-15 20:44:44 +0400
> > +++ Vyacheslav Semushin 2006-06-16 10:08:44 +0700
> >
> > FBG> Вопрос в том, интересно ли нам делать стабильный Сизиф, или
> > FBG> только свой стабильный пакет.
> >
> >     На сей счет есть несколько соображений:
> >
> >     - нельзя объять не объятное (с)
> >     - начинать менять мир лучше с себя
> >
> >     На этом основании я 1) заинтересован в стабильном Сизифе б) понимаю,
> >     что своими силами я его таким полностью сделать не смогу и поэтому я
> >     просто делаю стабильными свои пакеты.
> >
> >     Теоретически, если каждый будет очень внимательно следить за своими
> >     пакетами и заботиться об их стабильности, то и весь Сизиф таким
> >     станет, потому что он состоит из этих пакетов.
> 
> А практически, как ни старайся и не "вылизуй" свои пакеты, но ЦЕЛОСТНОСТЬ 
> Сизифа отдельный и мейнтейнер, и все мейнтейнеры вместе обеспечить не смогут. 

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

Например, целостность репозитория размером и составом напоминающего Owl
может поддерживать 1 (один) мантейнер.
Задача в том, чтобы разработать технологии и организовать процесс таким
образом, чтобы работать с репозиториями бОльшего объёма.


-- 
ldv

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

Re: [devel] Стабильный пакет > Стабильный Сизиф

[Led]

В сообщении от 16 июня 2006 15:07 Dmitry V. Levin написал(a):
> On Fri, Jun 16, 2006 at 12:18:50PM +0300, Led wrote:
> > В сообщении от 16 июня 2006 06:14 Slava Semushin написал(a):
> > > --- Fr. Br. George 2006-06-15 20:44:44 +0400
> > > +++ Vyacheslav Semushin 2006-06-16 10:08:44 +0700
> > >
> > > FBG> Вопрос в том, интересно ли нам делать стабильный Сизиф, или
> > > FBG> только свой стабильный пакет.
> > >
> > >     На сей счет есть несколько соображений:
> > >
> > >     - нельзя объять не объятное (с)
> > >     - начинать менять мир лучше с себя
> > >
> > >     На этом основании я 1) заинтересован в стабильном Сизифе б)
> > > понимаю, что своими силами я его таким полностью сделать не смогу и
> > > поэтому я просто делаю стабильными свои пакеты.
> > >
> > >     Теоретически, если каждый будет очень внимательно следить за своими
> > >     пакетами и заботиться об их стабильности, то и весь Сизиф таким
> > >     станет, потому что он состоит из этих пакетов.
> >
> > А практически, как ни старайся и не "вылизуй" свои пакеты, но ЦЕЛОСТНОСТЬ
> > Сизифа отдельный и мейнтейнер, и все мейнтейнеры вместе обеспечить не
> > смогут.
>
> Вы не правы.  Сложность обеспечения целостности зависит от трёх факторов:
> размера репозитория, используемых технологий и организации труда.
>
> Например, целостность репозитория размером и составом напоминающего Owl
> может поддерживать 1 (один) мантейнер.

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

> Задача в том, чтобы разработать технологии и организовать процесс таким
> образом, чтобы работать с репозиториями бОльшего объёма.

Так есть такая задача или нет? Я слышал только реплики, что это не очень-то и 
нужно или "вручную, два раза в год".

-- 
Led.

Re: [devel] Стабильный пакет > Стабильный Сизиф

[Dmitry V. Levin]

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

On Fri, Jun 16, 2006 at 03:13:18PM +0300, Led wrote:
> В сообщении от 16 июня 2006 15:07 Dmitry V. Levin написал(a):
> > On Fri, Jun 16, 2006 at 12:18:50PM +0300, Led wrote:
[...]
> > > А практически, как ни старайся и не "вылизуй" свои пакеты, но ЦЕЛОСТНОСТЬ
> > > Сизифа отдельный и мейнтейнер, и все мейнтейнеры вместе обеспечить не
> > > смогут.
> >
> > Вы не правы.  Сложность обеспечения целостности зависит от трёх факторов:
> > размера репозитория, используемых технологий и организации труда.
> >
> > Например, целостность репозитория размером и составом напоминающего Owl
> > может поддерживать 1 (один) мантейнер.
> 
> Я имел ввиду, что просто мантейнер(ы) если у него (них) нет доступу к 
> администрированию репозитария не смогут поддерживать его перманентную 
> целостность (если, конечно, мантейнеров у репозитрая больше одного)

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

> > Задача в том, чтобы разработать технологии и организовать процесс таким
> > образом, чтобы работать с репозиториями бОльшего объёма.
> 
> Так есть такая задача или нет? Я слышал только реплики, что это не очень-то и 
> нужно или "вручную, два раза в год".

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


-- 
ldv

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

Re: [devel] [sisyphus -> devel] Стабильный Сизиф

[Alexey Rusakov]

Damir Shayhutdinov wrote:
> 15.06.06, Fr. Br. George<george@altlinux.ru> написал(а):
>> А вот выдержать месяц-два заморозки самого Сизифа, да и поработать в
>> это время не на гонку за фичами, а на совместимость и более плотный
>> багфикс, я вполне способен.
> А что делать в период фриза тем, у кого пакеты в порядке? Плевать в
> потолок? Новую версию с новыми фичами выложить "на потестировать" не
> дадут...
Во-первых, есть Дедал. Во-вторых, помогать тем, у кого пакеты не в
порядке :)

-- 
    Alexey "Ktirf" Rusakov

Re: [devel] [sisyphus -> devel] Стабильный Сизиф

[Damir Shayhutdinov]

16.06.06, Alexey Rusakov<ktirf@altlinux.org> написал(а):
> > А что делать в период фриза тем, у кого пакеты в порядке? Плевать в
> > потолок? Новую версию с новыми фичами выложить "на потестировать" не
> > дадут...
> Во-первых, есть Дедал.
Ага, с отсутствующим QA и таким же контингентом тестеров :( В
Sisyphus/x86_64 частично похожая ситуация.

> Во-вторых, помогать тем, у кого пакеты не в
> порядке :)
Дык я и так вроде немножко помогаю. Правда получается плохо.
Но вот например у меня на машине есть собранный abiword под x86_64, и
в Sisyphus/i586 он есть. А вот в Sisyphus/x86_64 его нету - не прошел
сборку по зависимостям (libnautilus-devel). И что делать - непонятно.
;)

Re: [devel] [sisyphus -> devel] [JT] Стабильный Сизиф

[Pavlov Konstantin]

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

On Friday 16 June 2006 00:46, Damir Shayhutdinov wrote:

> > Во-первых, есть Дедал.
>
> Ага, с отсутствующим QA и таким же контингентом тестеров :( В
> Sisyphus/x86_64 частично похожая ситуация.
>
> > Во-вторых, помогать тем, у кого пакеты не в
> > порядке :)
>
> Дык я и так вроде немножко помогаю. Правда получается плохо.
Не прибедняйся. :)

-- 
Pavlov Konstantin,
ALT Linux Team,
VideoLAN Team,
jid: thresh@altlinux.org

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

Re: [devel] [sisyphus -> devel] Стабильный Сизиф

[Anton Farygin]

Damir Shayhutdinov wrote:

> Дык я и так вроде немножко помогаю. Правда получается плохо.
> Но вот например у меня на машине есть собранный abiword под x86_64, и
> в Sisyphus/i586 он есть. А вот в Sisyphus/x86_64 его нету - не прошел
> сборку по зависимостям (libnautilus-devel). И что делать - непонятно.
> ;)

Фиксить. Делать NMU на libnautilus-devel

Rgds,
Rider

Re: [devel] [sisyphus -> devel] Стабильный Сизиф

[Damir Shayhutdinov]

16.06.06, Anton Farygin<rider@altlinux.com> написал(а):
> Damir Shayhutdinov wrote:
>
> > Дык я и так вроде немножко помогаю. Правда получается плохо.
> > Но вот например у меня на машине есть собранный abiword под x86_64, и
> > в Sisyphus/i586 он есть. А вот в Sisyphus/x86_64 его нету - не прошел
> > сборку по зависимостям (libnautilus-devel). И что делать - непонятно.
> > ;)
>
> Фиксить. Делать NMU на libnautilus-devel
Не все так просто :( libnautilius сам по себе собирается. Он не прошел
из-за libeel.
Покопался в архиве - и нашел, как ты сам жаловался на nautilus именно
по этому поводу.

Re: [devel] [sisyphus -> devel] Стабильный Сизиф -> nautilus

[Anton Farygin]

Damir Shayhutdinov wrote:
> 16.06.06, Anton Farygin<rider@altlinux.com> написал(а):
>> Damir Shayhutdinov wrote:
>>
>>> Дык я и так вроде немножко помогаю. Правда получается плохо.
>>> Но вот например у меня на машине есть собранный abiword под x86_64, и
>>> в Sisyphus/i586 он есть. А вот в Sisyphus/x86_64 его нету - не прошел
>>> сборку по зависимостям (libnautilus-devel). И что делать - непонятно.
>>> ;)
>> Фиксить. Делать NMU на libnautilus-devel
> Не все так просто :( libnautilius сам по себе собирается. Он не прошел
> из-за libeel.
> Покопался в архиве - и нашел, как ты сам жаловался на nautilus именно
> по этому поводу.

В данный момент nautilus не собирается по другим причинам.

Всё что нужно - это просто его собрать.

nautilus-2.14.1:

         prefix:                 /usr
         source code location:   .
         compiler:               x86_64-alt-linux-gcc
         tracker support:        no
         beagle support:         no

         profiling support:      off

+ '[' -n '' ']'
+ NPROCS=1
+ make -j1
make: Entering directory `/home/rider/RPM/nautilus/BUILD/nautilus-2.14.1'
make: *** No targets.  Stop.
make: Leaving directory `/home/rider/RPM/nautilus/BUILD/nautilus-2.14.1'
ошибка: Неверный код возврата из 
/home/rider/RPM/nautilus/TMP/rpm-tmp.6813 (%build)

А это в свою очередь вылезает из-за:

config.status: creating Makefile
sed: file ./confstatZv1374/subs-4.sed line 29: unterminated `s' command
config.status: creating cut-n-paste-code/Makefile


собственно у мантейнра nautilus есть доступ к x86_64 среде.. Я так 
понимаю что просто нет времени/желания исправлять.

Rgds,
Rider

Re: [devel] [sisyphus -> devel] Стабильный Сизиф -> nautilus

[Anton Farygin]

Anton Farygin wrote:
> Damir Shayhutdinov wrote:
>> 16.06.06, Anton Farygin<rider@altlinux.com> написал(а):
>>> Damir Shayhutdinov wrote:
>>>
>>>> Дык я и так вроде немножко помогаю. Правда получается плохо.
>>>> Но вот например у меня на машине есть собранный abiword под x86_64, и
>>>> в Sisyphus/i586 он есть. А вот в Sisyphus/x86_64 его нету - не прошел
>>>> сборку по зависимостям (libnautilus-devel). И что делать - непонятно.
>>>> ;)
>>> Фиксить. Делать NMU на libnautilus-devel
>> Не все так просто :( libnautilius сам по себе собирается. Он не прошел
>> из-за libeel.
>> Покопался в архиве - и нашел, как ты сам жаловался на nautilus именно
>> по этому поводу.
> 
> В данный момент nautilus не собирается по другим причинам.
> 
> Всё что нужно - это просто его собрать.
> 
> nautilus-2.14.1:
> 
>          prefix:                 /usr
>          source code location:   .
>          compiler:               x86_64-alt-linux-gcc
>          tracker support:        no
>          beagle support:         no
> 
>          profiling support:      off
> 
> + '[' -n '' ']'
> + NPROCS=1
> + make -j1
> make: Entering directory `/home/rider/RPM/nautilus/BUILD/nautilus-2.14.1'
> make: *** No targets.  Stop.
> make: Leaving directory `/home/rider/RPM/nautilus/BUILD/nautilus-2.14.1'
> ошибка: Неверный код возврата из 
> /home/rider/RPM/nautilus/TMP/rpm-tmp.6813 (%build)
> 
> А это в свою очередь вылезает из-за:
> 
> config.status: creating Makefile
> sed: file ./confstatZv1374/subs-4.sed line 29: unterminated `s' command
> config.status: creating cut-n-paste-code/Makefile
> 
> 
> собственно у мантейнра nautilus есть доступ к x86_64 среде.. Я так 
> понимаю что просто нет времени/желания исправлять.

В продолжение:
sed падает вот на этом:
s,@ALL_LINGUAS@,af am ar az be bg bn bs ca cs cy da de el en_CA en_GB
es et eu fa fi fr ga gl gu he hi hr hu id is it ja ka
km ko ku li lt lv mi mk ml mn ms nb ne nl nn no nso pa
pl pt pt_BR ro ru rw sk sl sq sr sr@Latn sr@ije sv ta
te th tk tr uk vi wa xh yi zh_CN zh_HK zh_TW zu,;t t


Rgds,
Rider

Re: [devel] [sisyphus -> devel] Стабильный Сизиф -> nautilus

[Nick S. Grechukh]

В сообщении от 16 июня 2006 10:44 Anton Farygin написал(a):
> В продолжение:
> sed падает вот на этом:
> s,@ALL_LINGUAS@,af am ar az be bg bn bs ca cs cy da de el en_CA en_GB
> es et eu fa fi fr ga gl gu he hi hr hu id is it ja ka
> km ko ku li lt lv mi mk ml mn ms nb ne nl nn no nso pa
> pl pt pt_BR ro ru rw sk sl sq sr sr@Latn sr@ije sv ta
> te th tk tr uk vi wa xh yi zh_CN zh_HK zh_TW zu,;t t
ээ, гм. а почему на i586 собирается?

Re: [devel] [sisyphus -> devel] Стабильный Сизиф -> nautilus

[Anton Farygin]

Nick S. Grechukh wrote:
> В сообщении от 16 июня 2006 10:44 Anton Farygin написал(a):
>> В продолжение:
>> sed падает вот на этом:
>> s,@ALL_LINGUAS@,af am ar az be bg bn bs ca cs cy da de el en_CA en_GB
>> es et eu fa fi fr ga gl gu he hi hr hu id is it ja ka
>> km ko ku li lt lv mi mk ml mn ms nb ne nl nn no nso pa
>> pl pt pt_BR ro ru rw sk sl sq sr sr@Latn sr@ije sv ta
>> te th tk tr uk vi wa xh yi zh_CN zh_HK zh_TW zu,;t t
> ээ, гм. а почему на i586 собирается?

Без понятия.

Rgds,
Rider

Re: [devel] [sisyphus -> devel] Стабильный Сизиф -> nautilus

[Alexey Rusakov]

Anton Farygin пишет:
>> собственно у мантейнра nautilus есть доступ к x86_64 среде.. Я так 
>> понимаю что просто нет времени/желания исправлять.
>>     
Не хочу ни на кого сваливать вину, но 5 июня пакет nautilus-2.14.1-alt4 
с исправлением этой проблемы был отправлен в Сизиф.  Результат сборки 
можно посмотреть, например, здесь: 
http://lists.altlinux.org/pipermail/sisyphus-incominger/2006-June/002316.html
Если не совсем понятно - пакеты libeel и libeel-devel собираются из 
одного исходного пакета. Как удалось получить такую неразрешённую 
зависимость, я не знаю. Внимание incoming'а на это я обратил в тот же 
день. Результат, как я понимаю, в том, что мне нужно переотправить 
пакет. Замечу, что после изменения порядка сборки пакетов это уже далеко 
не первый раз, когда приходится прибегать к дополнительной пересборке 
из-за криво разрешившихся зависимостей.

> В продолжение:
> sed падает вот на этом:
> s,@ALL_LINGUAS@,af am ar az be bg bn bs ca cs cy da de el en_CA en_GB
> es et eu fa fi fr ga gl gu he hi hr hu id is it ja ka
> km ko ku li lt lv mi mk ml mn ms nb ne nl nn no nso pa
> pl pt pt_BR ro ru rw sk sl sq sr sr@Latn sr@ije sv ta
> te th tk tr uk vi wa xh yi zh_CN zh_HK zh_TW zu,;t t
>   
Спаси-ибо. Что бы я без вас делал. Когда я спрашивал о том, как это 
лучше пофиксить, хоть бы одна св^Wживая душа откликнулась. Точнее, одна 
и откликнулась - mike@, которому почему-то до всего есть дело. У всех 
остальных, я так понимаю, просто нет этих, как их, времени/желания.
Извините, вспылил.

-- 
  Alexey "Ktirf" Rusakov

Re: [devel] [sisyphus -> devel] Стабильный Сизиф -> nautilus

[Epiphanov Sergei]

В сообщении от Monday 19 June 2006 01:31 Alexey Rusakov написал(a):
> > В продолжение:
> > sed падает вот на этом:
> > s,@ALL_LINGUAS@,af am ar az be bg bn bs ca cs cy da de el en_CA en_GB
> > es et eu fa fi fr ga gl gu he hi hr hu id is it ja ka
> > km ko ku li lt lv mi mk ml mn ms nb ne nl nn no nso pa
> > pl pt pt_BR ro ru rw sk sl sq sr sr@Latn sr@ije sv ta
> > te th tk tr uk vi wa xh yi zh_CN zh_HK zh_TW zu,;t t
> >  
>
> Спаси-ибо. Что бы я без вас делал. Когда я спрашивал о том, как это
> лучше пофиксить, хоть бы одна св^Wживая душа откликнулась. Точнее, одна
> и откликнулась - mike@, которому почему-то до всего есть дело. У всех
> остальных, я так понимаю, просто нет этих, как их, времени/желания.
> Извините, вспылил.

Бывает. Мне, например, сложно помогать из-за того, что Сизиф получаю где-то 
раз в месяц-полтора, а тащить через сотовый телефон мегабайтные пакеты для 
проверки очень дорого и долго. Так и в трубу недолго вылететь. :)

-- 
С уважением, Епифанов Сергей

Re: [devel] [sisyphus -> devel] Стабильный Сизиф -> nautilus

[Anton Farygin]

Alexey Rusakov wrote:
> Anton Farygin пишет:
>>> собственно у мантейнра nautilus есть доступ к x86_64 среде.. Я так 
>>> понимаю что просто нет времени/желания исправлять.
>>>     
> Не хочу ни на кого сваливать вину, но 5 июня пакет nautilus-2.14.1-alt4 
> с исправлением этой проблемы был отправлен в Сизиф.  Результат сборки 
> можно посмотреть, например, здесь: 
> http://lists.altlinux.org/pipermail/sisyphus-incominger/2006-June/002316.html
> Если не совсем понятно - пакеты libeel и libeel-devel собираются из 
> одного исходного пакета. Как удалось получить такую неразрешённую 
> зависимость, я не знаю. Внимание incoming'а на это я обратил в тот же 
> день. Результат, как я понимаю, в том, что мне нужно переотправить 
> пакет. Замечу, что после изменения порядка сборки пакетов это уже далеко 
> не первый раз, когда приходится прибегать к дополнительной пересборке 
> из-за криво разрешившихся зависимостей.

Аналогично. Но я в этом случае долго не думаю.. release++ и вперёд.


> 
>> В продолжение:
>> sed падает вот на этом:
>> s,@ALL_LINGUAS@,af am ar az be bg bn bs ca cs cy da de el en_CA en_GB
>> es et eu fa fi fr ga gl gu he hi hr hu id is it ja ka
>> km ko ku li lt lv mi mk ml mn ms nb ne nl nn no nso pa
>> pl pt pt_BR ro ru rw sk sl sq sr sr@Latn sr@ije sv ta
>> te th tk tr uk vi wa xh yi zh_CN zh_HK zh_TW zu,;t t
>>   
> Спаси-ибо. Что бы я без вас делал. Когда я спрашивал о том, как это 
> лучше пофиксить, хоть бы одна св^Wживая душа откликнулась. Точнее, одна 
> и откликнулась - mike@, которому почему-то до всего есть дело. У всех 
> остальных, я так понимаю, просто нет этих, как их, времени/желания.
> Извините, вспылил.

Я не видел этого письма, к сожалению.

Так проблема ещё актуальна ?

Почему оно только на x86_64 вылезает ?

Rgds,
Rider

Re: [devel] [sisyphus -> devel] Стабильный Сизиф -> nautilus

[Alexey Rusakov]

Anton Farygin пишет:
> Так проблема ещё актуальна ?
>   
Уже нет, сегодня исправленный nautilus добрался-таки до Сизифа. Теперь 
нужно точно таким же образом протолкнуть исправленный file-roller, 
увязший в incoming по той же причине.

-- 
  Alexey "Ktirf" Rusakov

Re: [devel] [sisyphus -> devel] Стабильный Сизиф

[Michael Shigorin]

On Fri, Jun 16, 2006 at 12:46:14AM +0400, Damir Shayhutdinov wrote:
> > > А что делать в период фриза тем, у кого пакеты в порядке?
> > > Плевать в потолок? Новую версию с новыми фичами выложить
> > > "на потестировать" не дадут...
> > Во-первых, есть Дедал.
> Ага, с отсутствующим QA и таким же контингентом тестеров :(
> В Sisyphus/x86_64 частично похожая ситуация.

У backports та же проблема, но требовать её исправления от aris@
я лично никак не могу.  Если кто-то быстрее управится, то
предоставить молотилку, где можно пускать QA-роботов, за лето 
должно выйти.

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

Re: [devel] [sisyphus -> devel] Стабильный Сизиф

[Michael Shigorin]

On Thu, Jun 15, 2006 at 04:04:50PM +0400, Damir Shayhutdinov wrote:
> > А вот выдержать месяц-два заморозки самого Сизифа, да и
> > поработать в это время не на гонку за фичами, а на
> > совместимость и более плотный багфикс, я вполне способен.
> А что делать в период фриза тем, у кого пакеты в порядке?

Если есть настроение -- помочь коллегам?  Например, анонсировав
"а я тут умею починять 64-битные примусы" ;-)

В команде наметилось несколько людей, которые помогают другим.
Мне кажется, другие им по жизни признательны.

> Плевать в потолок? Новую версию с новыми фичами выложить "на
> потестировать" не дадут...

Это в lkml вроде проходили, нет?  Может, кому-нибудь ещё
интересна история больших апстримов?  Я вот как-то интересовался
и ветками в ядре, и тем, как оцикливали mozilla.  Поучительно.


В ядре получалось так, что если прорывались деятели с фичами при
заморозке (и отсутствии unstable), то некоторое время штормило 
и нередко заканчивалось выбрасыванием нафиг притащенного.
На сейчас они вроде как пришли не только к stable maintenance
отдельной командой, а и к тому, что kernel.org -- это вообще-то
не совсем stable, за production -- к вендорам.

Мне кажется, что это вполне параллельно sisyphus/stable/distros,
если под stable понимать то, о чём Гоша говорил "под декабрь".


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

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

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

Re: [devel] [sisyphus -> devel] Стабильный Сизиф

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

On Mon, Jun 19, 2006 at 12:03:34PM +0300, Michael Shigorin wrote:

MS> Мне кажется, что это вполне параллельно sisyphus/stable/distros,
MS> если под stable понимать то, о чём Гоша говорил "под декабрь".

Миша, посмотри на FreeBSD. Одним из моих вывдов с последнего чаепития на
Волхонке было то, что release engineering надо внимательно посмотреть
именно у них. Это особенно актуально в связи с плавным переходом на jit.

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

http://freesource.info
----------------------------------------------------------------------------
 * Vitls сегодня отмечает 3-х ление участия в проекте Linux Ru Net 

Re: [devel] [sisyphus -> devel] Стабильный Сизиф

[Michael Shigorin]

On Tue, Jun 20, 2006 at 07:59:30PM +0400, Денис Смирнов wrote:
> MS> Мне кажется, что это вполне параллельно sisyphus/stable/distros,
> MS> если под stable понимать то, о чём Гоша говорил "под декабрь".
> Миша, посмотри на FreeBSD. Одним из моих вывдов с последнего
> чаепития на Волхонке было то, что release engineering надо
> внимательно посмотреть именно у них. Это особенно актуально в
> связи с плавным переходом на jit.

В смысле по basesystem?  Не уверен, что смасштабируется.
Хотя поспрошать надо будет.

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

Re: [devel] [sisyphus -> devel] Стабильный Сизиф

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

On Wed, Jun 21, 2006 at 11:42:16AM +0300, Michael Shigorin wrote:

MS> В смысле по basesystem?  Не уверен, что смасштабируется.
MS> Хотя поспрошать надо будет.

По крайней мере git существенно облегчит мантейнером обслуживание разных
версий пакетов в разных branch'ах.

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

http://freesource.info
----------------------------------------------------------------------------
> alias char-major-10-134 fglrx
сурово. Это надо в фортунки ;)
		-- lakostis in community@

Re: [devel] [sisyphus -> devel] Стабильный Сизиф

[Fr. Br. George]

On Wed, Jun 21, 2006 at 11:42:16AM +0300, Michael Shigorin wrote:
> On Tue, Jun 20, 2006 at 07:59:30PM +0400, Денис Смирнов wrote:
> > MS> Мне кажется, что это вполне параллельно sisyphus/stable/distros,
> > MS> если под stable понимать то, о чём Гоша говорил "под декабрь".
> > Миша, посмотри на FreeBSD. Одним из моих вывдов с последнего
> > чаепития на Волхонке было то, что release engineering надо
> > внимательно посмотреть именно у них. Это особенно актуально в
> > связи с плавным переходом на jit.
> 
> В смысле по basesystem?  Не уверен, что смасштабируется.
> Хотя поспрошать надо будет.
Не только basesystem; разумеется, и база портов тоже. Особенность
FreeBSD -- в том, что basesystem они уделяют как можно больше внимания,
а ports base остаётся полностью на совести community. В нашем случае
больше свободы, но больше и разброса: помимо community имеются
заинтересованные в Сизифе организации (например, ALT), которые могут
использовать свои ресурсы для повышения внимания к той части
репозитория, которая им нужна. Это и будет подобие basesystem -- менее
строгое, но зато более гибкое.

-- 
			George V Kouryachy (aka Fr. Br. George)
			mailto:george at altlinux_ru

Re: [devel] [sisyphus -> devel] Стабильный Сизиф

[Michael Shigorin]

On Thu, Jun 22, 2006 at 02:48:17PM +0400, Fr. Br. George wrote:
> > > Миша, посмотри на FreeBSD. Одним из моих вывдов с последнего
> > В смысле по basesystem?  Не уверен, что смасштабируется.
> > Хотя поспрошать надо будет.
> Не только basesystem; разумеется, и база портов тоже.
> Особенность FreeBSD -- в том, что basesystem они уделяют как
> можно больше внимания, а ports base остаётся полностью на
> совести community.

Угу, и потом ловить клинья, как прошлым летом дырявый apache2
и разломанная сборка с починенным -- mod_perl2.

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

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

> В нашем случае больше свободы, но больше и разброса: помимо
> community имеются заинтересованные в Сизифе организации
> (например, ALT), которые могут использовать свои ресурсы для
> повышения внимания к той части репозитория, которая им нужна.
> Это и будет подобие basesystem -- менее строгое, но зато более
> гибкое.

Боюсь, даже Owl больше, чем FreeBSD basesystem.  Потому и 
сказал про масштабируемость.  Гентушники вон эту проблему тоже
то ли не видели, то ли решили, что бранчи портов им поддерживать
как сообществу дороговато и ненужновато.  Потому они тоже -- не
серверная ОС, за поддержку которой я как контора могу взяться.

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

Re: [devel] [sisyphus -> devel] Стабильный Сизиф

[Igor Zubkov]

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

В сообщении от 22 июня 2006 16:08 Michael Shigorin написал(a):
> On Thu, Jun 22, 2006 at 02:48:17PM +0400, Fr. Br. George wrote:
> > > > Миша, посмотри на FreeBSD. Одним из моих вывдов с последнего
> > >
> > > В смысле по basesystem?  Не уверен, что смасштабируется.
> > > Хотя поспрошать надо будет.
> >
> > Не только basesystem; разумеется, и база портов тоже.
> > Особенность FreeBSD -- в том, что basesystem они уделяют как
> > можно больше внимания, а ports base остаётся полностью на
> > совести community.
>
> Угу, и потом ловить клинья, как прошлым летом дырявый apache2
> и разломанная сборка с починенным -- mod_perl2.

И что там такого было?

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

Да. Они не бранчатся. А зачем?

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

И какие у неё признаки не сервантной ОС?

> > В нашем случае больше свободы, но больше и разброса: помимо
> > community имеются заинтересованные в Сизифе организации
> > (например, ALT), которые могут использовать свои ресурсы для
> > повышения внимания к той части репозитория, которая им нужна.
> > Это и будет подобие basesystem -- менее строгое, но зато более
> > гибкое.
>
> Боюсь, даже Owl больше, чем FreeBSD basesystem.  Потому и
> сказал про масштабируемость.  

> Гентушники вон эту проблему тоже 
> то ли не видели, то ли решили, что бранчи портов им поддерживать
> как сообществу дороговато и ненужновато.  Потому они тоже -- не
> серверная ОС, за поддержку которой я как контора могу взяться.

А я вот генту ставлю сейчас. Устал я от разломаного в репозитории kde...

-- 
Placebo - Peeping Tom

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

[devel] [JT] Re: [sisyphus -> devel] Стабильный Сизиф

[Michael Shigorin]

PreScriptum: это я к тому, куда стоит ходить за примерами
и про что проще сразу забыть.

On Thu, Jun 22, 2006 at 04:44:30PM +0300, Igor Zubkov wrote:
> > > > > Миша, посмотри на FreeBSD. Одним из моих вывдов с последнего
> > > > В смысле по basesystem?  Не уверен, что смасштабируется.
> > > > Хотя поспрошать надо будет.
> > > Не только basesystem; разумеется, и база портов тоже.
> > > Особенность FreeBSD -- в том, что basesystem они уделяют как
> > > можно больше внимания, а ports base остаётся полностью на
> > > совести community.
> > Угу, и потом ловить клинья, как прошлым летом дырявый apache2
> > и разломанная сборка с починенным -- mod_perl2.
> И что там такого было?

Съезд API в округе исправленной дырки, которую стоило фиксить.

> > Порты -- это поделка, которая фундаментально не годится для ОС,
> > за поддержку которуй можно отвечать.  Они не бранчатся.  Вообще.
> Да. Они не бранчатся. А зачем?

Затем, чтобы получалось на развёрнутых системах отделываться
минимальными изменениями.  Это денег может стоить, а вот
"соберите из cvs" может стоить грубостей...

> > Я фрю за серверную операционку уже по двум клиническим
> > признакам не считаю, и это сугубо технически, а не
> > эмоционально (впрочем, того уже хватало, чтобы не связываться
> > с этим проектом).
> И какие у неё признаки не сервантной ОС?

Отсутствие бранчей большинства серверных пакетов и то, что по
части поддержки оно *сейчас* напоминает линукс даже не
десятилетней давности -- "с пашпилем на танки":

http://tinyurl.com/j7nhf

(что-то ещё было фундаментального, сейчас не вспомню)

> А я вот генту ставлю сейчас.

Ну ставь, мне-то что.

> Устал я от разломаного в репозитории kde...

Хихикс :]

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

Re: [devel] [sisyphus -> devel] Стабильный Сизиф

[Fr. Br. George]

On Thu, Jun 22, 2006 at 04:08:36PM +0300, Michael Shigorin wrote:
> Порты -- это поделка, которая фундаментально не годится для ОС,
> за поддержку которуй можно отвечать.  Они не бранчатся.  Вообще.
Фи. Если бы не были знакомы лично, заподозрил бы агрессивную
неграмотность.

> Я фрю за серверную операционку уже по двум клиническим признакам
> не считаю, и это сугубо технически, а не эмоционально (впрочем,
> того уже хватало, чтобы не связываться с этим проектом).
Миша, а я 12 лет её эксплуатирую и как production сервер-ы, и как
desktop. Поторопился я с предыдущим утверждением. Всё-таки это с твоей
стороны именно агрессивная неграмотность. Ты, видимо, просто не в теме, и
пыл твой представляется чисто религиозным, что печально.

>  Гентушники вон эту проблему тоже
> то ли не видели, то ли решили, что бранчи портов им поддерживать
> как сообществу дороговато и ненужновато.  Потому они тоже -- не
> серверная ОС, за поддержку которой я как контора могу взяться.
Они "тоже" не серверная ОС по той же причине, что и Сизиф -- не
серверная ОС. Gentoo -- это такой живущий репозиторий. Без зачёса на
Gentoo-based профильные дистрибутивы. Ну так никто и не хочет объять
необъятное.

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

-- 
			George V Kouryachy (aka Fr. Br. George)
			mailto:george at altlinux_ru

[devel] [JT] Re: [sisyphus -> devel] Стабильный Сизиф

[Michael Shigorin]

On Thu, Jun 22, 2006 at 06:39:44PM +0400, Fr. Br. George wrote:
> > Порты -- это поделка, которая фундаментально не годится для ОС,
> > за поддержку которуй можно отвечать.  Они не бранчатся.  Вообще.
> Фи. Если бы не были знакомы лично, заподозрил бы агрессивную
> неграмотность.

Это мне рассказал один из пострадавших коммиттеров, который потом
потратил время на попытки найти способ исправить этот design bug,
поскольку хостинг был под угрозой и попадать на такое ещё уже не
хотелось.  В обратном как-то кто-то из юзеров пытался убедить,
даже не помню кто.

Короче, вот уж куда смысла смотреть по части _инфраструктуры_
именно что не вижу.

[почтой ответил на остальное]

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

Re: [devel] [JT] Re: [sisyphus -> devel] Стабильный Сизиф

[Fr. Br. George]

On Thu, Jun 22, 2006 at 06:07:49PM +0300, Michael Shigorin wrote:
> On Thu, Jun 22, 2006 at 06:39:44PM +0400, Fr. Br. George wrote:
> > > Порты -- это поделка, которая фундаментально не годится для ОС,
> > > за поддержку которуй можно отвечать.  Они не бранчатся.  Вообще.
> > Фи. Если бы не были знакомы лично, заподозрил бы агрессивную
> > неграмотность.
> Это мне рассказал один из пострадавших
Вот именно. А один из непострадавших рассказывал мне про дистанционное
обновление FreeBSD4 -> FreeBSD5 на сервисе 24/7 с временем простоя =
временеи загрузки. Не разговор.

-- 
			George V Kouryachy (aka Fr. Br. George)
			mailto:george at altlinux_ru

Re: [devel] [OT] (не)серверные ОС

[Michael Shigorin]

On Wed, Jun 28, 2006 at 06:37:47PM +0400, Fr. Br. George wrote:
> > > > Порты -- это поделка, которая фундаментально не годится
> > > > для ОС, за поддержку которуй можно отвечать.  Они не
> > > > бранчатся.  Вообще.
> > > Фи. Если бы не были знакомы лично, заподозрил бы
> > > агрессивную неграмотность.
> > Это мне рассказал один из пострадавших
> Вот именно. А один из непострадавших рассказывал мне про
> дистанционное обновление FreeBSD4 -> FreeBSD5 на сервисе 24/7 с
> временем простоя = временеи загрузки. Не разговор.

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

Без рассказов -- переводил сервер, у которого практически каждое
моргание eth0 означало денюжку ($1--2), с RH7.3 на ALM2.2.  
Даунтайм был тоже порядка минут.  Это тоже ничего не значит.

Рекомендовать использовать Windows 95 на гейтвее я точно так же
не могу.  Хотя и таких гениев только сам повидал немало.


Гош, давай на фесте.  Мож Антон вон молодость повспоминает,
да ещё кто. ;)

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

Re: [devel] [OT] ( не ) серверные ОС

[Epiphanov Sergei]

В сообщении от Wednesday 28 June 2006 23:20 Michael Shigorin написал(a):
> Рекомендовать использовать Windows 95 на гейтвее я точно так жене могу.
>  Хотя и таких гениев только сам повидал немало.

У нас на работе такое было. Хорошо, что это не внешний, а внутрирабочий 
(отделял нашу собственную сеть от общеинститутской).

-- 
С уважением, Епифанов Сергей

Re: [devel] Стабильный Сизиф

[Michael Shigorin]

On Thu, Jun 15, 2006 at 01:48:57PM +0400, Fr. Br. George wrote:
> 5. Ещё раз: sync, freeze, testing, release -- это стадии Сизифа, а не
>    какого-либо дистрибутива. Это для сообщества, для нас самих.

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

> 6. Дистрибутив -- это _отличия_ от Сизифа, которые его авторы
> доводят параллельно. Накатим отличия на стабильный Сизиф --
> получим стабильный дистрибутив. Хоть сейчас в release.

Если снять крашеную оптику, то всё равно остаётся фиксация 
и более жёсткая прогонка результата (очень понравилось
бета-тестирование ALM2.4, ну и результат вполне).

> 		Примерный план-график рабочего цикла.
> 
> Стоит заметить, что действительные даты (особенно freeze и release) могут
> слегка (на неделю-две) сдвигаться вперёд, так, чтобы было удобнее всем, но
> ориентироваться всё же удобнее по месяцам, без неопределённостей.
> 
> Июнь-Август		Эксперименты, сессия и отпуска.
> Сентябрь		Sync
> 		Кидается клич: "Народ! Через месяц freeze! У вас всё готово?"
> 		Со словами "Какой там готово!" отдохнувший с лета народ
> 		принимается приводить в порядок дела. Возможно, сентября будет
> 		мало, заедем на октябрь.

Это, кстати, пора конференций, выставок и вообще повышенния
деловой активности.  На многих сказывается по части свободного
времени.

> Октябрь			Freeze
> 		Когда всё более-менее на уровне, объявляется заморозка.
> 		Все на блох! Обновления _версий_ пакетов допускаются только в
> 		крайнем случае (дыра в безопасности) или для специального
> 		класса пакетов (документация). Длится до тех пор, пока все
> 		release critical блохи не будут удушены.

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

> Ноябрь			Testing
> 		Объявляется первый release candidate. Кидается клич:
> 		"Сообщество! Ты боялось нестабильного Сизифа? Этот --
> 		стабильный! Кто найдёт ошибку сегодня -- исправим завтра, кто
> 		поленится -- исправим только через полгода!". RC продолжают
> 		выпускаться до тех пор, пока не перестанут приходить release
> 		critical блохи, или пока не надоест.

Тоже интересное "или".  Или пока не настанет декабрь?..
(это если верить в то, что это всё вообще планируемо в
абсолютных, а не относительных, интервалах и тем более
точках времени)

> Декабрь			Release
> 		(не позже середины декабря). Выпуск. Стабильный Сизиф
> 		оформляется в виде ветки. Если на ней выпущены какие-то
> 		дистрибутивы, ветка даже оказывается отчасти поддерживаемой.
> 		Сам Сизиф семимильными шагами движется в гору, навстречу
> 		новым блохам, зимней сессии и рождественским каникулам.
> Январь			Эксперименты и сессия
> Февраль			Sync
> Март			Freeze
> Апрель			Testing
> Май			Release

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

Если не торопиться впереди планеты всей, то на основе
декабрьского чего-то в принципе можно как раз к весне 
сделать rock solid distro.  При условии, конечно, что
зимой хватит здоровья, интереса и напильника вывалить
заморозку, а к весне оно будет коммерчески надо.

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