[devel] Q: Do not EPERM test-only tasks

[devel] Q: Do not EPERM test-only tasks

[Vitaly Chikunov]

Hi,

Предлагаю test-only таски не переводить в состояние EPERM. Это позволит
легко отличить в почте результат run --test-only от run --commit!

Thanks,

Re: [devel] Q: Do not EPERM test-only tasks

[Aleksey Novodvorsky]

чт, 3 дек. 2020 г. в 21:14, Vitaly Chikunov <vt@altlinux.org>:
>
> Hi,
>
> Предлагаю test-only таски не переводить в состояние EPERM. Это позволит
> легко отличить в почте результат run --test-only от run --commit!

+1

Путаница именно в этом.

Rgrds, Алексей

>
> Thanks,
>
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

Re: [devel] Q: Do not EPERM test-only tasks

[Dmitry V. Levin]

On Thu, Dec 03, 2020 at 09:14:02PM +0300, Vitaly Chikunov wrote:
> Hi,
> 
> Предлагаю test-only таски не переводить в состояние EPERM. Это позволит
> легко отличить в почте результат run --test-only от run --commit!

А в какое состояние тогда их переводить?


-- 
ldv

Re: [devel] Q: Do not EPERM test-only tasks

[Vitaly Chikunov]

On Thu, Dec 03, 2020 at 09:26:34PM +0300, Dmitry V. Levin wrote:
> On Thu, Dec 03, 2020 at 09:14:02PM +0300, Vitaly Chikunov wrote:
> > Hi,
> > 
> > Предлагаю test-only таски не переводить в состояние EPERM. Это позволит
> > легко отличить в почте результат run --test-only от run --commit!
> 
> А в какое состояние тогда их переводить?

Варианты: TESTED, TESTEPERM,

Re: [devel] Q: Do not EPERM test-only tasks

[Anton Farygin]

On 03.12.2020 21:30, Vitaly Chikunov wrote:
> On Thu, Dec 03, 2020 at 09:26:34PM +0300, Dmitry V. Levin wrote:
>> On Thu, Dec 03, 2020 at 09:14:02PM +0300, Vitaly Chikunov wrote:
>>> Hi,
>>>
>>> Предлагаю test-only таски не переводить в состояние EPERM. Это позволит
>>> легко отличить в почте результат run --test-only от run --commit!
>> А в какое состояние тогда их переводить?
> Варианты: TESTED, TESTEPERM,

не надо использовать термин TESTED для заданий, которые не TESTED.

Я предпочёл бы BUILD COMPLETED.

А вместо --test-only опцию --no-commit

Re: [devel] Q: Do not EPERM test-only tasks

[Vitaly Chikunov]

On Thu, Dec 03, 2020 at 09:36:16PM +0300, Anton Farygin wrote:
> On 03.12.2020 21:30, Vitaly Chikunov wrote:
> > On Thu, Dec 03, 2020 at 09:26:34PM +0300, Dmitry V. Levin wrote:
> > > On Thu, Dec 03, 2020 at 09:14:02PM +0300, Vitaly Chikunov wrote:
> > > > Hi,
> > > > 
> > > > Предлагаю test-only таски не переводить в состояние EPERM. Это позволит
> > > > легко отличить в почте результат run --test-only от run --commit!
> > > А в какое состояние тогда их переводить?
> > Варианты: TESTED, TESTEPERM,
> 
> не надо использовать термин TESTED для заданий, которые не TESTED.

Я думаю, что не надо смешивать разные feature requests в один.

> 
> Я предпочёл бы BUILD COMPLETED.
> 
> А вместо --test-only опцию --no-commit
> 
> 
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

Re: [devel] Q: Do not EPERM test-only tasks

[Anton Farygin]

On 03.12.2020 21:44, Vitaly Chikunov wrote:
> On Thu, Dec 03, 2020 at 09:36:16PM +0300, Anton Farygin wrote:
>> On 03.12.2020 21:30, Vitaly Chikunov wrote:
>>> On Thu, Dec 03, 2020 at 09:26:34PM +0300, Dmitry V. Levin wrote:
>>>> On Thu, Dec 03, 2020 at 09:14:02PM +0300, Vitaly Chikunov wrote:
>>>>> Hi,
>>>>>
>>>>> Предлагаю test-only таски не переводить в состояние EPERM. Это позволит
>>>>> легко отличить в почте результат run --test-only от run --commit!
>>>> А в какое состояние тогда их переводить?
>>> Варианты: TESTED, TESTEPERM,
>> не надо использовать термин TESTED для заданий, которые не TESTED.
> Я думаю, что не надо смешивать разные feature requests в один.

Да, ок. Давай этого медведя есть маленькими кусочками.

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

Re: [devel] Q: Do not EPERM test-only tasks

[Dmitry V. Levin]

On Thu, Dec 03, 2020 at 09:30:00PM +0300, Vitaly Chikunov wrote:
> On Thu, Dec 03, 2020 at 09:26:34PM +0300, Dmitry V. Levin wrote:
> > On Thu, Dec 03, 2020 at 09:14:02PM +0300, Vitaly Chikunov wrote:
> > > Hi,
> > > 
> > > Предлагаю test-only таски не переводить в состояние EPERM. Это позволит
> > > легко отличить в почте результат run --test-only от run --commit!
> > 
> > А в какое состояние тогда их переводить?
> 
> Варианты: TESTED, TESTEPERM,

Я не понял, что предлагается, убрать acl check из test-only tasks?
Или игнорировать результат acl check для test-only tasks?

Я пока не понял, что именно не устраивает в нынешней ситуации.
Задания в состояние EPERM, которые test-only, явно помечены как test-only.


-- 
ldv

Re: [devel] Q: Do not EPERM test-only tasks

[Anton Farygin]

On 03.12.2020 21:51, Dmitry V. Levin wrote:
> On Thu, Dec 03, 2020 at 09:30:00PM +0300, Vitaly Chikunov wrote:
>> On Thu, Dec 03, 2020 at 09:26:34PM +0300, Dmitry V. Levin wrote:
>>> On Thu, Dec 03, 2020 at 09:14:02PM +0300, Vitaly Chikunov wrote:
>>>> Hi,
>>>>
>>>> Предлагаю test-only таски не переводить в состояние EPERM. Это позволит
>>>> легко отличить в почте результат run --test-only от run --commit!
>>> А в какое состояние тогда их переводить?
>> Варианты: TESTED, TESTEPERM,
> Я не понял, что предлагается, убрать acl check из test-only tasks?
> Или игнорировать результат acl check для test-only tasks?
>
> Я пока не понял, что именно не устраивает в нынешней ситуации.
> Задания в состояние EPERM, которые test-only, явно помечены как test-only.

Если я правильно понял идею автора - предлагается ввести новое состояние 
сборочного задания, означающее что сборка прошла и задание готово к 
COMMIT в репозиторий.

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

Re: [devel] Q: Do not EPERM test-only tasks

[Dmitry V. Levin]

