Hi Денис!

Sunday 15, at 04:23:07 PM you wrote:

> On Sun, Oct 15, 2006 at 04:04:31PM +0400, Konstantin A. Lepikhov wrote:
> 
> >> Кто будет этим ключевым звеном, уход которого в отпуск блокирует всю
> >> работу? vsu@ прямой доступ нужен, насколько я понимаю. Но также мне
> >> кажется сомнительным что Сергей обрадуется _необходимости_ делать git
> >> pull/push, на каждое _твое_ изменение.
> >> Напоминаю что скоро сборка пакета в Сизиф кроме как через git будет невозможна.
> >> Как минимум ты и vsu@ получается должны иметь доступ на запись.
> KAL> это организационный вопрос, а не технический.
> 
> Из этого организационного вопроса следуют технические следствия, на
> разрешения которых, если прогноз ldv@ сбудется, у нас чуть больше 2-х
> недель.
это если сбудется.

..
> Я понимаю.
> 
> Но это не повод городить лишнюю сущность. Напоминаю -- kernel cvs через
> две недели мертв, создается нечто новое. Будет ли это kernel cvs поверх
> git, или мы будем на максимум использовать особенности вновь создаваемой
> системы?
Денис, давай без нагнетания напряженности ;) я не слышал про закрытие i/S
через 2 недели, и думаю, никто не пойдет на такое. Просто i/S станет еще
одной подготовительной стадией к сборке, вот и все.

..
> >> Кто контролировать будет? Ты готов лично проверять корректность каждой
> >> моей сборки zaptel (особенно с учетом того что из меня ядерщик такой же
> >> как балерина -- то бишь на редкость хреновый)? Видимость контроля хуже
> >> отсутствия такового.
> KAL> мне ее приходится проверять, как и сборки других модулей. Но как ты
> KAL> правильно заметил, это поверхностная оценка.
> 
> И, если я правильно понимаю, при желании такую поверхностную оценку
> правильно написаный скрипт будет производить по крайней мере быстрее тебя.
> Так как я сомневаюсь что ты при этой проверке смотришь исходники, написать
> такой робот вполне реально.
> 
> Мало того, если ты сможешь это формализовать, я даже возьмусь за это.
отслеживать изменение структур и макросов в headers? Помойму это задача
все-таки для human-like.

> KAL> а чем васю не устраивает свой cvs репозиторий?
> 
> Васю не устраивает это исключительно тем, что пользователи этого ядра
> почему-то могут оказаться вполне себе другими пользователями Сизифа.
> 
> Скажем по другому -- сильно мой via26 кому-то помешал? Был он мне нужен --
> жил. Потом тихонько сдох, потому что никому больше нужен не оказался.
> Оказался бы -- жил бы дальше. Чем это плохо?
плохо замусориванием cvs, где нельзя каталоги удалить ;)

> 
> Да, я понимаю что в дистрибутив такие левые ядра класть нельзя. Но и ll26
> твой загнулся, во многом из-за того что многие кто могли бы по чуть-чуть
> помочь просто не имели доступа к kernel cvs.
и даже если бы имели, что изменилось? Кстати, он не загнулся, у него
вялотекущая кома :)

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

> >> radlinux тому хороший пример -- автор варится в собственном соку.
> KAL> и автора это устраивает.
> 
> Автора -- да. Его пользователей -- нет. Точно тебе говорю.
тогда это list mismatch. Пинайте автора.

> 
> >> Плюс совсем нелогично что в _одном_ репозитории у нас лежит все
> >> околоядерное. Это нелогично.
> KAL> можно сделать _один_ околоядерный репозиторий, как в ovz.
> 
> Смысл?
дабы при сборке цеплять его и делать возможными ядра, использующие что-то
не сизиф-специфичное.

<skip>
> KAL> скрипты в kernel cvs не сильно завязаны на srpms. Точнее, вообще на них не
> KAL> завязаны. Они завязаны на _сборочную среду_.
> 
> Ты это скажи тем скриптам которые при сборке модулей на версии ядер
> смотрят... Они, собаки такие, не верят. И мне их патчить пришлось чтобы у
> меня они то что нужно подхватывали. Это так, к примеру.
так при чем тут srpms? они завязаны на _сборочную среду_, где используется
rpm. Не будет rpm, придумаем что-нить другое.


<тут надо начинать новый тред>
> KAL> какие нужные модули не собраны в данный момент?
> 
> Вот сию секунду собрано все мне нужное. Однако за последние пол года более
> половины времени php был неюзабелен в том числе по причине не собранности
> модулей. И у меня есть подозрение что как только будет обновлен php, цирк
> продолжится.
не будет. У legion@ теперь есть тестеры и заинтересованность.

-- 
WBR et al.