Re: [devel] Build from gear

["Денис Смирнов" <mithraen@altlinux.ru>]

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

On Sun, Oct 15, 2006 at 04:28:37PM +0300, Michael Shigorin wrote:

>> Кто будет этим ключевым звеном, уход которого в отпуск
>> блокирует всю работу? vsu@ прямой доступ нужен, насколько я
>> понимаю. Но также мне кажется сомнительным что Сергей
>> обрадуется _необходимости_ делать git pull/push, на каждое
>> _твое_ изменение.
 MS> Слушай, а ты уверен, что грокнул git и не считаешь его таким
 MS> себе cvs?  Он же весь из себя про деревья и бранчи, а не про 
 MS> центральный репо и доступ к нему.

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

Плюс флейм шел о том чтобы переносить kernel cvs в git без изменений (то
бишь использовать git как cvs), что мне категорически не нравится.

А бранчами полноценно я пользоваться пока не научился, да. То что я
научился будет заметно по исчезновению патчей из моих пакетов :)

MS> Бишь есть нечто вроде vALTnilla, и если кому надо -- клонят
MS> и ведут свои деревья, при необходимости дёргая народ насчёт
MS> слить наработки.  В этой как раз точке и место для review,
MS> причём необязательно именно одним и тем же человеком.

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

>> Напоминаю что скоро сборка пакета в Сизиф кроме как через git
>> будет невозможна.
MS> Это ещё что за новости?

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

>> Да, я понимаю что любой имеющий права на сборку модулей может
>> подсунуть руткит. Но я сомневаюсь что кто-то проводит вычитку
>> кода всех kernel-source-*.
MS> От любого желающего просто не надо делать pull.

Тебе напомнить про apanel, который ты не мог себе собрать из-за того что
не имел доступ к kernel cvs? И про то как я про него забыл, из-за чего ты
ой как долго его дожидался? AFAIR я его все-таки собрал, но нынешний его
статус не знаю.

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

А я посмотрел. Ему пришлось слишком много несовместимых велосипедов
изобретать. Будь разработка более открытой этих велосипедов не было. Вот
ему, например, нужны ядра с другим патчем на mppe/mppc, другой pppd,
cramfs в ядре и т.д. Он был со своими предолжениями просто молча
проигнорирован, и потому пошел делать свои велосипеды.

> >>> Вон у меня сейчас сборка астериска (из-за его развесистости)
> >>> постепенно начинает напоминать сборку ядра (уже два flavour,
> KAL>> ну вот вам и нужно придумывать решение, а тут зачем изгаляться?
>> Это я к слову. Себе я велосипед из стайки скриптов изобрел, он
>> работает, это все страшно до жути но мне пофиг. И будет пофиг
>> С firefox проблемы есть уже сейчас.
>> С php, который ты ниже упомянул, вообще не проблемы а вилы.
MS> А ещё есть seamonkey.
MS> Только опять же -- даже не почитав скрипты kernel cvs и не
MS> соображая, чем отличается тот же git{,.alt} по части возможности
MS> навешивания хуков, весьма смутно представляю себе, как и что там
MS> можно пытаться обобщить.  Хотя есть подозрение, что с git.alt
MS> подготовка к пересборке будет сводиться к выделению множества
MS> зависимых по сборке и автопростановки им Правильного Тега (TM).

Ну например :)

Я себе уже четко представляю как можно написать робота-пересборщика для
NMU в стиле QA-robot, которым сможет воспользоваться любой человек. Как
только заработает сборка через git (то бишь появятся первые записи в
кэше), я таки его напишу (если Дима не напишет раньше меня).

В общем-то конкретно эту проблему такой подход решит -- можно после сборки
основного пакета этим роботом легко и непринужденно пнуть сборку остальных
пакетов.

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

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

Качество сборки безусловно вырастет, а вот выдержит ли такой кошмар
incoming?

Я вон и так DoS'ил incoming своими ежедневными снапшотами астериска в
период активного тестирования. Но у меня под это была целая хитрющая туча
скриптов. Поэтому психов вроде меня было мало. Теперь же для этого ужаса
достаточно скриптов из нескольких строк (обновить из svn, обновить
changelog, gear-release, git push).

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

http://freesource.info
----------------------------------------------------------------------------
ПЕРВЫЙ ЗАКОН ПРОТИВОДЕЙСТВИЯ ФУДДА
 Толкните что-нибудь тяжелое, и оно опрокинется.


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