[sisyphus] Re: [POLICY] Sisyphus

[Michael Shigorin]

On Tue, Jan 27, 2004 at 03:23:40PM +0300, info wrote:
> Такая схема - это как карта местности. Без нее представление о
> структуре сизифа достаточно туманное, на уровне либо подкорки и
> интуиции (у тех, кто глубоко в теме), либо ёжика в тумане - у
> всех остальных.

:-]

(здесь вспомнилась еще одна мысль -- про кластеры пакетов,
обладающих сходной функциональностью -- нечто вроде debian tasks
и прочих recommends/suggests, только на это можно было навесить
категоризированные веса -- ресурсоемкость, уровень пользователя,
...)

Стоп.

Карта местности нужна для хождения по ней, а не подъезда к.

Я в данном случае ("v0.1") воспринимаю Sisyphus/ как нечто в
достаточной степени целостное и воспринимаемое как один объект,
чтобы сфокусироваться на "таможенной полосе" -- этом самом
гипотетическом dot-incoming.

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

Понятно, что при более глубокой отработке "таможенных процедур"
(факторов, влияющих на переход пакета из .incoming в какой
.contrib или .base) это приближение не работает и надо смотреть,
а на каком основании пакету A надо попасть в .base завтра, а вот
libB -- полежать до конца своей недели.

---

Попробую привести пример.

Сейчас:

* некий mike залил apache;
* на следующий день оказалось, что в classic изменился apt и
  теперь механизм учета неверсионированных зависимостей,
  неверсионированно же удовлетворяемых в рамках репозитория
  виртуальными пакетами, также изменился (вообще говоря, это
  платформообразующее изменение -- то, что стоит упоминания
  отдельной строкой в "По Граблям и Затем Обратно");
* некий mike откатил старый хак и опять залил apache;
* на следующий день выяснилось, что представления о
  версионировании у rpm и perl не совпадают, причем каждый
  по-своему прав; в итоге проблема углубилась, а dist-upgrade
  пользователям mod_perl остается сломанным минимум третьи, а то
  и четвертые сутки.


При добавлении .incoming:

* некий mike залил apache;
* на следующий день оказалось, что в рамках classic+incoming
  apache-mod_perl сломан вышеуказанным образом;
* [...выясняем, в чем дело...];
* залита Правильная Сборка;
* пролежав там свои N суток (неделю) и не обновившись, эта сборка
  перемещается скриптом в свой .contrib или куда положено; при
  этом пользователи нормального .classic этой бури в стакане не
  ощутили.

Здесь около слов "оказалось" и "выясняем" можно сразу дописывать
"поднимаем исключение <<ИЗМЕНА!!>>".


В идеале (tm) -- включает предыдущий пункт :) --

* майнтейнер apt объявил об изменении, которое задевает пакеты,
  подпадающее под такие-то условия ("Provides: A" или "Requires: A"
  без указания версии); как вариант -- это было обнаружено уже
  postfactum _в_рамках_.incoming;
* объявляется "точка перегиба", которая характеризуется:
  - описанием происхождения и необходимости (последнее -- при
    известности заранее) -- "начиная с apt-0.5.15cnc5-alt3, ...";
  - тестом для проверки ее влияния на пакет ("$ .... .spec");
  - типичным рецептом для типично ожидаемых проблем ("добавить
    версию туда и сюда");
* обнаружив, что эта точка задевает пакет apache, mike по крайней
  мере не будет трепыхаться с лишней сборкой/залитием до тех пор,
  пока не синхронизируется с Sisyphus/incoming+classic _после_
  этой точки, а по обновлении будет иметь представление о
  проблеме и способе решения;
* после того, как это решение зафиксировано в пакете -- оно
  попадает в .incoming, где лежит (исходя из того, что apache --
  пакет важный, судя тому, что живет в .master, им пользуется 14%
  пользователей Sisyphus, от него зависят 16 пакетов, etc, etc)
  -- M1 дней, пусть трое суток.
* после чего пакет apache-<версия>.alt<сборка>.src.rpm и его
  бинарное потомство переселяются в компоненту master при
  отсутствии новых точек перегиба, влияющих на них.

---

Здесь вырисовывается еще пара тонких моментов, о которых
вроде уже и говорилось:

* конкретно apache-mod_perl наступил сразу на несколько слегка
  разнесенных во времени ТП за последний месяц -- см. "сейчас".
  
  При этом выдвигалось предложение, что такие платформообразующие
  моменты может быть осмысленно группировать или по крайней мере
  стараться локализовать во времени.
  
  - pro: если несколько изменений затрагивают определенную группу
    пакетов, количество необходимых пересборок уменьшится;
  
  - contra: не получается атомарности (в т.ч. отката), надо
    гораздо координированнее производить обновление пакетов,
    приводящих к появлению новой "точки".

  Кстати, "большой" ТП в "стабильном стане" является не что иное,
  как выпуск дистрибутива.

* "src.rpm и потомство": несмотря на то, что проблема может
  касаться одного или нескольких производных от исходного
  бинарных пакетов, перемещаются или остаются они "одной семьей".

* "при отсутствии новых точек": на этом месте упираемся в
  автоматические тесты.

---

[а здесь я вспомнил, что у мамы юбилей -- и пошел домой]
[эх -- опять из контекста дважды за время написания вырвали :( ]

> Вообще-то, это называется не research, а - в программно-целевом
> планировании - "постановка задачи". Этап совершенно необходимый
> в любом проекте, но, увы, часто забываемый
> программистами-практиками, которые - не хочу никого обидеть,
> но, увы, такое бывает - порой действуют безо всяких там
> постановок задачи, а по принципу "О! А не сделать ли нам вот
> так???":-))

А я вообще не программист. :-]

-- 
 ---- WBR, Michael Shigorin <mike на altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Тип     : application/pgp-signature
Размер  : 189 байтов
Описание: =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Url     : <http://lists.altlinux.org/pipermail/sisyphus/attachments/20040127/f36b03e5/attachment-0009.bin>