Re: [devel] repocop+sisyphus_check

["Evgeny Sinelnikov" <sin@altlinux.ru>]

9 августа 2008 г. 1:09 пользователь Igor Vlasenko
<vlasenko@imath.kiev.ua> написал:
> On Fri, Aug 08, 2008 at 11:50:32PM +0300, Igor Vlasenko wrote:
>> Там место только для таких ошибок, которые нужно исправлять.
>
> Кроме того, если дополнительно выделить экспериментальные тесты,
> то у майнтайнеров будет период адаптации к новшествам.
> а также время что-то подкорректировать в самих тестах.
>
> Например, будет возможно такое полиси:
> новый тест sisyphus_check должен будет сначала 2 недели ругать
> пакеты через sisyphus.ru,
> и только потом, если не будет возражений, будет включаться в incoming.
>


Хотел бы пояснить официальное мнение на этот счёт. Я некоторое время
действительно провёл в попытках решить этот вопрос для себя только
задача у меня ставилась иначе, чем запускать любые тесты.

Тут смешалось две задачи... Проверка пакетов на удовлетворение
заданным критериям с целью выявить и обозначить потенциальные проблемы
(repocop) и выполнить проверку на удовлетворение policy по прохождению
пакетов в Сизиф (sisyphus_check). Выделение не-полиси-специфичной
части более подходит как решение поднимаемой проблемы. Для этого тоже
было предложено решение в процессе обсуждения упомянутого #15376.
Решение состояло в том, чтобы вынести базовую утилиту проверки в некий
rpm-check. Пользуясь которым, можно сделать любую программу проверки.
sisyphus_check, как утилита проверки sisyphus policy, является в такой
схеме, одной из программ использующих данный механизм. repocop
получается второй... Мне же интересен был третий вариант, который бы
не просто мог проверять, но и мог бы быть использован в hasher, взамен
стандартной политики, требующей, например, чтобы у сборщика был email
в домене altlinux.org или соотвествующий gpg-ключ и подпись - мне
нужны были совместно новый, дополнительный домен и новый,
дополнительный набор ключей...

В текущем положении дел назрела действительная возможность к
реализации описанного выше решения. Готов поучаствовать в его
реализации и развитии. К сожалению, я не особый ценитель
программирования на bash или Perl и, самостоятельно, я скорее готов
всё переписать на python. Но осознавая, что не всех это устроит. С
технической точки зрения это ещё и дополнительные зависимости в
сборчной среде... В общем архитектуру на bash я придумать конечно
могу, но боюсь, что кто-то, кто не так испорчен ООП языками, может
сделать это лучше. С другой стороны, я готов обсуждать и участвовать в
любых вопросах в рамках этой задачи.

-- 
Sin (Sinelnikov Evgeny)