[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