[sisyphus] Предложения по формированию бранчей

Alexey Novikov shader на yandex.ru
Пт Май 22 15:27:50 MSD 2009


On Fri, May 22, 2009 at 01:47:51PM +0400, Grigory Batalov wrote:
> On Fri, 22 May 2009 09:15:58 +0400, Alexey Novikov wrote:
> 
> > Почему бы не воспользоваться модифицированной
> > дебиановской схемой:
> > 1. unstable (Sisyphus) - как есть на данный момент.
> > 2. testing, в который попадают пакеты из Сизифа после обкатки и
> > на котором смогут жить майнтейнеры и тестеры. Требуется
> > гарантировать обновляемость до Сизифа. Требуются достаточно свежие
> > версии apt+rpm, чтобы можно было запускать hasher с Сизифом.
> 
> Насколько я понял обсуждение в devel@, вопрос в том, как повлияют
> обновлённые пакеты на бранч testing. Допустим, в бранч приходит
> новый gcc, пропущенный туда по всем формальным признакам. Может
> так случиться, что уже лежащие в бранче пакеты перестанут
> пересобираться, что неоднократно встречалось в Сизифе.

Тут скорее вопрос, по чьей инициативе пакет из unstable(sisyphus)
будет попадать в testing. Если по инициативе майнтейнера, то
спрашивается чем это лучше Сизифа? Скорее это должен быть
ответственный(ые) за testing, при чем имеющий достаточную
компетенцию. Перенос же собственно должен быть в
полуавтоматическом режиме, ИМХО.

Т.е., например, майнтейнер пакета в Сизифе уведомляет менеджера
testing-branch о том, что пакет в Сизифе достаточно работоспособен,
т.е. как минимум не хуже, чем в testing. Ответственный проверяет
зависимости,устанавливаемость,собираемость,может быть даже
работоспособность. Если после этого принимается решение о
переносе, то определяется набор пакетов необходимых для переноса,
т.к. не всегда можно перенести пакет без обновления зависимостей.
После этого "нажимает педаль", по которой клонируются gear-репо,
автоматом корректируется release и создается задание на сборку
всего набора пакетов в окружении testing.

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

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

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

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

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

> P.S. обсуждение в devel@ здесь:
> http://lists.altlinux.org/pipermail/devel/2009-May/170059.html

Как же, читаю через gmane, только писать туда не могу. :)

-- 
WBR, Alexey Novikov
XMPP: alex-novikov at jabber.ru, shader at ya.ru


Подробная информация о списке рассылки Sisyphus