On Thu, Dec 03, 2020 at 09:56:48PM +0300, Anton Farygin wrote:
> On 03.12.2020 21:51, Dmitry V. Levin wrote:
> > On Thu, Dec 03, 2020 at 09:30:00PM +0300, Vitaly Chikunov wrote:
> >> On Thu, Dec 03, 2020 at 09:26:34PM +0300, Dmitry V. Levin wrote:
> >>> On Thu, Dec 03, 2020 at 09:14:02PM +0300, Vitaly Chikunov wrote:
> >>>> Hi,
> >>>>
> >>>> Предлагаю test-only таски не переводить в состояние EPERM. Это позволит
> >>>> легко отличить в почте результат run --test-only от run --commit!
> >>> А в какое состояние тогда их переводить?
> >> Варианты: TESTED, TESTEPERM,
> > Я не понял, что предлагается, убрать acl check из test-only tasks?
> > Или игнорировать результат acl check для test-only tasks?
> >
> > Я пока не понял, что именно не устраивает в нынешней ситуации.
> > Задания в состояние EPERM, которые test-only, явно помечены как test-only.
> 
> Если я правильно понял идею автора - предлагается ввести новое состояние 
> сборочного задания, означающее что сборка прошла и задание готово к 
> COMMIT в репозиторий.
> 
> При этом если в этом задании наступил EPERM, то явно это не показывать в 
> состоянии сборочного задания.

Но если задание не прошло acl check, то оно явно не готово быть
закоммиченным в репозиторий.  Если предлагается эту информацию скрыть,
то как этим тогда пользоваться?


-- 
ldv

Re: [devel] Q: Do not EPERM test-only tasks

[Vitaly Chikunov]

On Thu, Dec 03, 2020 at 09:51:09PM +0300, Dmitry V. Levin wrote:
> On Thu, Dec 03, 2020 at 09:30:00PM +0300, Vitaly Chikunov wrote:
> > On Thu, Dec 03, 2020 at 09:26:34PM +0300, Dmitry V. Levin wrote:
> > > On Thu, Dec 03, 2020 at 09:14:02PM +0300, Vitaly Chikunov wrote:
> > > > Hi,
> > > > 
> > > > Предлагаю test-only таски не переводить в состояние EPERM. Это позволит
> > > > легко отличить в почте результат run --test-only от run --commit!
> > > 
> > > А в какое состояние тогда их переводить?
> > 
> > Варианты: TESTED, TESTEPERM,
> 
> Я не понял, что предлагается, убрать acl check из test-only tasks?

Я не предлагал вариантов как это реализовать.

> Или игнорировать результат acl check для test-only tasks?
> 
> Я пока не понял, что именно не устраивает в нынешней ситуации.
> Задания в состояние EPERM, которые test-only, явно помечены как test-only.

Да, но все равно это путает. Почему-то у меня EPERM оверрайдит test-only
в голове. Впрочем, если считаешь, что пользы от этого нет то ОК, для
этого и обсуждение.

Re: [devel] Q: Do not EPERM test-only tasks

[Anton Farygin]

On 03.12.2020 22:00, Dmitry V. Levin wrote:
> On Thu, Dec 03, 2020 at 09:56:48PM +0300, Anton Farygin wrote:
>> On 03.12.2020 21:51, Dmitry V. Levin wrote:
>>> On Thu, Dec 03, 2020 at 09:30:00PM +0300, Vitaly Chikunov wrote:
>>>> On Thu, Dec 03, 2020 at 09:26:34PM +0300, Dmitry V. Levin wrote:
>>>>> On Thu, Dec 03, 2020 at 09:14:02PM +0300, Vitaly Chikunov wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Предлагаю test-only таски не переводить в состояние EPERM. Это позволит
>>>>>> легко отличить в почте результат run --test-only от run --commit!
>>>>> А в какое состояние тогда их переводить?
>>>> Варианты: TESTED, TESTEPERM,
>>> Я не понял, что предлагается, убрать acl check из test-only tasks?
>>> Или игнорировать результат acl check для test-only tasks?
>>>
>>> Я пока не понял, что именно не устраивает в нынешней ситуации.
>>> Задания в состояние EPERM, которые test-only, явно помечены как test-only.
>> Если я правильно понял идею автора - предлагается ввести новое состояние
>> сборочного задания, означающее что сборка прошла и задание готово к
>> COMMIT в репозиторий.
>>
>> При этом если в этом задании наступил EPERM, то явно это не показывать в
>> состоянии сборочного задания.
> Но если задание не прошло acl check, то оно явно не готово быть
> закоммиченным в репозиторий.  Если предлагается эту информацию скрыть,
> то как этим тогда пользоваться?

COMMIT можно сделать и для EPERM задания (с approve и run со стороны). 
Т.е. - состояние EPERM не означает что заданию нельзя сделать commit.

как вариант можно сделать одновременное отображения сразу двух 
состояний, например: [BUILD DONE][EPERM]

Re: [devel] Q: Do not EPERM test-only tasks

[Dmitry V. Levin]

On Thu, Dec 03, 2020 at 10:04:02PM +0300, Vitaly Chikunov wrote:
> On Thu, Dec 03, 2020 at 09:51:09PM +0300, Dmitry V. Levin wrote:
> > On Thu, Dec 03, 2020 at 09:30:00PM +0300, Vitaly Chikunov wrote:
> > > On Thu, Dec 03, 2020 at 09:26:34PM +0300, Dmitry V. Levin wrote:
> > > > On Thu, Dec 03, 2020 at 09:14:02PM +0300, Vitaly Chikunov wrote:
> > > > > Hi,
> > > > > 
> > > > > Предлагаю test-only таски не переводить в состояние EPERM. Это позволит
> > > > > легко отличить в почте результат run --test-only от run --commit!
> > > > 
> > > > А в какое состояние тогда их переводить?
> > > 
> > > Варианты: TESTED, TESTEPERM,
> > 
> > Я не понял, что предлагается, убрать acl check из test-only tasks?
> 
> Я не предлагал вариантов как это реализовать.
> 
> > Или игнорировать результат acl check для test-only tasks?
> > 
> > Я пока не понял, что именно не устраивает в нынешней ситуации.
> > Задания в состояние EPERM, которые test-only, явно помечены как test-only.
> 
> Да, но все равно это путает. Почему-то у меня EPERM оверрайдит test-only
> в голове. Впрочем, если считаешь, что пользы от этого нет то ОК, для
> этого и обсуждение.

Допустим, это путает, а какой вариант будет путать меньше?
 
Если acl check будет происходить после того, как задание (не важно,
test-only или нет) оказалось в состоянии TESTED, это будет удобнее?
  
Условно говоря, BUILDING -> TESTED -> CHECKPERM -> PENDING|EPERM
(где CHECKPERM - это некое новое промежуточное, не обязательно видимое
состояние)?


-- 
ldv

Re: [devel] Q: Do not EPERM test-only tasks

[Dmitry V. Levin]

On Thu, Dec 03, 2020 at 10:07:52PM +0300, Anton Farygin wrote:
> On 03.12.2020 22:00, Dmitry V. Levin wrote:
> > On Thu, Dec 03, 2020 at 09:56:48PM +0300, Anton Farygin wrote:
> >> On 03.12.2020 21:51, Dmitry V. Levin wrote:
> >>> On Thu, Dec 03, 2020 at 09:30:00PM +0300, Vitaly Chikunov wrote:
> >>>> On Thu, Dec 03, 2020 at 09:26:34PM +0300, Dmitry V. Levin wrote:
> >>>>> On Thu, Dec 03, 2020 at 09:14:02PM +0300, Vitaly Chikunov wrote:
> >>>>>> Hi,
> >>>>>>
> >>>>>> Предлагаю test-only таски не переводить в состояние EPERM. Это позволит
> >>>>>> легко отличить в почте результат run --test-only от run --commit!
> >>>>> А в какое состояние тогда их переводить?
> >>>> Варианты: TESTED, TESTEPERM,
> >>> Я не понял, что предлагается, убрать acl check из test-only tasks?
> >>> Или игнорировать результат acl check для test-only tasks?
> >>>
> >>> Я пока не понял, что именно не устраивает в нынешней ситуации.
> >>> Задания в состояние EPERM, которые test-only, явно помечены как test-only.
> >> Если я правильно понял идею автора - предлагается ввести новое состояние
> >> сборочного задания, означающее что сборка прошла и задание готово к
> >> COMMIT в репозиторий.
> >>
> >> При этом если в этом задании наступил EPERM, то явно это не показывать в
> >> состоянии сборочного задания.
> > Но если задание не прошло acl check, то оно явно не готово быть
> > закоммиченным в репозиторий.  Если предлагается эту информацию скрыть,
> > то как этим тогда пользоваться?
> 
> COMMIT можно сделать и для EPERM задания (с approve и run со стороны). 
> Т.е. - состояние EPERM не означает что заданию нельзя сделать commit.

