[devel] I: git.alt package build acl: ideas

[Alexey Tourbin]

On Fri, Jun 13, 2008 at 05:47:29PM +0400, Dmitry V. Levin wrote:
> Интерфейс управления разграничением доступа к сборке пакетов из git.alt
> будет отличаться от действующего интерфейса list.src.classic&notes для
> управления разграничением доступа к сборке пакетов через incoming.
> 
> Цель изменения acl -- упростить совместную разработку.
> Основная идея: наследование истории изменений сделать обязательным,
> по умолчанию разрешить сборку всем.
> 
> Предполагается реализовать git.alt acl следующим образом.
> + acl по прежнему состоит из 2 частей: список пакетов (packages) и
>   список групп мантейнеров (groups).
> + Первоначально оба списка пусты.
> + Пакет, не упомянутый в packages, считается новым.
> + Сборку нового пакета может предпринять любой потенциальный мантейнер.
> + Новый пакет, будучи успешно собранным, закрепляется за его мантейнером
>   путём внесения соответствующей записи в packages (и, возможно, groups).
> + Новая сборка пакета, не являющегося новым, должна основываться на
>   последней успешной сборке этого пакета.
> + Новую сборку пакета может предпринять любой, если только
>   мантейнер этого пакета не установил ограничений.
> + Мантейнер при помощи своего etc/packages.git может:
>   - ограничить список тех, кому можно отправлять на сборку
>     закреплённые за ним пакеты;
>   - передать закреплённый за ним пакет другому мантейнеру,
>     тем самым закрепив этот пакет за новым мантейнером;
>   - отказаться от закреплённого за ним пакета, тем самым давая
>     возможность сборке этого пакета в качестве нового.
> + Актуальное состояние списков, образующих git.alt acl, будет доступно
>   на http://git.altlinux.org/

Мне кажется это недостаточно гибким.  На все важные пакеты всё равно
будет установлен жесткий ACL (чтобы кто-нибудь не залил openssl 0.9.8g).
Останутся "второсортные" пакеты, которые компрометируют институт
мейнетнерства (более или менее персональной ответственности за
работоспособность пакета).

Вообще идея раннего ACL в связи с предложенным означает слишком
диаметральное рсслоение -- либо априорное доверие, либо априорное
недоверие.  На практике же доверие -- штука тонкая, "доверяй но
проверяй".  Хотелось бы иметь механизм подтверждения (или отмены)
"неавторизированных" сборок вопреки ACL.  А именно, хочется, чтобы
неавторизированную сборку можно было "быстро подтвердить" или же,
наоборот, "быстро отшить".  Mainatiner не всегда может быстро
среагировать, поэтому нужен арбитр.
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : =?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/20080616/1a635145/attachment-0002.bin>