Я извиняюсь за оффтопик, но в форме заведения нового бага нет продукта Bugzilla.
Откройте продукт для приема пожеланий его пользователей, пожалуйста. Их накопилось.

Как только на сайте ALT Linux появится информация о новом дистрибутиве, так я 
сразу добавлю новый продукт в багзиллу.

Продукт Багзилла был закрыт потому, что у разработчиков и пользователей случался
head panic при виде "ALT Linux Bugzilla". В этот продукт вешались баги об
ошибках в ReiserFS, konqueror и т.д.

(In reply to comment #2)
> Продукт Багзилла был закрыт потому, что у разработчиков и пользователей случался
> head panic при виде "ALT Linux Bugzilla". В этот продукт вешались баги об
> ошибках в ReiserFS, konqueror и т.д.

Это не повод отрубать его напрочь. Ставьте RESOLVED INVALID с подсказкой, как
правильно сделать (по-моему, была в Bugzilla такая фича, как шаблонные
комментарии). Еще hint: добиться того, чтобы Bugzilla не была первым продуктом в
списке.

P.S. Что по поводу идеи упрятать варианты дистрибутивов в "версию" вместо
"продукта"?

IMHO "упрятать" -- здраво.

(In reply to comment #3)
> Это не повод отрубать его напрочь. Ставьте RESOLVED INVALID с подсказкой, как
> правильно сделать (по-моему, была в Bugzilla такая фича, как шаблонные
> комментарии). Еще hint: добиться того, чтобы Bugzilla не была первым продуктом в
> списке.

Для меня повод.

> P.S. Что по поводу идеи упрятать варианты дистрибутивов в "версию" вместо
> "продукта"?

Объясните подробнее. В версию чего ? у компонентов нет версий. 

(In reply to comment #5)
> > Это не повод отрубать его напрочь.
> Для меня повод.

Опять у нас инфраструктура развернута лицом к обслуживающему персоналу, а не к
пользователям :-/

> > P.S. Что по поводу идеи упрятать варианты дистрибутивов в "версию" вместо
> > "продукта"?
> 
> Объясните подробнее. В версию чего ? у компонентов нет версий. 

Поле Version в багах "продуктов", обозначающих дистрибутивы, сейчас не используется.
Поскольку баги обычно заводятся скорее на пакет, чем на конкретный дистрибутив
(и могут воспроизводиться одновременно в Sisyphus, Master и пр.), логичнее слить
"продукты" Bugzilla, отвечающие за варианты дистрибутива, и перенести
идентификацию варианта в поле Version: например, "Master 2.4".

Предлагаю вам реализовать, предлагаемую структуру. И развернуть инфраструктуру в
нужную сторону нужным местом. Если мантейнерам понравится модель, то мы перейдем
на неё полностью.
Когда я делал эту структуру, то считал что она лучше предыдущей... возможно
настало время переделать и её.

(In reply to comment #7)
> Предлагаю вам реализовать, предлагаемую структуру.

Я не знаю структуры базы данных Bugzilla.
Но лезть в нее нужно примерно так, только переформулировав с человеческого на SQL:
1. Для багов, у которых продукт "ALT Linux Sisyphus" выставить в поле версии
"Sisyphus"; то же самое для "Master 2.4".
2. Проставить всем багам, у которых продукт Sisyphus или Master, единый продукт
"ALT Linux". Можно реюзнуть один из существующих идентификаторов продукта и
изменить его имя впоследствии.
3. Соответственно обновить все связанные таблицы, если таковые есть.

Лучше, разумеется, сначала потренироваться на копии базы.

> И развернуть инфраструктуру в
> нужную сторону нужным местом.

Если вы о возвращении пункта Bugzilla в меню продуктов, возможно, дело в
формулировке. Назовите продукт "Metabugs" и никто не будет принимать его за
место, куда нужно постить все баги. Или напишите страшенный текст большими
буквами в описании продукта: "%^@, как вы задолбали постить сюда баги ALT Linux,
неужели непонятно, ^&#$..."

(In reply to comment #8)
> Я не знаю структуры базы данных Bugzilla.

Я знаю как она устроена. Вы думаете почему я предложил вам это реализовать ?! :)

> Но лезть в нее нужно примерно так, только переформулировав с человеческого на SQL:

Для реализации вашего предложения нужно серьёзно переделывать интерфейс для
добавления нового бага и не только.
Из опытов я знаю, что чем меньше элементов, тем лучше. Например в redhat до
версии дистрибутрива при добавлении новой баги можно добраться только через
эксперт мод. А в mozilla.org вообще нет этого поля при посте нового бага.
Конечно это не аргумент, но после экспериментов я убрал часть полей из нашей
формы добавления багов т.к. (например) пользователи упорно добавляли себя в СС к
своей же баге ... хотя там было оприсано зачем нужно это поле.
Это я к тому что все будут забывать выбирать версию. Чтобы такого не было
придется делать добавление бага в три этапа: 1 - выбор продукта (в вашем случае
"ALT Linux"), 2 - выбор версии (например "Master 2.4"), а уж потом компонент (по
нашему это пакет). Или как-то ещё ... вообщем нужно думать чтобы совершенно
тупой человек мог повесить баг без ошибок.
Сейчас интерфейс конечно не фонтан, но ...

Обещаю об этом подумать когда буду внедрять новую версию багзиллы. Но реализацию
не обещаю.

> Если вы о возвращении пункта Bugzilla в меню продуктов, возможно, дело в
> формулировке. Назовите продукт "Metabugs" и никто не будет принимать его за
> место, куда нужно постить все баги. Или напишите страшенный текст большими
> буквами в описании продукта: "%^@, как вы задолбали постить сюда баги ALT Linux,
> неужели непонятно, ^&#$..."

Я пробовал несколько разных описаний, но ни одно не помогло. Пользователи просто
 их не читают ... только заголовки (теперь я это точно знаю). Вы думаете я из
вредности убрал этот продукт ?! Из того что вешалось на этот продукт две трети
были ошибочные баги. И мне приходилось их развешивать вручную. И всё это ради
2-3 фичареквестов на "ALT Linux Bugzilla" ?!.

(In reply to comment #9)
> (In reply to comment #8)
> > Я не знаю структуры базы данных Bugzilla.
> 
> Я знаю как она устроена. Вы думаете почему я предложил вам это реализовать ?! :)

Присылайте схему базы, я посмотрю.

> > Но лезть в нее нужно примерно так, только переформулировав с человеческого
на SQL:
> 
> Для реализации вашего предложения нужно серьёзно переделывать интерфейс для
> добавления нового бага и не только.

Сейчас там уже есть поле "Version", установленное в вечный "unstable".
Зачем оно там? И почему, чтобы его оживить, нужно серьезно переделывать интерфейс?

> Это я к тому что все будут забывать выбирать версию. Чтобы такого не было
> придется делать добавление бага в три этапа: 1 - выбор продукта (в вашем случае
> "ALT Linux"), 2 - выбор версии (например "Master 2.4"), а уж потом компонент (по
> нашему это пакет). Или как-то ещё ... вообщем нужно думать чтобы совершенно
> тупой человек мог повесить баг без ошибок.

Лучше пусть пользователь не выберет правильную версию, чем баги пакета
размываются между разными продуктами, так что искать, не существует ли уже баг
на конкретный пакет, можно только в Advanced Search.
Версия дистрибутива а) не важна в большом количестве случаев; б) в случае нужды
может быть уточнена сопроводителем.
По-моему, типичная ошибка назначения приоритетов в UI.

> Я пробовал несколько разных описаний, но ни одно не помогло. Пользователи просто
>  их не читают ... только заголовки (теперь я это точно знаю). Вы думаете я из
> вредности убрал этот продукт ?! Из того что вешалось на этот продукт две трети
> были ошибочные баги.

Я же написал, назовите этот продукт "Metabugs" и пользователи не будут принимать
его за место для багов ALT Linux.

> И мне приходилось их развешивать вручную.

Не нужно развешивать, ставьте INVALID. Пусть сами исправляют.

> И всё это ради
> 2-3 фичареквестов на "ALT Linux Bugzilla" ?!.

Все потому, что годами, например, отсутствует состояние NEEDINFO, что иногда нужно.

Подумав над вашим предложением я понял что так делать нельзя. Вы смешиваете
разные сущности - пакеты в дистрибутивах. Например пакет mozilla в мастере,
компакте и сизифе это разный пакет. У него как минимум разные мантейнеры. Но
могут быть разные QA и описания. Формально говоря это совершенно разные пакеты с
разными проблемами. В разных дистрибутивах пакет может присутствовать или
отсутствовать (например gcc3.3 в сизифе уже нет, но в копакте ещё есть).

Сейчас поле "Версия" в продукте имеет чисто информационную функцию, а баги
вешаются на связку Продукт+Компонент. 

Чтобы пойти по предлагаемому пути т.е. сделать чтобы баги вешались на
Продукт+Версия продукта+Компонент, нужно будет добавлять зависимость на версию
продукта в большое количество мест ... а именно везде где есть зависимость на
компонент и продукт. Как вы понимаете внесение таких изменений это гиганская
работа по серьёзному изменению архитектуры багзиллы. 

reassign

С какой богатой историей баг, однако :)

В багзилле нужен нормальный багтракинг для релизов/бранчей, я займусь 
обсустройством. Разгребанием багов займётся техподдержка и (to be created) QA 
ООО.

Не, мы займёмся навешиванием багов ;) разгребание - это к разработке.


(In reply to comment #13)
> 
>  Разгребанием багов займётся техподдержка и (to be created) QA 
> ООО.
> 

>разгребание - это к разработке.

К разработке - фиксить, а вот следить, чтобы всё было по местам развешано - это 
к вам.

Итак, de facto продукты для дистрибутивов в багзилле появились до апгрейда 
багзиллы, и баги по ним легли на соответствующих RM.

Тонкую настройку (группировку продуктов в категории etc) можно производить уже 
после апгрейда.