В моём понимании вещей EPERM означает, что заданию нельзя сделать commit.


-- 
ldv

Re: [devel] Q: Do not EPERM test-only tasks

[Anton Farygin]

On 03.12.2020 22:18, Dmitry V. Levin wrote:
> On Thu, Dec 03, 2020 at 10:07:52PM +0300, Anton Farygin wrote:
>> On 03.12.2020 22:00, Dmitry V. Levin wrote:
>>> On Thu, Dec 03, 2020 at 09:56:48PM +0300, Anton Farygin wrote:
>>>> On 03.12.2020 21:51, Dmitry V. Levin wrote:
>>>>> On Thu, Dec 03, 2020 at 09:30:00PM +0300, Vitaly Chikunov wrote:
>>>>>> On Thu, Dec 03, 2020 at 09:26:34PM +0300, Dmitry V. Levin wrote:
>>>>>>> On Thu, Dec 03, 2020 at 09:14:02PM +0300, Vitaly Chikunov wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> Предлагаю test-only таски не переводить в состояние EPERM. Это позволит
>>>>>>>> легко отличить в почте результат run --test-only от run --commit!
>>>>>>> А в какое состояние тогда их переводить?
>>>>>> Варианты: TESTED, TESTEPERM,
>>>>> Я не понял, что предлагается, убрать acl check из test-only tasks?
>>>>> Или игнорировать результат acl check для test-only tasks?
>>>>>
>>>>> Я пока не понял, что именно не устраивает в нынешней ситуации.
>>>>> Задания в состояние EPERM, которые test-only, явно помечены как test-only.
>>>> Если я правильно понял идею автора - предлагается ввести новое состояние
>>>> сборочного задания, означающее что сборка прошла и задание готово к
>>>> COMMIT в репозиторий.
>>>>
>>>> При этом если в этом задании наступил EPERM, то явно это не показывать в
>>>> состоянии сборочного задания.
>>> Но если задание не прошло acl check, то оно явно не готово быть
>>> закоммиченным в репозиторий.  Если предлагается эту информацию скрыть,
>>> то как этим тогда пользоваться?
>> COMMIT можно сделать и для EPERM задания (с approve и run со стороны).
>> Т.е. - состояние EPERM не означает что заданию нельзя сделать commit.
> В моём понимании вещей EPERM означает, что заданию нельзя сделать commit.
но промежуточного состояния между EPERM и COMMIT же не возникает ?

Re: [devel] Q: Do not EPERM test-only tasks

[Dmitry V. Levin]

On Thu, Dec 03, 2020 at 10:16:53PM +0300, Dmitry V. Levin wrote:
> On Thu, Dec 03, 2020 at 10:04:02PM +0300, Vitaly Chikunov wrote:
> > On Thu, Dec 03, 2020 at 09:51:09PM +0300, Dmitry V. Levin wrote:
> > > On Thu, Dec 03, 2020 at 09:30:00PM +0300, Vitaly Chikunov wrote:
> > > > On Thu, Dec 03, 2020 at 09:26:34PM +0300, Dmitry V. Levin wrote:
> > > > > On Thu, Dec 03, 2020 at 09:14:02PM +0300, Vitaly Chikunov wrote:
> > > > > > Hi,
> > > > > > 
> > > > > > Предлагаю test-only таски не переводить в состояние EPERM. Это позволит
> > > > > > легко отличить в почте результат run --test-only от run --commit!
> > > > > 
> > > > > А в какое состояние тогда их переводить?
> > > > 
> > > > Варианты: TESTED, TESTEPERM,
> > > 
> > > Я не понял, что предлагается, убрать acl check из test-only tasks?
> > 
> > Я не предлагал вариантов как это реализовать.
> > 
> > > Или игнорировать результат acl check для test-only tasks?
> > > 
> > > Я пока не понял, что именно не устраивает в нынешней ситуации.
> > > Задания в состояние EPERM, которые test-only, явно помечены как test-only.
> > 
> > Да, но все равно это путает. Почему-то у меня EPERM оверрайдит test-only
> > в голове. Впрочем, если считаешь, что пользы от этого нет то ОК, для
> > этого и обсуждение.
> 
> Допустим, это путает, а какой вариант будет путать меньше?
>  
> Если acl check будет происходить после того, как задание (не важно,
> test-only или нет) оказалось в состоянии TESTED, это будет удобнее?
>   
> Условно говоря, BUILDING -> TESTED -> CHECKPERM -> PENDING|EPERM
> (где CHECKPERM - это некое новое промежуточное, не обязательно видимое
> состояние)?

Допустим, test-only задание находится в состоянии TESTED, и автор этого
задания делает ему task run --commit, в результате чего задание переходит
в состояние EPERM.  Вопрос, какие уведомления по каким адресам и с каким
содержанием рассылать в этой ситуации?


-- 
ldv

Re: [devel] Q: Do not EPERM test-only tasks

[Denis Medvedev]

On 12/3/20 10:27 PM, Dmitry V. Levin wrote:
> On Thu, Dec 03, 2020 at 10:16:53PM +0300, Dmitry V. Levin wrote:
>> On Thu, Dec 03, 2020 at 10:04:02PM +0300, Vitaly Chikunov wrote:
>>> On Thu, Dec 03, 2020 at 09:51:09PM +0300, Dmitry V. Levin wrote:
>>>> On Thu, Dec 03, 2020 at 09:30:00PM +0300, Vitaly Chikunov wrote:
>>>>> On Thu, Dec 03, 2020 at 09:26:34PM +0300, Dmitry V. Levin wrote:
>>>>>> On Thu, Dec 03, 2020 at 09:14:02PM +0300, Vitaly Chikunov wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> Предлагаю test-only таски не переводить в состояние EPERM. Это позволит
>>>>>>> легко отличить в почте результат run --test-only от run --commit!
>>>>>> А в какое состояние тогда их переводить?
>>>>> Варианты: TESTED, TESTEPERM,
>>>> Я не понял, что предлагается, убрать acl check из test-only tasks?
>>> Я не предлагал вариантов как это реализовать.
>>>
>>>> Или игнорировать результат acl check для test-only tasks?
>>>>
>>>> Я пока не понял, что именно не устраивает в нынешней ситуации.
>>>> Задания в состояние EPERM, которые test-only, явно помечены как test-only.
>>> Да, но все равно это путает. Почему-то у меня EPERM оверрайдит test-only
>>> в голове. Впрочем, если считаешь, что пользы от этого нет то ОК, для
>>> этого и обсуждение.
>> Допустим, это путает, а какой вариант будет путать меньше?
>>   
>> Если acl check будет происходить после того, как задание (не важно,
>> test-only или нет) оказалось в состоянии TESTED, это будет удобнее?
>>    
>> Условно говоря, BUILDING -> TESTED -> CHECKPERM -> PENDING|EPERM
>> (где CHECKPERM - это некое новое промежуточное, не обязательно видимое
>> состояние)?
> Допустим, test-only задание находится в состоянии TESTED, и автор этого
> задания делает ему task run --commit, в результате чего задание переходит
> в состояние EPERM.  Вопрос, какие уведомления по каким адресам и с каким
> содержанием рассылать в этой ситуации?
>
Два варианта из жизни

