[devel] Q: ON_QA

Anton Farygin rider на basealt.ru
Сб Дек 5 21:46:55 MSK 2020


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.



Подробная информация о списке рассылки Devel