[devel] задания и схемы совместной работы

[Alexey Tourbin]

On Thu, Feb 26, 2009 at 03:50:45PM +0200, Igor Vlasenko wrote:
> On Thu, Feb 26, 2009 at 04:43:03PM +0300, Alexey Tourbin wrote:
> > Дьявол в деталях.  Мне кажется, что нельзя двигаться вперёд, оставляя
> > после себя шлейф разломанных пакетов.  На самом деле в новейшей истории
> > ни разу не удалось естественным образом достичь ситуации, когда число
> > разломанных пакетов было бы на допустимом минимальном уровне (грубо
> > говоря, не больше, чем несколько штук).  Всё время было много анметов
> > и всё время пакеты сотнями не собирались.  И весь этот фриз когда осенью
> > или весной начинают закручивать гайки это какое-то робкое гоняние с
> > палкой за людьми.  И более приемлемое состояния в конечном счете
> > удавалось добиться лишь за счёт удаления пакетов.
> 
> Об этом и речь.
> Как это реально будет выглядеть?
> Будет ли это похоже на pocket, о котором говорил Денис?

Я не знаю, что такое pocket, это не было строго описано.
Изначальные идеи были следующие.

1) Есть задания.  Задание содержит упорядоченный набор пакетов
для сборки.  Пересечений между пакетами в одном задании быть не
должно.  Задание применяется транзакционно, если оно не ухудшает
характеристик репозитария.

2) Совместная работа над заданиями.  Требование, чтобы задание не
ухудшало характеристик репозитария, это требование иногда означает,
что в задание вовлечены несколько человек (если пакеты одного человека
влияют на пакеты другого человека).

Есть следующие схемы совместной работы.

2.1) Человек A чинит чужие пакеты человека B и добавляет их в свое
задание (со своим тагом).  Это схема с подтверждением NMU.

2.2) Человек A просит человека B добавить исправленные пакеты
в задание человека A (таг должен поставить человек B).  Это схема
shared task.

2.3) Человек A просит человека B подписать таг у исправленного пакета,
но при этом человек A сам добавляет в своё задание исправленный таг,
подписанный человеком B.  После консультации с ldv мы от этой схемы
решили отказаться, потому что она нарушает принцип "отправлять на сборку
можно только свои собственные таги".

В общем, есть как бы pockets, но с достаточно жесткими условиями
по части кто за что отвечает.

Какие ещё схемы можно придумать, чтобы людям было проще договориться?
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Тип     : application/pgp-signature
Размер  : 197 байтов
Описание: =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Url     : <http://lists.altlinux.org/pipermail/devel/attachments/20090226/83b867d5/attachment-0001.bin>