1)разработчик сделал тестовое задание

и оно собралось в EPERM.

Дальше он просит администратора бранча его подтвердить и запустить.

Но администратор не может - он не в состоянии запустить EPERM задание

которое TEST-ONLY хотя выглядит оно точно также и для разработчика и для 
администратора.

Я бы различал EPERM тестированного и не тестированного задания как-то. 
Или вообще не вешал бы

EPERM на TESTED задания, ограничиваясь информацией в логах сборки.

2) разработчик сделал тестовое задание, которое в принципе не собирается 
коммитить в бранч.

Тогда EPERM  для него не несет никакой информации, а просто раздражает 
своим отличием от таких

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

для целей тестирования на собираемость в условиях сборочницы.

Re: [devel] Q: Do not EPERM test-only tasks

[Michael Shigorin]

On Thu, Dec 03, 2020 at 10:54:25PM +0300, Denis Medvedev wrote:
> Я бы различал EPERM тестированного и не тестированного задания как-то. 

EPERMED? :)

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [devel] Q: Do not EPERM test-only tasks

[Dmitry V. Levin]

On Thu, Dec 03, 2020 at 10:54:25PM +0300, Denis Medvedev wrote:
> On 12/3/20 10:27 PM, Dmitry V. Levin wrote:
[...]
> > Допустим, test-only задание находится в состоянии TESTED, и автор этого
> > задания делает ему task run --commit, в результате чего задание переходит
> > в состояние EPERM.  Вопрос, какие уведомления по каким адресам и с каким
> > содержанием рассылать в этой ситуации?
> >
> Два варианта из жизни

Это всё очень интересно и полезно, спасибо большое, но будет здорово,
если вы ответите на мой вопрос.


-- 
ldv

Re: [devel] Q: Do not EPERM test-only tasks

[Vitaly Chikunov]

On Thu, Dec 03, 2020 at 10:27:59PM +0300, Dmitry V. Levin wrote:
> On Thu, Dec 03, 2020 at 10:16:53PM +0300, Dmitry V. Levin wrote:
> > On Thu, Dec 03, 2020 at 10:04:02PM +0300, Vitaly Chikunov wrote:
> > > On Thu, Dec 03, 2020 at 09:51:09PM +0300, Dmitry V. Levin wrote:
> > > > On Thu, Dec 03, 2020 at 09:30:00PM +0300, Vitaly Chikunov wrote:
> > > > > On Thu, Dec 03, 2020 at 09:26:34PM +0300, Dmitry V. Levin wrote:
> > > > > > On Thu, Dec 03, 2020 at 09:14:02PM +0300, Vitaly Chikunov wrote:
> > > > > > > Hi,
> > > > > > > 
> > > > > > > Предлагаю test-only таски не переводить в состояние EPERM. Это позволит
> > > > > > > легко отличить в почте результат run --test-only от run --commit!
> > > > > > 
> > > > > > А в какое состояние тогда их переводить?
> > > > > 
> > > > > Варианты: TESTED, TESTEPERM,
> > > > 
> > > > Я не понял, что предлагается, убрать acl check из test-only tasks?
> > > 
> > > Я не предлагал вариантов как это реализовать.
> > > 
> > > > Или игнорировать результат acl check для test-only tasks?
> > > > 
> > > > Я пока не понял, что именно не устраивает в нынешней ситуации.
> > > > Задания в состояние EPERM, которые test-only, явно помечены как test-only.
> > > 
> > > Да, но все равно это путает. Почему-то у меня EPERM оверрайдит test-only
> > > в голове. Впрочем, если считаешь, что пользы от этого нет то ОК, для
> > > этого и обсуждение.
> > 
> > Допустим, это путает, а какой вариант будет путать меньше?
> >  

Запуская --test-only я не обязательно хочу получить acl check (и, как
следствие, ошибку в нём), так как, скорее всего, я и не хотел коммитить
это задание в репозиторий - это просто экспериментальная сборка на всех
основных архитектурах, а не неудавшаяся попытка закоммитить.

Если acl check обязателен и важен, то он может быть написан в логе, или
как-то снижена его психологическая значимость с EPERM, допустим, через
префикс "TEST-".

> > Если acl check будет происходить после того, как задание (не важно,
> > test-only или нет) оказалось в состоянии TESTED, это будет удобнее?
> >   
> > Условно говоря, BUILDING -> TESTED -> CHECKPERM -> PENDING|EPERM
> > (где CHECKPERM - это некое новое промежуточное, не обязательно видимое
> > состояние)?
> 
> Допустим, test-only задание находится в состоянии TESTED, и автор этого
> задания делает ему task run --commit, в результате чего задание переходит
> в состояние EPERM.  Вопрос, какие уведомления по каким адресам и с каким
> содержанием рассылать в этой ситуации?

Так же как сейчас? Разве сейчас они не шлются?

> 
> 
> -- 
> ldv
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

Re: [devel] Q: Do not EPERM test-only tasks

[Dmitry V. Levin]

On Thu, Dec 03, 2020 at 11:03:42PM +0300, Vitaly Chikunov wrote:
> On Thu, Dec 03, 2020 at 10:27:59PM +0300, Dmitry V. Levin wrote:
[...]
> > Допустим, test-only задание находится в состоянии TESTED, и автор этого
> > задания делает ему task run --commit, в результате чего задание переходит
> > в состояние EPERM.  Вопрос, какие уведомления по каким адресам и с каким
> > содержанием рассылать в этой ситуации?
> 
> Так же как сейчас? Разве сейчас они не шлются?

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


-- 
ldv

Re: [devel] Q: Do not EPERM test-only tasks

[Denis Medvedev]

On 12/3/20 10:59 PM, Dmitry V. Levin wrote:
> On Thu, Dec 03, 2020 at 10:54:25PM +0300, Denis Medvedev wrote:
>> On 12/3/20 10:27 PM, Dmitry V. Levin wrote:
> [...]
>>> Допустим, test-only задание находится в состоянии TESTED, и автор этого
>>> задания делает ему task run --commit, в результате чего задание переходит
>>> в состояние EPERM.  Вопрос, какие уведомления по каким адресам и с каким
>>> содержанием рассылать в этой ситуации?
>>>
>> Два варианта из жизни
> Это всё очень интересно и полезно, спасибо большое, но будет здорово,
> если вы ответите на мой вопрос.
>
>
Мой вариант - просто отменить состояние EPERM для TEST-ONLY тасков.

Пусть они всегда будут TESTED.

Про ACL разработчик может узнать

1) из лога - если интересно.

2) когда таки запустит --commit.

Оповещающие рассылки рассылаются по адресам ACL когда делается commit.

Про TESTED никого не оповещать.

Re: [devel] Q: Do not EPERM test-only tasks

[Michael Shigorin]

On Thu, Dec 03, 2020 at 11:10:43PM +0300, Denis Medvedev wrote:
> Про TESTED никого не оповещать.

Ты хотел сказать "кроме отправившего на сборку", наверное.

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [devel] Q: Do not EPERM test-only tasks

[Paul Wolneykien]

