Проблема
bugzilla не воспринимается разработчиками Сизифа, как авторитативный источник информации о всех задачах, связанных с Сизифом.
Анализ
Bugzilla не совсем удобна для реализации issue tracking'а в пределах репозитория пакетов, ибо изначально точилась под другие задачи, поэтому изобретаются ad-hoc средства организации тасков. Например: Mikhail Gusarov / Shared Libraries Analysis?. Необходимо эту порочную практику искоренить, ибо она ведёт к нехорошим последствиям:
- Фрагментация информации о состоянии репозитория. По issue tracker'у непонятно, в каком состоянии находится каждый конкретный компонент: фатально сломан, из-за чего багов не пишут, или превосходен, из-за чего багов опять-таки не пишут.
- Невозможность написания роботов для управления внешними сервисами. К примеру, в Debian робот не пропускает пакет в Testing, если на нём висят открытые RC (grave, serious) баги. В случае, когда информация в issue tracker'е не отражает полной картины, робот будет работать некорректно.
Первая проблема затрудняет работу над решениями на основе Сизифа, вторая – повседневную работу над репозиториями.
Задачи, не связанные с пакетами Сизифа непосредственно, в issue tracker'е на данный момент вообще не отражаются. Это фрагментирует информацию о состоянии репозитория, некоторую часть из неё делает эффективно приватной, и ухудшает возможности по мониторингу состояния репозитория в целом.
План исправления ситуации
Собранные жалобы
- Нет списка пакетов и других компонентов в интерфейсе. Традиционный combobox компонентов ужасен, ибо предназначался только для проектов, где количество компонентов не превышает нескольких десятков, а в Сизифе весит мегабайты HTML-я. Решения: посмотреть на багзиллы Red Hat?, Su SE?, нарисовать свой список, динамически подгружающий компоненты по мере надобности.
- Поле 'CC' не появляется на некоторых страницах, связанных с манипуляцией багом (скажем, при аплоаде attach'а).
- При изменении каких-либо полей в баге, это не отражается в комментарии, но дублируется почтой. В результате либо в баглоге не видно изменений, происходивших с багом, либо в e-mail-рассылке дублируется информация о том, что происходило с багом. Можно дописать функциональность, дублирующую шапку из почтовой рассылки в комментарии.