On Sun, Oct 15, 2006 at 04:04:31PM +0400, Konstantin A. Lepikhov wrote: >> Кто будет этим ключевым звеном, уход которого в отпуск блокирует всю >> работу? vsu@ прямой доступ нужен, насколько я понимаю. Но также мне >> кажется сомнительным что Сергей обрадуется _необходимости_ делать git >> pull/push, на каждое _твое_ изменение. >> Напоминаю что скоро сборка пакета в Сизиф кроме как через git будет невозможна. >> Как минимум ты и vsu@ получается должны иметь доступ на запись. KAL> это организационный вопрос, а не технический. Из этого организационного вопроса следуют технические следствия, на разрешения которых, если прогноз ldv@ сбудется, у нас чуть больше 2-х недель. >> feat/fix/... это совершенно самостоятельные пакеты. Которые, насколько я >> понимаю, уходят в Сизиф в неизменном виде. Чем и отличаются от модулей. KAL> возможно, но они бесполезны без ядер. Я понимаю. Но это не повод городить лишнюю сущность. Напоминаю -- kernel cvs через две недели мертв, создается нечто новое. Будет ли это kernel cvs поверх git, или мы будем на максимум использовать особенности вновь создаваемой системы? >> Кто контролировать будет? Ты готов лично проверять корректность каждой >> моей сборки zaptel (особенно с учетом того что из меня ядерщик такой же >> как балерина -- то бишь на редкость хреновый)? Видимость контроля хуже >> отсутствия такового. KAL> мне ее приходится проверять, как и сборки других модулей. Но как ты KAL> правильно заметил, это поверхностная оценка. И, если я правильно понимаю, при желании такую поверхностную оценку правильно написаный скрипт будет производить по крайней мере быстрее тебя. Так как я сомневаюсь что ты при этой проверке смотришь исходники, написать такой робот вполне реально. Мало того, если ты сможешь это формализовать, я даже возьмусь за это. >> Насколько я помню мы рассчитываем на сознательность мантейнера. Если он не >> сознательный -- он идет лесом (в смысле ему перекрывают доступ к заливанию >> ядреных пакетов). Если совсем несознательный... но на моей памяти >> прецедентов с совсем несознательными не было. >> Да, я понимаю что любой имеющий права на сборку модулей может подсунуть >> руткит. Но я сомневаюсь что кто-то проводит вычитку кода всех >> kernel-source-*. KAL> vsu@ читает :) Увы, думаю далеко не все :) >> Вася Пупкин не имеет доступа в kernel cvs, но ему нужно собрать для себя >> ядрышко с модулями. Ядрышко его сборки нужно ещё и Василисе Пупкиной, а >> также нескольким их коллегам. >> Что делать бум? Пущай варяться в своих песочницах, али как? KAL> а чем васю не устраивает свой cvs репозиторий? Васю не устраивает это исключительно тем, что пользователи этого ядра почему-то могут оказаться вполне себе другими пользователями Сизифа. Скажем по другому -- сильно мой via26 кому-то помешал? Был он мне нужен -- жил. Потом тихонько сдох, потому что никому больше нужен не оказался. Оказался бы -- жил бы дальше. Чем это плохо? Да, я понимаю что в дистрибутив такие левые ядра класть нельзя. Но и ll26 твой загнулся, во многом из-за того что многие кто могли бы по чуть-чуть помочь просто не имели доступа к kernel cvs. >> У нас есть сейчас три "типа официальных" flavour -- std, wks, ovz. Но я не >> понимаю почему следует _запрещать_ альтернативные сборки, если они кому-то >> нужны. KAL> а их никто не запрещает - если ты посмотришь повнимательнее в kernel cvs, там KAL> много "заброшенных" сборок вроде rt26, которая вообще является чьим-то KAL> выкидышем, т.к. у нее -headers непригодны для сборки -modules. Т.е. KAL> препятствий нет, есть лень и отсутствие времени/людей. Если мы это разрешаем, то на того человека который будет работать прокси падает большая нагрузка. Проксей людей быть не должно. >> radlinux тому хороший пример -- автор варится в собственном соку. KAL> и автора это устраивает. Автора -- да. Его пользователей -- нет. Точно тебе говорю. >> Плюс совсем нелогично что в _одном_ репозитории у нас лежит все >> околоядерное. Это нелогично. KAL> можно сделать _один_ околоядерный репозиторий, как в ovz. Смысл? >> Плюс нет разграничения зон ответственности. Вот я сейчас каааак возьму, и >> кааааак сделаю коммит в wks26-*. Не, ну понятно что ты увидишь в почте cvs >> log, дашь мне в лоб больно и откатишь изменение. А ежели не заметишь? ;) KAL> замечу ;) :) >> Ну и самое главное что ты полностью проигнорировал. У нас нет SRPM. Вернее >> через месяц не будет. Вообще не будет. И сделаный из kernel cvs/git/что >> угодно ещё srpm ты сможешь только собрать локально и любоваться. >> Поэтому подразумевается что из spec'а rpm генерируется исключительно на >> git.altlinux.ru (кроме периода локального тестирования). И сделать всю >> систему стоило бы так, чтобы это было удобно. KAL> скрипты в kernel cvs не сильно завязаны на srpms. Точнее, вообще на них не KAL> завязаны. Они завязаны на _сборочную среду_. Ты это скажи тем скриптам которые при сборке модулей на версии ядер смотрят... Они, собаки такие, не верят. И мне их патчить пришлось чтобы у меня они то что нужно подхватывали. Это так, к примеру. >> Это я к слову. Себе я велосипед из стайки скриптов изобрел, он работает, >> это все страшно до жути но мне пофиг. И будет пофиг пока >> asterisk*/seirospbx* означает что мантейнер я. Как только появится хотя бы >> один модуль, который кому-то нужен, а мне нафиг не нужен, собирать его >> геморройно, и я пошлю его мантейнера разбираться самого -- у него будут >> проблемы. KAL> потому что либо нет документации по сборке, либо система сборки KAL> непрозрачна. Нет. Это потому что как только я обновляю minor версию он должен обновлять свой пакет. >> С firefox проблемы есть уже сейчас. KAL> они временные до выхода fx-3.0. До этого ещё дожить надо. >> С php, который ты ниже упомянул, вообще не проблемы а вилы. Перманентно >> существенная часть модулей не собрана, и обновить php попросту невозможно. >> О нем и не говорят даже, потому что без мата о нем говорить трудно, а мы >> все-таки в приличном обществе. Однако факт есть факт -- он нужен. И мне, >> который его ненавидит всей душлой -- тоже. KAL> какие нужные модули не собраны в данный момент? Вот сию секунду собрано все мне нужное. Однако за последние пол года более половины времени php был неюзабелен в том числе по причине не собранности модулей. И у меня есть подозрение что как только будет обновлен php, цирк продолжится. >> И, кстати, php уже напрашивается как минимум на 2 flavour -- обычный и >> hardened (в связи с тем что zend optimizer с hardened, AFAIR, не >> совместим, а вот люди его хотят из-за кривых поделий с закрытыми >> исходниками). KAL> там все хуже: zend API сменился при переходе с 4.3.10 на 4.4.0, поэтому KAL> старые блобы и так уже давно в пролете. Это отдельная тема. Факт необходимости двух сборок php со всем окружением никак не отменяющая. Собственно о чем мы флеймим сейчас? Меня интересует поиск более универсального решения, которое облегчит жизнь как ядерщикам, так и всем остальным имеющим аналогичные проблемы. Ясно что для ядра нужна более сложная система. Также мне кажется что можно на максимум использовать преимущества git. Ты мне предлагаешь оставить все как есть и не париться, добавив ещё к этому невозможность отправить любой ядреный пакет в Сизиф без подтверждения человека-прокси, который будет единственным способным отправить что-либо ядреное в сизиф, так? -- С уважением, Денис http://freesource.info ---------------------------------------------------------------------------- AMike: мы боты! мы боты! мы боты не купили!