В Thu, 3 Dec 2020 21:50:30 +0300
Anton Farygin <rider@basealt.ru> пишет:

> On 03.12.2020 21:44, Vitaly Chikunov wrote:
> > On Thu, Dec 03, 2020 at 09:36:16PM +0300, Anton Farygin wrote:  
> >> On 03.12.2020 21:30, Vitaly Chikunov wrote:  
> >>> On Thu, Dec 03, 2020 at 09:26:34PM +0300, Dmitry V. Levin wrote:  
> >>>> On Thu, Dec 03, 2020 at 09:14:02PM +0300, Vitaly Chikunov wrote:
> >>>>  
> >>>>> Hi,
> >>>>>
> >>>>> Предлагаю test-only таски не переводить в состояние EPERM. Это
> >>>>> позволит легко отличить в почте результат run --test-only от
> >>>>> run --commit!  
> >>>> А в какое состояние тогда их переводить?  
> >>> Варианты: TESTED, TESTEPERM,  
> >> не надо использовать термин TESTED для заданий, которые не TESTED.
> >>  
> > Я думаю, что не надо смешивать разные feature requests в один.  
> 
> Да, ок. Давай этого медведя есть маленькими кусочками.
> 
> не показывать EPERM для заданий, у которых не может быть EPERM потому 
> что они тестовые - эта идея отличная и, наверное, станет легче.

  +1

Re: [devel] Q: Do not EPERM test-only tasks

[Paul Wolneykien]

В Thu, 3 Dec 2020 23:03:42 +0300
Vitaly Chikunov <vt@altlinux.org> пишет:

> > > Допустим, это путает, а какой вариант будет путать меньше?
> > >    
> 
> Запуская --test-only я не обязательно хочу получить acl check (и, как
> следствие, ошибку в нём), так как, скорее всего, я и не хотел
> коммитить это задание в репозиторий - это просто экспериментальная
> сборка на всех основных архитектурах, а не неудавшаяся попытка
> закоммитить.

  Да, в 99% случаев я делаю test-only задание для того, чтобы
удостовериться, что сборка (именно сборка!) _в сборочнице_ пройдёт
успешно. Про ACL я на этот момент уже знаю либо он мне не интересен.
  И если я не получаю в ответ FAILED, то дальше у меня два варианта:
если этой мой пакет, то отправляю --commit, если пакет чужой ---
пытаюсь согласовать NMU с мэйнтейнером этого пакета и передаю ему
ссылку на успешно собравшееся задание в качестве наглядного
доказательства того, что мои изменения хотя бы собираются.
  Ясно дело, что заголовок TESTED в последнем случае выглядел бы более
презентабельно: мол, всё хорошо, не проверяли только ACL. Собственно,
это условие и предлагаю считать условием для выставления TESTED.

  Дополню ещё слова Виталия выше: EPERM --- это ошибка проверки ACL на
предмет возможности commit, так? Если так, то нельзя её получать
незаслуженно, то есть тогда, когда автор задания запускал его не с
целью commit. В этом главное противоречие. Для проверки _потенциальной_
возможности обновить пакет в репозитории существует команда acl show.

Re: [devel] Q: Do not EPERM test-only tasks

[Dmitry V. Levin]

On Thu, Dec 03, 2020 at 11:49:30PM +0300, Paul Wolneykien wrote:
[...]
>   Дополню ещё слова Виталия выше: EPERM --- это ошибка проверки ACL на
> предмет возможности commit, так? Если так, то нельзя её получать
> незаслуженно, то есть тогда, когда автор задания запускал его не с
> целью commit. В этом главное противоречие. Для проверки _потенциальной_
> возможности обновить пакет в репозитории существует команда acl show.

Есть ещё task run --dry-run, рекомендую.
Например, task run --dry-run --commit для задания в состоянии TESTED
проверит права и покажет, готово ли это задание для коммита.


-- 
ldv

Re: [devel] Q: Do not EPERM test-only tasks

[Sergey V Turchin]

On Thursday, 3 December 2020 21:14:02 MSK Vitaly Chikunov wrote:
> Hi,
> 
> Предлагаю test-only таски не переводить в состояние EPERM. Это позволит
> легко отличить в почте результат run --test-only от run --commit!
В теме же написано "[test-only]".

-- 
Regards, Sergey.

Re: [devel] Q: Do not EPERM test-only tasks

[Sergey V Turchin]

On Thursday, 3 December 2020 21:50:30 MSK Anton Farygin wrote:

[...]
> не показывать EPERM для заданий, у которых не может быть EPERM потому
> что они тестовые - эта идея отличная и, наверное, станет легче.
А мне не нравится. Тестовое задание должно быть точно таким же, как обычное, 
только тестовым. Сейчас оно так и есть -- в теме письма написано "test-only".

-- 
Regards, Sergey.

Re: [devel] Q: Do not EPERM test-only tasks

[Sergey V Turchin]

On Thursday, 3 December 2020 22:00:40 MSK Dmitry V wrote:

[...]
> Но если задание не прошло acl check, то оно явно не готово быть
> закоммиченным в репозиторий.  Если предлагается эту информацию скрыть,
> то как этим тогда пользоваться?
+1
Тест должен показывать всё без искажений. Пометка в теме есть.

-- 
Regards, Sergey.

Re: [devel] Q: Do not EPERM test-only tasks

[Sergey V Turchin]

On Thursday, 3 December 2020 23:03:42 MSK Vitaly Chikunov wrote:

[...]
> Запуская --test-only я не обязательно хочу получить acl check (и, как
> следствие, ошибку в нём), так как, скорее всего, я и не хотел коммитить
> это задание в репозиторий - это просто экспериментальная сборка на всех
> основных архитектурах, а не неудавшаяся попытка закоммитить.
Я считаю, что запускающий тестовой задание должен хотеть получить _всю_ 
информацию, почему его сборка не пройдёт commit.

> Если acl check обязателен и важен, то он может быть написан в логе, или
> как-то снижена его психологическая значимость с EPERM, допустим, через
> префикс "TEST-".
В письме есть достаточно инвормации, чтобы каждый отсортировал письма по 
любому принципу психологической значимости.

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

[...]

-- 
Regards, Sergey.

Re: [devel] Q: Do not EPERM test-only tasks

[Sergey V Turchin]

On Thursday, 3 December 2020 23:30:34 MSK Скрылевъ Малъ wrote:
>  
>  
> 03.12.2020, 21:30, "Vitaly Chikunov" <vt@altlinux.org>:
> 
> On Thu, Dec 03, 2020 at 09:26:34PM +0300, Dmitry V. Levin wrote:
> 
>  On Thu, Dec 03, 2020 at 09:14:02PM +0300, Vitaly Chikunov wrote:
>  > Hi,
>  >
>  > Предлагаю test-only таски не переводить в состояние EPERM. Это позволит
>  > легко отличить в почте результат run --test-only от run --commit!
>  
>  А в какое состояние тогда их переводить?
> 
> 
> Варианты: TESTED, TESTEPERM,
> 
> 
> например.
> CHECKED - состояние при вклбчённом --test-only, но до EPERM
> TESTED - состояние при вклбчённом --test-only, уже после EPERM
VERIFIED
DISCOVERED
до кучи, чтоб всех окончательно запутать. ;-)

-- 
Regards, Sergey.

Re: [devel] Q: ON_QA

[Dmitry V. Levin]

