On Tue, Jun 17, 2008 at 01:53:10AM +0400, Dmitry V. Levin wrote:
> > Нарушение ACL соответствует ситуации NMU.  Мы можем дать разовое NMU
> > без изменения ACL, но для этого нужно точно знать изменения в пакете
> > (то есть пакет должен собраться).  Тогда либо maintainer пакета,
> > либо арбитр (если maintainer недоступен) может сказать "SKIP ACL OK".
> 
> Мне нравится эта идея.  Каким должен быть механизм подтверждений, чтобы
> быть удобным и мантейнеру, и арбитру?

Это зависит от модели данных в сборочнице.  Она может быть такой:

struct task {
	int id; // ever-increasing номера заданий
	struct packages[]; // пакеты, собираемые в задании
}

struct package {
	struct task *task; // имеется в виду, что пакеты привязаны к
			   // заданиями и рассматриваются в пределах
			   // задания
	char *name;	// имя пакета, на которое можно ссылаться в
			// пределах задания
	
	char *git_repo; // информация про gear-репозитарий
	char *tag;
	sha1 *comitish;

	enum {
		V_UNMETS;
		V_ACL;
	} violations[];	// нарушения пакета
}

Когда мы делаем 'push-build', мы отправляем один или несколько пакетов
на сборку, и создаётся task.  Если все пакеты собрались, и в каждом
пакете пустой список violations, то пакеты автоматически проходят в
Сизиф.  Если хотя бы один пакет не собрался (по грубой причине), то
task автоматически отменяется.  В противном случае пакеты собрались,
но в некоторых из них имеются violations.  Тогда об этом отправляется
письмо по почте (тем, кто может воздействовать на violations).

Механизм подтверждения или отвержения нарушений можно сделать через
git.alt.

ssh git.alt violation <task-id> <package-name> <violation> "permit"|"deny"

Если все нарушения удалось снять, то пакеты из task проходят в сизиф.
В противном случае через некоторое время task автоматически отменятся.

В task надо уметь добавлять новые пакеты (если он не проходит
автоматически).  Это соответствует ситуации, когда пакет что-то ломает
(напр. V_UNMETS).  Тогда в этот task добавляются исправленные пакеты,
и часть violations автоматически снимается (но могут также добавляться
новые violations, напр. V_ACL).

Такая модель позволят наладить транзакционную смену soname'ов (а также
частично её нарушать).