On Thu, Oct 11, 2012 at 06:00:49AM +0300, Igor Vlasenko wrote:
> On Thu, Oct 11, 2012 at 06:40:16AM +0400, Dmitry V. Levin wrote:
> > > опция --email, может некорркетно ее так называть, 
> > > может быть, --task-leader правильнее, это человек,
> > > который заказал какому-то сервису сборку пакета.
> > > 
> > > Этой опцией убивается 2 зайца:
> > > 1) письмо не отсылается на cronbuild@. [ а то робот меня спамит :( ]
> > > 2) письмо гарантированно отсылается человеку, 
> > > заказавшему сборку, даже если его явно нет в acl.
> > > (он неявно в <лидер, ушел из team> @everybody).
> > 
> > Это все выглядит как уход от проблемы устаревания ACL.
> > Поскольку ACL - это первичный источник информации для всех типов рассылок,
> > связанных с пакетами, давайте лучше подумаем, как решить эту проблему.
> 
> Здесь принципиально, что заказчик не обязан _явно_ присутствовать в acl.
> Разных сервисов автоматизации уже сейчас много. И будет больше.
> 
> Например, заказчик может приказать роботу NMU: "добавь в трвнзакцию
> как NMU пересборку всех пакетов, зависящих от моей библиотеки".

Если робот настолько не при чем, что даже отчет о сборке нужно направлять
заказчику, то и владельцем задания со всеми подзаданиями следует тогда
считать заказчика, и все остальные проверки применять к заказчику, а не к
роботу.

Осталось только придумать способ надежной проверки, было ли данное задание
действительно делегировано этому роботу данным заказчиком, и все, никаких
костылей типа --email будет не нужно.

> Сейчас в gb-task-send-email используется `cat task/owner`.
> Хочется
> с опцией --email/--task-leader/--recepient/как угодно
> __подменять__ task/owner на указанную персону.

Для того, чтобы полностью исключить робота, недостаточно подменить
TASK_ID/task/owner, еще нужно подменить все TASK_ID/gears/*/userid.

> Подмена еще хороша тем, что письмо тогда на `cat task/owner` 
> (т.е. роботу) высылаться не будет.

Это все костыли, хотелось бы решить саму задачу делегирования,
а не бороться с последствиями объездов.


-- 
ldv