On Thu, Dec 03, 2020 at 09:50:30PM +0300, Anton Farygin wrote:
> On 03.12.2020 21:44, Vitaly Chikunov wrote:
> > On Thu, Dec 03, 2020 at 09:36:16PM +0300, Anton Farygin wrote:
> >> On 03.12.2020 21:30, Vitaly Chikunov wrote:
> >>> On Thu, Dec 03, 2020 at 09:26:34PM +0300, Dmitry V. Levin wrote:
> >>>> On Thu, Dec 03, 2020 at 09:14:02PM +0300, Vitaly Chikunov wrote:
> >>>>> Hi,
> >>>>>
> >>>>> Предлагаю test-only таски не переводить в состояние EPERM. Это позволит
> >>>>> легко отличить в почте результат run --test-only от run --commit!
> >>>> А в какое состояние тогда их переводить?
> >>> Варианты: TESTED, TESTEPERM,
> >> не надо использовать термин TESTED для заданий, которые не TESTED.
> > Я думаю, что не надо смешивать разные feature requests в один.
> 
> Да, ок. Давай этого медведя есть маленькими кусочками.
> 
> не показывать EPERM для заданий, у которых не может быть EPERM потому 
> что они тестовые - эта идея отличная и, наверное, станет легче.

Если стало легче, то я предлагаю завести новое состояние, например, ON_QA,
и придумать более подходящий workflow, чем тот, который сложился сейчас,
для тех репозиториев, в которых есть внешний QA.


-- 
ldv

Re: [devel] Q: ON_QA

[Vitaly Chikunov]

On Sat, Dec 05, 2020 at 07:29:22PM +0300, Dmitry V. Levin wrote:
> > не показывать EPERM для заданий, у которых не может быть EPERM потому 
> > что они тестовые - эта идея отличная и, наверное, станет легче.
> 
> Если стало легче, то я предлагаю завести новое состояние, например, ON_QA,
> и придумать более подходящий workflow, чем тот, который сложился сейчас,
> для тех репозиториев, в которых есть внешний QA.

Было бы хорошо если бы в будущем это было интегрируемо с автоматическими
внешними тестами (в стиле CI). То есть QA состояний может быть, в
теории, больше 1.

Re: [devel] Q: ON_QA

[Anton Farygin]

On 05.12.2020 20:18, Vitaly Chikunov wrote:
> On Sat, Dec 05, 2020 at 07:29:22PM +0300, Dmitry V. Levin wrote:
>>> не показывать EPERM для заданий, у которых не может быть EPERM потому
>>> что они тестовые - эта идея отличная и, наверное, станет легче.
>> Если стало легче, то я предлагаю завести новое состояние, например, ON_QA,
>> и придумать более подходящий workflow, чем тот, который сложился сейчас,
>> для тех репозиториев, в которых есть внешний QA.
> Было бы хорошо если бы в будущем это было интегрируемо с автоматическими
> внешними тестами (в стиле CI). То есть QA состояний может быть, в
> теории, больше 1.
>
ON_AUTOTEST сразу напрашивается, я тоже хотел предложить этот вариант.

С более подходящим workflow надо как следует подумать и посоветоваться. 
Тут лучше не спешить а постараться сделать в достаточной степени удобно 
для всех участников процесса.

Наверное, было бы здорово иметь возможность задействовать QA не только 
для заданий стабильных репозиториев, но и в каких-то редких случаях для 
заданий из Sisyphus (для примера - grub 2.02 -> 2.04).

Соответственно может быть сделать возможность отправлять задания на 
стадию проверки:

task <task number> goto <stage, QA or AUTOTEST for example>

при этом переход из EPERM в ON_QA и обратно для stable репозиториев 
можно осуществлять по факту approve/disapprove от групп @maint и @testers

Стадия ON_QA должна ещё сноситься при внесении любых изменений в задание.


может быть, по аналогии с [test-only] вешать на задание флаг [verifyed] 
и, в случае с Sisyphus - оставлять это в таком виде на усмотрения 
ментейнера, а в случае с stable репозиторием - коммитить, если такое 
задание не помечено как test-only.


Это мысли в слух, ни в коем случае не надо воспринимать это как готовое 
workflow.

Re: [devel] Q: ON_QA

[Новиков Сергей]

Добрый день.

05.12.2020 19:29, Dmitry V. Levin пишет:
> On Thu, Dec 03, 2020 at 09:50:30PM +0300, Anton Farygin wrote:
>> On 03.12.2020 21:44, Vitaly Chikunov wrote:
>>> On Thu, Dec 03, 2020 at 09:36:16PM +0300, Anton Farygin wrote:
>>>> On 03.12.2020 21:30, Vitaly Chikunov wrote:
>>>>> On Thu, Dec 03, 2020 at 09:26:34PM +0300, Dmitry V. Levin wrote:
>>>>>> On Thu, Dec 03, 2020 at 09:14:02PM +0300, Vitaly Chikunov wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> Предлагаю test-only таски не переводить в состояние EPERM. Это позволит
>>>>>>> легко отличить в почте результат run --test-only от run --commit!
>>>>>> А в какое состояние тогда их переводить?
>>>>> Варианты: TESTED, TESTEPERM,
>>>> не надо использовать термин TESTED для заданий, которые не TESTED.
>>> Я думаю, что не надо смешивать разные feature requests в один.
>> Да, ок. Давай этого медведя есть маленькими кусочками.
>>
>> не показывать EPERM для заданий, у которых не может быть EPERM потому
>> что они тестовые - эта идея отличная и, наверное, станет легче.
> Если стало легче, то я предлагаю завести новое состояние, например, ON_QA,
> и придумать более подходящий workflow, чем тот, который сложился сейчас,
> для тех репозиториев, в которых есть внешний QA.
Можно добавить следующие статусы:
1. ON_MAINT_REVIEW - таск появился в списке --needs-approval=maint
2. IN_QA_QUEUE - таск появился в списке --needs-approval=tester
3. ON_QA_REVIEW - QA взяли таск в работу.
4. READY_TO_COMMIT - получены апрувы от @maint и @tester
5. REJECTED_BY_MAINT - отклонен группой @maint
6. REJECTED_BY_QA - отклонен QA

Re: [devel] Q: ON_QA

[Michael Shigorin]

On Mon, Dec 07, 2020 at 01:55:35PM +0300, Новиков Сергей wrote:
> Можно добавить следующие статусы:

Кстати, разумно (надеюсь, реализуемо).

> 1. ON_MAINT_REVIEW - таск появился в списке --needs-approval=maint
> 2. IN_QA_QUEUE - таск появился в списке --needs-approval=tester
> 3. ON_QA_REVIEW - QA взяли таск в работу.
> 4. READY_TO_COMMIT - получены апрувы от @maint и @tester
> 5. REJECTED_BY_MAINT - отклонен группой @maint
> 6. REJECTED_BY_QA - отклонен QA

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [devel] Q: ON_QA

[Anton Farygin]

On 07.12.2020 14:01, Michael Shigorin wrote:
> On Mon, Dec 07, 2020 at 01:55:35PM +0300, Новиков Сергей wrote:
>> Можно добавить следующие статусы:
> Кстати, разумно (надеюсь, реализуемо).
>
>> 1. ON_MAINT_REVIEW - таск появился в списке --needs-approval=maint
>> 2. IN_QA_QUEUE - таск появился в списке --needs-approval=tester
>> 3. ON_QA_REVIEW - QA взяли таск в работу.
>> 4. READY_TO_COMMIT - получены апрувы от @maint и @tester
>> 5. REJECTED_BY_MAINT - отклонен группой @maint
>> 6. REJECTED_BY_QA - отклонен QA

