[devel] ACL Policy #3

[devel] ACL Policy #3

[Anton Farygin]

http://www.altlinux.org/ACLPolicy

Две недели обсуждения уже прошло. Последнее существенное изменение я 
внёс сегодня.

Звучит оно так:
"Мейнтейнер считается пропавшим для всех его пакетов без исключения. 
Дальнейшие запросы на добавление в ACL Администратор репозитария обязан 
выполнять без периода ожидания, до тех пор, пока мейнтейнер не появится 
и не заявит о себе в bugzilla или списке рассылки."

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

Если возражений нет, то просьба к принимающему - принять.

Re: [devel] ACL Policy #3

[Michael Shigorin]

On Tue, Jun 16, 2009 at 12:55:02AM +0400, Anton Farygin wrote:
> Это сделано для того, что бы не выжидать период ожидания для
> всех пакетов пропавшего мейнтейнера.

Резонно.

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

Re: [devel] ACL Policy #3

[Alexey Gladkov]

16.06.2009 00:55, Anton Farygin wrote:
> Если возражений нет, то просьба к принимающему - принять.

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

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

-- 
Rgrds, legion

Re: [devel] ACL Policy #3

[Anton Farygin]

Alexey Gladkov пишет:
> 16.06.2009 00:55, Anton Farygin wrote:
>> Если возражений нет, то просьба к принимающему - принять.
> 
> Я не согласен с динамической сменой лидера. Мне кажется, что требуются
> более веские причины для смены лидера т.к. иначе будущий лидер всегда
> сможет сделать три последовательные сборки меняя в %description "A" на
> "B", потом "B" на "C" и затем "C" на "A".
> 
> Впиши, например, чтобы кандидат исправлял ошибки ciritcal и выше. Всё
> лучше, чем просто три дежурные сборки пакета (в любом пакете есть, что
> исправить).

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

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


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

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

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

Re: [devel] ACL Policy #3

[Michael Shigorin]

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/

Re: [devel] ACL Policy #3

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 587 bytes --]

On Tue, Jun 16, 2009 at 12:55:02AM +0400, Anton Farygin wrote:
> http://www.altlinux.org/ACLPolicy
> 
> Две недели обсуждения уже прошло. 

Предлагаю вынести раздел "Динамическая смена лидера" из нормативной части,
поскольку с ним есть 2 проблемы:
- есть разногласие, по которому не достигнуто взаимопонимания;
- присутствует требование к git.alt builder, не обеспеченное реализацией.

Вообще, я не вижу смысла вводить в действие policy, содержащее требование
к функциональности git.alt, если на момент введения в действие указанное
требование не реализовано.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] ACL Policy #3

[Anton Farygin]

Dmitry V. Levin пишет:
> On Tue, Jun 16, 2009 at 12:55:02AM +0400, Anton Farygin wrote:
>> http://www.altlinux.org/ACLPolicy
>>
>> Две недели обсуждения уже прошло. 
> 
> Предлагаю вынести раздел "Динамическая смена лидера" из нормативной части,
> поскольку с ним есть 2 проблемы:
> - есть разногласие, по которому не достигнуто взаимопонимания;
> - присутствует требование к git.alt builder, не обеспеченное реализацией.
> 
> Вообще, я не вижу смысла вводить в действие policy, содержащее требование
> к функциональности git.alt, если на момент введения в действие указанное
> требование не реализовано.

Устроит ли вариант, когда мы Динамическую смену лидера сделаем "по 
требованию" ?

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

Re: [devel] ACL Policy #3

[Afanasov Dmitry]

[-- Attachment #1: Type: text/plain, Size: 570 bytes --]

On Wed, Jun 17, 2009 at 09:00:45AM +0400, Anton Farygin wrote:
> Dmitry V. Levin пишет:
> Устроит ли вариант, когда мы Динамическую смену лидера сделаем "по 
> требованию" ?
> 
> Т.е., звучать будет примерно так:
> мейнтейнер, выполнивший три сборки подряд одного пакета может 
> потребовать у администратора репозитория права лидера пакета.
коммент из зала: меня устраивает много больше первоначальной версии.

автосмена лидера действительно нивелирует весь смысл лидера и делает его
бесполезным. проще сразу отказаться.
-- 
С уважением
Афанасов Дмитрий

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] ACL Policy #3

[Igor Vlasenko]

On Wed, Jun 17, 2009 at 02:22:25AM +0400, Dmitry V. Levin wrote:
> On Tue, Jun 16, 2009 at 12:55:02AM +0400, Anton Farygin wrote:
> > http://www.altlinux.org/ACLPolicy
> > 
> > Две недели обсуждения уже прошло. 
> 
> Предлагаю вынести раздел "Динамическая смена лидера" из нормативной части,
> поскольку с ним есть 2 проблемы:
> - есть разногласие, по которому не достигнуто взаимопонимания;

