Bug 15467 - binary <-> source package bug navigation
Summary: binary <-> source package bug navigation
Status: CLOSED WONTFIX
Alias: None
Product: Infrastructure
Classification: Infrastructure
Component: bugzilla.altlinux.org (show other bugs)
Version: unspecified
Hardware: all Linux
: P2 enhancement
Assignee: Олег Соловьев
QA Contact: Mikhail Gusarov
URL:
Keywords:
: 15923 (view as bug list)
Depends on: 16711
Blocks: 18644
  Show dependency tree
 
Reported: 2008-04-25 20:58 MSD by Mikhail Gusarov
Modified: 2021-07-01 13:32 MSK (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mikhail Gusarov 2008-04-25 20:58:23 MSD
Для увеличения юзабельности компонента загоняния багов, стоит предусмотреть 
возможность резолвинга binary пакетов в соответствующие source-пакеты.
Comment 1 Mikhail Gusarov 2008-04-25 21:07:13 MSD
Что-то я прогнал. В багзилле и так бинарные пакеты.
Comment 2 Vladimir V. Kamarzin 2008-04-28 11:53:04 MSD
Э, а я подумал что ты хочешь чтобы бинарных компонентов не было, а только
source, т.е. чтобы баги на binary-компоненты вешались не на них а на тот
source-компонент, из которого собирается binary.
Comment 3 Mikhail Gusarov 2008-04-28 12:14:52 MSD
Нет, не хочу. А надо? В debian, в принципе, можно видеть баги как на бинарные 
пакеты, так и на source, из которых они собираются.
Comment 4 Vladimir V. Kamarzin 2008-04-28 12:39:03 MSD
Да вроде не надо.

Разве что было бы полезно иметь возможность легко найти все баги на подпакетах
source-пакета xxx. substring/regexp в поиске тут не совсем канает, т.к. названия
подпакетов вовсе не обязательно содержат в себе xxx.
Comment 5 Mikhail Gusarov 2008-04-28 12:43:15 MSD
Ок.
Comment 6 Mikhail Gusarov 2008-12-10 17:08:22 MSK
В 3.2
Comment 7 Vitaly Fedrushkov 2008-12-11 06:48:32 MSK
Все зависит от того, на что реально назначаются ответственные: на source или на binary.  Этот объект и должен стать компонентом, а на оставшийся создать custom field.  Если есть таблица перехода, одно поле вычислять из другого на лету.

Это даст возможность вести поиск, отчетность и т.п. в разрезе того и другого.
Comment 8 Mikhail Gusarov 2008-12-11 08:11:04 MSK
И правда: компонентом должен быть source package, custom field - binary package. При создании багов нужен будет кастомный интерфейс для выбора компонента, но это не смертельно.
Comment 9 Vitaly Fedrushkov 2008-12-11 09:20:14 MSK
Проблема будет если отношение между ними не один-ко-многим.

Если список известен статически, его можно даже не тащить в Bugzilla.  Надо лишь заполнить список выбора для _текстового_ поля custom field.  См. идею тут:

https://doctor.mozilla.org/?action=edit&file=bugzilla-org/src/installation-list/index.html
Comment 10 Mikhail Gusarov 2008-12-11 09:58:17 MSK
Внутри одного продукта отношение всегда один-к-многим.

Спасибо за ссылочку, подумаю. А custom field ведь глобален, а не per-product? Придётся тогда вешать тэги "этот продукт - про репозиторий / это продукт - не про репозиторий", и менять GUI.

Впрочем, для репозиториев и так GUI слегка адаптировать не помешает.
Comment 11 Mikhail Gusarov 2008-12-11 10:00:35 MSK
Впрочем, понял, зачем нужен список в Bugzilla: чтобы можно было этот custom field нормально редактировать: в виде combobox при перевешивании на другой binary package внутри одного source package, и для autocompletion при перевешивании на другой source package.

Тут ещё много разного геморроя может открыться: скажем, при перемещении багов между продуктами, и при работе с пакетами, у которых ровно один бинарный пакет собирается из source - в этом случае жестоко заставлять выбирать пользователя ещё и бинарный.
Comment 12 Mikhail Gusarov 2009-04-04 02:03:00 MSD
*** Bug 15923 has been marked as a duplicate of this bug. ***
Comment 13 Олег Соловьев 2021-07-01 12:18:51 MSK
А с этим что?
Comment 14 Anton Farygin 2021-07-01 13:32:51 MSK
я думаю, что в этом смысле лучше ничего не менять. Примерно это же показывает обсуждение от 2008 года.