Всё разумно, за исключением того, что смысла от группы @maint в режиме 
ON_MAINT_REVIEW пока особого нет.

Я бы предложил исключить эту стадию, оставив при этом возможность 
сделать REJECTED_BY_MAINT на любом этапе.

Re: [devel] Q: ON_QA

[Arseny Maslennikov]

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

On Mon, Dec 07, 2020 at 01:55:35PM +0300, Новиков Сергей wrote:
> Добрый день.
> 
> 05.12.2020 19:29, Dmitry V. Levin пишет:
> > On Thu, Dec 03, 2020 at 09:50:30PM +0300, Anton Farygin wrote:
> > > On 03.12.2020 21:44, Vitaly Chikunov wrote:
> > > > On Thu, Dec 03, 2020 at 09:36:16PM +0300, Anton Farygin wrote:
> > > > > On 03.12.2020 21:30, Vitaly Chikunov wrote:
> > > > > > On Thu, Dec 03, 2020 at 09:26:34PM +0300, Dmitry V. Levin wrote:
> > > > > > > On Thu, Dec 03, 2020 at 09:14:02PM +0300, Vitaly Chikunov wrote:
> > > > > > > > Hi,
> > > > > > > > 
> > > > > > > > Предлагаю test-only таски не переводить в состояние EPERM. Это позволит
> > > > > > > > легко отличить в почте результат run --test-only от run --commit!
> > > > > > > А в какое состояние тогда их переводить?
> > > > > > Варианты: TESTED, TESTEPERM,
> > > > > не надо использовать термин TESTED для заданий, которые не TESTED.
> > > > Я думаю, что не надо смешивать разные feature requests в один.
> > > Да, ок. Давай этого медведя есть маленькими кусочками.
> > > 
> > > не показывать EPERM для заданий, у которых не может быть EPERM потому
> > > что они тестовые - эта идея отличная и, наверное, станет легче.
> > Если стало легче, то я предлагаю завести новое состояние, например, ON_QA,
> > и придумать более подходящий workflow, чем тот, который сложился сейчас,
> > для тех репозиториев, в которых есть внешний QA.
> Можно добавить следующие статусы:
> 1. ON_MAINT_REVIEW - таск появился в списке --needs-approval=maint
> 2. IN_QA_QUEUE - таск появился в списке --needs-approval=tester
> 3. ON_QA_REVIEW - QA взяли таск в работу.
> 4. READY_TO_COMMIT - получены апрувы от @maint и @tester
> 5. REJECTED_BY_MAINT - отклонен группой @maint
> 6. REJECTED_BY_QA - отклонен QA

Я не то чтобы против того, чтобы эта метаинформация связывалась с заданием.
Но всё вышеперечисленное относится к отделам компании, дистрибутивам и
бранчам этой же компании, а girar — по крайней мере, задуман как —
инструмент сообщества и дистрибутивной платформы Альт, у пользователей
которого структура QA может и не соответствовать принятой в Базальт СПО.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [devel] Q: ON_QA

[Paul Wolneykien]

В Mon, 7 Dec 2020 14:01:55 +0300
Michael Shigorin <mike@altlinux.org> пишет:

> On Mon, Dec 07, 2020 at 01:55:35PM +0300, Новиков Сергей wrote:
> > Можно добавить следующие статусы:  
> 
> Кстати, разумно (надеюсь, реализуемо).
> 
> > 1. ON_MAINT_REVIEW - таск появился в списке --needs-approval=maint
> > 2. IN_QA_QUEUE - таск появился в списке --needs-approval=tester
> > 3. ON_QA_REVIEW - QA взяли таск в работу.
> > 4. READY_TO_COMMIT - получены апрувы от @maint и @tester
> > 5. REJECTED_BY_MAINT - отклонен группой @maint
> > 6. REJECTED_BY_QA - отклонен QA  
> 

  Только очень длинно --- нужно всё сократить до 5 букв (ДЗДРАБРЫ!).

  С другой стороны, а нужно ли вообще менять статус задания в процессе
работы QA, когда обработка задания сборочницей уже завершилась (а новая
ещё не начиналась)? Меняющийся статус может быть, но это должен быть
статус каких-то объектов QA, а не сборочных заданий.

Re: [devel] Q: ON_QA

[Sergey V Turchin]

On Monday, 7 December 2020 14:01:55 MSK Michael Shigorin wrote:
> On Mon, Dec 07, 2020 at 01:55:35PM +0300, Новиков Сергей wrote:
> > Можно добавить следующие статусы:
> Кстати, разумно (надеюсь, реализуемо).
> 
> > 1. ON_MAINT_REVIEW - таск появился в списке --needs-approval=maint
> > 2. IN_QA_QUEUE - таск появился в списке --needs-approval=tester
> > 3. ON_QA_REVIEW - QA взяли таск в работу.
> > 4. READY_TO_COMMIT - получены апрувы от @maint и @tester
> > 5. REJECTED_BY_MAINT - отклонен группой @maint
> > 6. REJECTED_BY_QA - отклонен QA
Желательно, чтобы ДЕЙСТВИЕ, МЕСТО И ПЕРСОНАЖ были в одном или схожем порядке.
Т.е., например
REVIEW_BY_MAINT
QUEUE_FOR_QA
REVIEW_BY_QA

-- 
Regards, Sergey.

Re: [devel] Q: ON_QA

[Anton Farygin]

On 07.12.2020 14:15, Arseny Maslennikov wrote:
> On Mon, Dec 07, 2020 at 01:55:35PM +0300, Новиков Сергей wrote:
>> Добрый день.
>>
>> 05.12.2020 19:29, Dmitry V. Levin пишет:
>>> On Thu, Dec 03, 2020 at 09:50:30PM +0300, Anton Farygin wrote:
>>>> On 03.12.2020 21:44, Vitaly Chikunov wrote:
>>>>> On Thu, Dec 03, 2020 at 09:36:16PM +0300, Anton Farygin wrote:
>>>>>> On 03.12.2020 21:30, Vitaly Chikunov wrote:
>>>>>>> On Thu, Dec 03, 2020 at 09:26:34PM +0300, Dmitry V. Levin wrote:
>>>>>>>> On Thu, Dec 03, 2020 at 09:14:02PM +0300, Vitaly Chikunov wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> Предлагаю test-only таски не переводить в состояние EPERM. Это позволит
>>>>>>>>> легко отличить в почте результат run --test-only от run --commit!
>>>>>>>> А в какое состояние тогда их переводить?
>>>>>>> Варианты: TESTED, TESTEPERM,
>>>>>> не надо использовать термин TESTED для заданий, которые не TESTED.
>>>>> Я думаю, что не надо смешивать разные feature requests в один.
>>>> Да, ок. Давай этого медведя есть маленькими кусочками.
>>>>
>>>> не показывать EPERM для заданий, у которых не может быть EPERM потому
>>>> что они тестовые - эта идея отличная и, наверное, станет легче.
>>> Если стало легче, то я предлагаю завести новое состояние, например, ON_QA,
>>> и придумать более подходящий workflow, чем тот, который сложился сейчас,
>>> для тех репозиториев, в которых есть внешний QA.
>> Можно добавить следующие статусы:
>> 1. ON_MAINT_REVIEW - таск появился в списке --needs-approval=maint
>> 2. IN_QA_QUEUE - таск появился в списке --needs-approval=tester
>> 3. ON_QA_REVIEW - QA взяли таск в работу.
>> 4. READY_TO_COMMIT - получены апрувы от @maint и @tester
>> 5. REJECTED_BY_MAINT - отклонен группой @maint
>> 6. REJECTED_BY_QA - отклонен QA
> Я не то чтобы против того, чтобы эта метаинформация связывалась с заданием.
> Но всё вышеперечисленное относится к отделам компании, дистрибутивам и
> бранчам этой же компании, а girar — по крайней мере, задуман как —
> инструмент сообщества и дистрибутивной платформы Альт, у пользователей
> которого структура QA может и не соответствовать принятой в Базальт СПО.

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

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