Гм. единственный, кто высказался против, это Алексей Гладков. 
но была еще дискуссия.
Наверное, надо попросить Алексея подтвердить позицию.

> - присутствует требование к git.alt builder, не обеспеченное реализацией.

Я как инициатор буду обеспечивать реализацией указанное требование.

> Вообще, я не вижу смысла вводить в действие policy, содержащее требование
> к функциональности git.alt, если на момент введения в действие указанное
> требование не реализовано.

А я не вижу смысла обеспечивать реализацией требование, 
если оно не основано на policy.

-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine

Re: [devel] ACL Policy #3

[Aleksey Novodvorsky]

17 июня 2009 г. 10:23 пользователь Igor Vlasenko
(vlasenko@imath.kiev.ua) написал:
> On Wed, Jun 17, 2009 at 02:22:25AM +0400, Dmitry V. Levin wrote:
>> On Tue, Jun 16, 2009 at 12:55:02AM +0400, Anton Farygin wrote:
>> > http://www.altlinux.org/ACLPolicy
>> >
>> > Две недели обсуждения уже прошло.
>>
>> Предлагаю вынести раздел "Динамическая смена лидера" из нормативной части,
>> поскольку с ним есть 2 проблемы:
>> - есть разногласие, по которому не достигнуто взаимопонимания;
>
> Гм. единственный, кто высказался против, это Алексей Гладков.
> но была еще дискуссия.
> Наверное, надо попросить Алексея подтвердить позицию.
>
>> - присутствует требование к git.alt builder, не обеспеченное реализацией.
>
> Я как инициатор буду обеспечивать реализацией указанное требование.
>
>> Вообще, я не вижу смысла вводить в действие policy, содержащее требование
>> к функциональности git.alt, если на момент введения в действие указанное
>> требование не реализовано.
>
> А я не вижу смысла обеспечивать реализацией требование,
> если оно не основано на policy.


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

Rgrds, Алексей

>
> --
>
> Dr. Igor Vlasenko
> --------------------
> Topology Department
> Institute of Math
> Kiev, Ukraine
>
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

Re: [devel] ACL Policy #3

[Alexey I. Froloff]

[-- Attachment #1: Type: text/plain, Size: 501 bytes --]

On Wed, Jun 17, 2009 at 09:23:39AM +0300, Igor Vlasenko wrote:
> > Предлагаю вынести раздел "Динамическая смена лидера" из нормативной части,
> > поскольку с ним есть 2 проблемы:
> > - есть разногласие, по которому не достигнуто взаимопонимания;
> Гм. единственный, кто высказался против, это Алексей Гладков. 
> но была еще дискуссия.
Я тоже против, потому как не описания алгоритма смены лидера.
Если такой алгоритм появится, у меня будут уже другие возражения.

-- 
Regards,
Sir Raorn.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] ACL Policy #3

[Igor Vlasenko]

On Wed, Jun 17, 2009 at 12:39:12PM +0400, Alexey I. Froloff wrote:
> On Wed, Jun 17, 2009 at 09:23:39AM +0300, Igor Vlasenko wrote:
> > > Предлагаю вынести раздел "Динамическая смена лидера" из нормативной части,
> > > поскольку с ним есть 2 проблемы:
> > > - есть разногласие, по которому не достигнуто взаимопонимания;
> > Гм. единственный, кто высказался против, это Алексей Гладков. 
> > но была еще дискуссия.
> Я тоже против

Жалко. 
Надо бы поощрять тех, кто делает,
а не тех, кто и сам не делает, и другим не дает.

