Re: [devel] ACL Policy #3

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

On Tue, Jun 16, 2009 at 10:33:49AM +0400, Anton Farygin wrote:
> >>Если возражений нет, то просьба к принимающему - принять.
> >Я не согласен с динамической сменой лидера.

Лёш, это факт из жизни: люди _теряют_ интерес в конкретных
пакетах, а порой пропадают, причём бывает и неожиданно для себя
самих -- свалились какие обстоятельства на голову и знаешь,
совсем не до правки ACL или даже письма "собира...".

> >Мне кажется, что требуются более веские причины для смены
> >лидера т.к. иначе будущий лидер всегда сможет сделать три
> >последовательные сборки меняя в %description "A" на "B", потом
> >"B" на "C" и затем "C" на "A".

Это же фиксируется в gears, при _необходимости_ разборки можно её
учинить и уладить всё -- с помощью канделябра или по-человечески.

Ты подразумеваешь злонамерение по умолчанию, а зря.

> >Впиши, например, чтобы кандидат исправлял ошибки ciritcal и
> >выше. Всё лучше, чем просто три дежурные сборки пакета (в
> >любом пакете есть, что исправить).

Можно и критикалы высасывать из пальца, причём даже так,
чтоб формально подходили под критерии.

> Нет, именно три дежурные сборки.

Сказал бы "полезные", но критерий полезности формализовать тоже
сложно (в багах?  так их можно понавешать "ради галочки"
практически на любой пакет пачку).  Мне опять же кажется более 
важным намерение: если я не могу заниматься apache, а solo@ хочет
его улучшить -- так или иначе, заблокировав его работу, я не дам
даже шанса сравнить результаты.

Или вот если vvk@ спрашивал ACL на hddtemp (помимо дополнений
в багзиле), а текущий лидер долго не мог добраться -- то налицо
теряемая впустую инициатива.  Причём злого умысла не вижу ни с
одной стороны, просто обстоятельства и технические барьеры.

> Если мейнтейнер (лидер) не исправляет ошибки, которые можно
> исправить - то зачем такой лидер у пакета ?  И если для этого
> пакета есть более эффективный мейнтейнер, то лучше дать ему
> возможность работать, а не строить препятствия.

+1

> Вспомним первое обсуждение ACLPolicy - это сделано для того,
> что бы пропавший мейнтейнер спокойно заменялся новым. Я не
> думаю, что кто-то злонамеренно будет делать три подряд сборки с
> тривиальным изменением только для того, что бы стать лидером в
> ACL. Если это произойдёт, то это повод отдельно разбираться с
> этим человеком.

Вот именно.  Это exception.

> Опять же - если так подумать, то что ты можешь потерять, как
> лидер ?  возможность менять ACL у пакета, не более того (а оно
> тебе надо) ?

Скажем так -- если надо, то надо было реагировать на запрос ACL.
Даже если и отрицательно.  А если не реагировал -- значит,
_по факту_ не надо.

> Я бы вообще предложил убрать институт лидерства у пакетов и
> разрешить менять ACL всем, кто хоть когда-то собирал этот пакет
> (соответстенно он в теме), но видимо многим это сложно,
> соответственно делаем небольшой шажок - лидер ничто

Ой не уверен: некоторые пакеты тривиально чинил, но совсем бы не
хотел подписываться на некие дополнительные обязательства
(в текущей системе таковых).  Потому как, например, в багзиле
в Cc: сейчас добавляются все, кто в ACL пакета, и это правильно.
(хм... кстати, этот способ информирования при отцеплении ACL
может пострадать, не по всем же бывшим сборщикам тогда спамить)

> важен тот, кто работает на благо пакета.

Да, но семантика лидера как ответственного -- ну или крайнего
-- вообще-то правильная.  Просто подключиться к работе должно
быть не так много мороки, особенно если пакет не из важных.

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