[devel] sisyphus-unmets: "смягчить" работу над shared tasks (was: collaboration patterns)

[Michael Shigorin <mike@osdn.org.ua>]

On Fri, Apr 24, 2009 at 09:43:58PM +0400, Alexey Tourbin wrote:
> > > Yes, you have to add that another package to your fpc task.
> > > If you have ACL permissions to build that another package,
> > > this is remarkably simple. :)  And if you don't, this is
> > > still possible.
> > Да, наверно сейчас, когда такой пакет всего один, это будет
> > просто. А если завтра их будет больше одного? А каждый
> > мантейнер личность и к каждому найти подход...
> Okay, let's discuss again what I call "collaboration patterns".
[...]
> Are there any better possibilities?  I believe we need to make
> rebuilding packages for new dependencies easily possible.  And
> otherwise we face major problems.

Yup.

Вот что ещё подумалось: а можно ли обломавшиеся по причине
создания новых анметов задания сваливать в некую общую кучу
sisyphus-unmets или там sisyphus-next, в рамках которой не
требовалось бы отдельных действий по координации для исправления?

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

Возможность реализации IMHO зависит от того, насколько получается
предположить возможность исправления целостности получаемого
репозитория новоприбывшими пакетами -- примерно так:

- залил новые A и B;
- A собрался/проверился нормально и пошёл в Sisyphus;
- B сломал по установочным зависимостям пакеты C и D
  и потому был отправлен в sisyphus-unmets;
- майнтейнер C забросил новую сборку в git.alt или incoming;
- её пересборка в окружении sisyphus-unmets показала
  уменьшение количества анметов при транзакции
  => пакет определён в sisyphus-unmets;
- майнтейнер D тоже забросил сборку, но она не уменьшила
  количества анметов в рамках sisyphus-unmets, при этом
  пересборка на sisyphus показала неувеличение анметов
  => пакет определён в sisyphus;
- когда все порождённые B анметы "погашены" определёнными
  в sisyphus-unmets пакетами, B и пакеты, скомпенсировавшие
  именно им созданные анметами, отправляются на пересборку
  в Sisyphus (и при прохождении перекладываются туда).

Налицо существенные сомнения в "сходимости ряда" анметов таким
образом в разумное время, чтобы полученную "кучу" можно было
целиком перемещать в Sisyphus: скорее всего, куча будет
распухать со временем и блокировать возможность перекладывания
в сизиф статистически постоянным наличием/созданием анметов.
_Возможно_, от этого бы помогло установление некоего таймаута
(скажем, в неделю) и напускание stmpclean.

А ещё судьба пакета C может быть неожиданной для майнтейнера,
который и не собирался как-то особенно исправлять судьбу пакета B
(даже быть не в курсе), а просто намеревался увидеть новую сборку
пакета C в сизифе.

---

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

Получилось же сделать task add srpm, за что отдельное спасибо.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/