Разведем феодализм :(

-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine

Re: [devel] ACL Policy #3

[Alexey Gladkov]

17.06.2009 10:23, Igor Vlasenko wrote:
> Гм. единственный, кто высказался против, это Алексей Гладков. 
> но была еще дискуссия.
> Наверное, надо попросить Алексея подтвердить позицию.

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

-- 
Rgrds, legion

Re: [devel] ACL Policy #3

[Anton Farygin]

Alexey Gladkov пишет:
> 17.06.2009 10:23, Igor Vlasenko wrote:
>> Гм. единственный, кто высказался против, это Алексей Гладков. 
>> но была еще дискуссия.
>> Наверное, надо попросить Алексея подтвердить позицию.
> 
> Я всё также против. Если нет ограничений на содержательность сборки,
> то требование трёх сборок можно совсем выкинуть из полиси и отдавать
> лидерство сразу. Это требование будет выполняться всегда, если есть
> желание его выполнить. Оно не несёт ограничений и только добавляет
> тупой работы мантейнеру. Это также скажется на пользователях,
> вынужденных устанавливать себе эти сборки.

Т.е. - мы пишем, что лидер пакета может быть заменён в том случае, если 
второй мейтнейнер этого пакета запрашивает себе права лидера ?

такая формулировка всех устроит ?:

лидер пакета может быть изменён в том случае, если он признан как 
пропавший мейнтейнер и не никак не проявлял себя в bugzilla в течении 45 
суток с момента обращения за лидерством или ACL на пакет.

Re: [devel] ACL Policy #3

[Igor Vlasenko]

On Wed, Jun 17, 2009 at 03:02:34PM +0400, Anton Farygin wrote:
> Т.е. - мы пишем, что лидер пакета может быть заменён в том случае, если  
> второй мейтнейнер этого пакета запрашивает себе права лидера ?
>
> такая формулировка всех устроит ?:
>
> лидер пакета может быть изменён в том случае, если он признан как  
> пропавший мейнтейнер и не никак не проявлял себя в bugzilla в течении 45  
> суток с момента обращения за лидерством или ACL на пакет.

Такая формулировка не нужна.
Она практически не нужна.

На практике, лидер нужен, чтобы __СРОЧНО__
выдать кому-то NMU или acl.

Соответственно, если лидер исчез,
то заинтересованным сторонам (комайнтайнерам)
технически будет проще и быстрее теребить администратора.

45 суток никто ждать не будет.

Т.е. мертвых лидеров никто закапывать не будет,
а нагрузка ляжет на администратора.
В т.ч. и возможные кофликты будут иметь уже 
не двухсторонний, а трехсторонний характер
(с участием администратора и претензиями к администратору).

Жаль. Так польское панство закопало Речь Посполитую :(

-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine

Re: [devel] ACL Policy #3, fixed

[Anton Farygin]

Igor Vlasenko пишет:
> Т.е. мертвых лидеров никто закапывать не будет,
> а нагрузка ляжет на администратора.
> В т.ч. и возможные кофликты будут иметь уже 
> не двухсторонний, а трехсторонний характер
> (с участием администратора и претензиями к администратору).
> 
> Жаль. Так польское панство закопало Речь Посполитую :(


Согласен. Просто у нас в сизифе издревна сложилась такая картина, когда 
часть мейнтейнеров сидит на своих пакетах как курица на яйцах. И любая 
попытка либерализации ACL для них выглядет как попытка "отобрать" у них 
пакеты.

Странно, правда ? Закон Тома Сойера в действии, только этого почему-то 
никто не понимает...

Мне, как автору первоначального текста, смена лидера не нужна. 
достаточно будет добавление нового мейнтейнера.

Убрал этот пункт. До лучших времён. Добавить не сложно, сложнее убедить.

2ldv: просьба принять.

Re: [devel] ACL Policy #3, fixed

[Michael Shigorin]

On Wed, Jun 17, 2009 at 03:45:59PM +0400, Anton Farygin wrote:
> Согласен. Просто у нас в сизифе издревна сложилась такая
> картина, когда часть мейнтейнеров сидит на своих пакетах как
> курица на яйцах. И любая попытка либерализации ACL для них
> выглядет как попытка "отобрать" у них пакеты.

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

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

Re: [devel] ACL Policy #3

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1254 bytes --]

On Wed, Jun 17, 2009 at 02:27:46PM +0300, Igor Vlasenko wrote:
> On Wed, Jun 17, 2009 at 03:02:34PM +0400, Anton Farygin wrote:
> > Т.е. - мы пишем, что лидер пакета может быть заменён в том случае, если  
> > второй мейтнейнер этого пакета запрашивает себе права лидера ?
> >
> > такая формулировка всех устроит ?:
> >
> > лидер пакета может быть изменён в том случае, если он признан как  
> > пропавший мейнтейнер и не никак не проявлял себя в bugzilla в течении 45  
> > суток с момента обращения за лидерством или ACL на пакет.
> 
> Такая формулировка не нужна.
> Она практически не нужна.
> 
> На практике, лидер нужен, чтобы __СРОЧНО__
> выдать кому-то NMU или acl.
> 
> Соответственно, если лидер исчез,
> то заинтересованным сторонам (комайнтайнерам)
> технически будет проще и быстрее теребить администратора.
> 
> 45 суток никто ждать не будет.
> 
> Т.е. мертвых лидеров никто закапывать не будет,
> а нагрузка ляжет на администратора.
> В т.ч. и возможные кофликты будут иметь уже 
> не двухсторонний, а трехсторонний характер
> (с участием администратора и претензиями к администратору).
> 
> Жаль. Так польское панство закопало Речь Посполитую :(

Тогда давайте пересмотрим понятие лидера ACL.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]