Re: [devel] Q: ON_QA

[Michael Shigorin]

On Mon, Dec 07, 2020 at 02:15:55PM +0300, Arseny Maslennikov wrote:
> Но всё вышеперечисленное относится к отделам компании,
> дистрибутивам и бранчам этой же компании, а girar — по крайней
> мере, задуман как — инструмент сообщества и дистрибутивной
> платформы Альт, у пользователей которого структура QA может
> и не соответствовать принятой в Базальт СПО.

Ну так и EPERM (вместе с acl) применять необязательно.

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [devel] Q: ON_QA

[Dmitry V. Levin]

On Mon, Dec 07, 2020 at 01:55:35PM +0300, Новиков Сергей wrote:
> 05.12.2020 19:29, Dmitry V. Levin пишет:
[...]
> > Если стало легче, то я предлагаю завести новое состояние, например, ON_QA,
> > и придумать более подходящий workflow, чем тот, который сложился сейчас,
> > для тех репозиториев, в которых есть внешний QA.
> Можно добавить следующие статусы:

Давайте всё-таки отличать атрибуты и состояния:

> 1. ON_MAINT_REVIEW - таск появился в списке --needs-approval=maint

Мне кажется, что это классический EPERM.

> 2. IN_QA_QUEUE - таск появился в списке --needs-approval=tester
> 3. ON_QA_REVIEW - QA взяли таск в работу.

С точки зрения сборочницы эти состояния (ожидание QA и собственно QA)
неотличимы, поскольку происходят снаружи.  Если бы сборочница обслуживала
очередь QA, тогда разные состояния были бы естественны, а так непонятно,
в чём разница, помимо атрибута, не влияющего ни на что, кроме внешнего
вида задания.

Например, если бы сборочница обслуживала какую-то очередь CI,
то можно было бы предложить состояния вроде AWAITING_CI и ON_CI.

> 4. READY_TO_COMMIT - получены апрувы от @maint и @tester

На мой взгляд, это атрибут, а не состояние.  Состояний у задания с этим
атрибутом может быть несколько: PENDING, COMMITTING, а также AWAITING,
BUILDING, и т.д.

> 5. REJECTED_BY_MAINT - отклонен группой @maint

Мне кажется, что это классический EPERM.
Я пока не вижу, чем ON_MAINT_REVIEW и REJECTED_BY_MAINT отличаются как
состояния (т.е. чем отличаются графы переходов из этих состояний).

> 6. REJECTED_BY_QA - отклонен QA

Это состояние задания я тоже пока не понимаю.
В какие другие состояния возможен переход из этого состояния?


-- 
ldv

Re: [devel] Q: ON_QA

[Новиков Сергей]

08.12.2020 20:10, Dmitry V. Levin пишет:
> On Mon, Dec 07, 2020 at 01:55:35PM +0300, Новиков Сергей wrote:
>> 05.12.2020 19:29, Dmitry V. Levin пишет:
> [...]
>>> Если стало легче, то я предлагаю завести новое состояние, например, ON_QA,
>>> и придумать более подходящий workflow, чем тот, который сложился сейчас,
>>> для тех репозиториев, в которых есть внешний QA.
>> Можно добавить следующие статусы:
> Давайте всё-таки отличать атрибуты и состояния:
>
>> 1. ON_MAINT_REVIEW - таск появился в списке --needs-approval=maint
> Мне кажется, что это классический EPERM.
>
>> 2. IN_QA_QUEUE - таск появился в списке --needs-approval=tester
>> 3. ON_QA_REVIEW - QA взяли таск в работу.
> С точки зрения сборочницы эти состояния (ожидание QA и собственно QA)
> неотличимы, поскольку происходят снаружи.  Если бы сборочница обслуживала
> очередь QA, тогда разные состояния были бы естественны, а так непонятно,
> в чём разница, помимо атрибута, не влияющего ни на что, кроме внешнего
> вида задания.
>
> Например, если бы сборочница обслуживала какую-то очередь CI,
> то можно было бы предложить состояния вроде AWAITING_CI и ON_CI.
>
>> 4. READY_TO_COMMIT - получены апрувы от @maint и @tester
> На мой взгляд, это атрибут, а не состояние.  Состояний у задания с этим
> атрибутом может быть несколько: PENDING, COMMITTING, а также AWAITING,
> BUILDING, и т.д.
>
>> 5. REJECTED_BY_MAINT - отклонен группой @maint
> Мне кажется, что это классический EPERM.
> Я пока не вижу, чем ON_MAINT_REVIEW и REJECTED_BY_MAINT отличаются как
> состояния (т.е. чем отличаются графы переходов из этих состояний).
Предложенные мной статусы/атрибуты направлены на то, чтобы
заинтересованным людям легко можно было определить текущий
статус собранного в стабильный бранч задания.

Так как в данный момент мейнтейнер, собирающий в стабильный бранч,
часто не понимает какой статус у задания и на каком этапе проверки оно 
находится,
он видит только статус EPERM, хотя задание может быть уже отклонено 
группой @maint или группой @tester.
>> 6. REJECTED_BY_QA - отклонен QA
> Это состояние задания я тоже пока не понимаю.
> В какие другие состояния возможен переход из этого состояния?
>
Получается это не состояние, а атрибут.
С данным атрибутом, возможен переход в любые другие состояния.


-- 
Новиков Сергей
ООО «Базальт СПО»

Re: [devel] Q: ON_QA

[Alexey V. Vissarionov]

On 2020-12-09 11:50:37 +0300, Новиков Сергей wrote:

 >>> Можно добавить следующие статусы:
 >> Давайте всё-таки отличать атрибуты и состояния:
 >>> 5. REJECTED_BY_MAINT - отклонен группой @maint
 >> Мне кажется, что это классический EPERM.
 >> Я пока не вижу, чем ON_MAINT_REVIEW и REJECTED_BY_MAINT
 >> отличаются как состояния (т.е. чем отличаются графы
 >> переходов из этих состояний).
 > Предложенные мной статусы/атрибуты направлены на то, чтобы
 > заинтересованным людям легко можно было определить текущий
 > статус собранного в стабильный бранч задания.

А велика ли разница? Ну, разве что EPERM можно разделить на
"awaiting approval" и "rejected" - в первом случае действия
от мейнтейнера еще не было, а во втором мейнтейнер уже сказал
свое веское.

 > Так как в данный момент мейнтейнер, собирающий в стабильный
 > бранч, часто не понимает какой статус у задания и на каком
 > этапе проверки оно находится, он видит только статус EPERM,
 > хотя задание может быть уже отклонено группой @maint или
 > группой @tester.

Привязка к текущей бизнес-логике конторы => неуниверсально =>
не нужно.

 >>> 6. REJECTED_BY_QA - отклонен QA
 >> Это состояние задания я тоже пока не понимаю.
 >> В какие другие состояния возможен переход из этого состояния?
 > Получается это не состояние, а атрибут. С данным атрибутом,
 > возможен переход в любые другие состояния.

Ну и на зачем он тогда такой нужен? Если по уму, то rejected -
это частный случай failed.


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net