Bug 44099

Summary: Add more useful Status options
Product: Infrastructure Reporter: Vitaly Chikunov <vt>
Component: bugzilla.altlinux.orgAssignee: Олег Соловьев <mcpain>
Status: NEW --- QA Contact: Andrey Cherepanov <cas>
Severity: normal    
Priority: P5 CC: ldv, rider, snowmix, snowmix, zerg
Version: unspecified   
Hardware: x86   
OS: Linux   

Description Vitaly Chikunov 2022-10-20 20:42:20 MSK
Может быть стоит добавить больше полезных статусов у багов[1]. Пример какие есть в других багзиллах:
  https://bugzilla.redhat.com/page.cgi?id=fields.html#bug_status
  https://bugzilla.opensuse.org/page.cgi?id=status_resolution_matrix.html

- В частности, для Open багов не помешал бы статус CONFIRMED - это бы значило что наличие бага подтверждено.
- Так же ASSIGNED не означает, что работа ведется, так что может стоит добавить аналог IN_PROGRESS / ON_DEV.
- В закрытые баги статус UPSTREAM.

[1] https://bugzilla.altlinux.org/page.cgi?id=fields.html#bug_status
Comment 1 Anton Farygin 2022-10-20 21:03:38 MSK
Кстати да, поддерживаю это предложение.

Особенно с учётом того, что у нас грядут некоторые изменения по разгребанию багов по stable непозиториям и статус UNCONFIRMED будет использоваться (вместо NEW).
Comment 2 Sergey V Turchin 2022-10-24 14:23:38 MSK
IMHO если расширять, то минимально, чтоб не наплодить статусов, которые малопонятны простым пользователям. Они и так боятся.
Comment 3 Олег Соловьев 2022-10-25 10:52:48 MSK
(In reply to Anton Farygin from comment #1)
> Кстати да, поддерживаю это предложение.
> 
> Особенно с учётом того, что у нас грядут некоторые изменения по разгребанию
> багов по stable непозиториям и статус UNCONFIRMED будет использоваться
> (вместо NEW).

раз "вместо", то лучше NEW не трогать?

NEW -> CONFIRMED -> ASSIGNED -> IN_PROGRESS -> RESOLVED -> CLOSED
Comment 4 Олег Соловьев 2022-10-25 11:02:26 MSK
И что будут означать RESOLVED FIXED и RESOLVED UPSTREAM?

Это зависит от того, кто исправил багу?
Или RESOLVED UPSTREAM будет означать, что бага исправлена нами, но изменения вместо Сизифа отправлены в апстрим и ментейнер ждёт merge в стабильный бранч, чтобы собрать из очередного релиза (я часто так делаю со своими исправлениями в KDE, но иногда оно требуется "прямщаз" и я прикладываю его отдельным патчем)?

И что делать с багами IN_PROGRESS? Никто не будет гарантировать что IN_PROGRESS будет находиться в "висячем" состоянии как ASSIGNED.
Вместо этого можно сбрасывать ASSIGNED обратно в NEW через некоторое время после бездействия assignee.
Comment 5 Sergey V Turchin 2022-10-25 11:03:48 MSK
(Ответ для Олег Соловьев на комментарий #3)
> > UNCONFIRMED будет использоваться (вместо NEW).
> раз "вместо", то лучше NEW не трогать?
UNCONFIRMED ещё и менее понятное.
Comment 6 Anton Farygin 2022-10-25 11:17:19 MSK
с UNCONFIRMED всё просто:
по новому регламенту ошибка в stable ветках будет сначала вешаться на qateam и ими подтверждаться и уже потом перевешиваться на исполнителя или ментейнера.

Собственно статус UNCONFIRMED будет в этот момент.
Comment 7 Олег Соловьев 2022-10-25 11:33:56 MSK
(In reply to Anton Farygin from comment #6)
> с UNCONFIRMED всё просто:
> по новому регламенту ошибка в stable ветках будет сначала вешаться на qateam
> и ими подтверждаться и уже потом перевешиваться на исполнителя или
> ментейнера.
> 
> Собственно статус UNCONFIRMED будет в этот момент.

Это заметят пользователи и начнут задавать вопросы.

Предлагаю: 

> Пользователь вешает баг
< Статус бага NEW как и раньше, исполнитель - qa

> QA подтверждает наличие бага
< NEW -> CONFIRMED, assignee qa -> maintainer

Изменение будет прозрачно для пользователей (как было NEW так и осталось при заведении бага).
Считаю, что если начальное состояние по каким-то причинам станет другим -- будут вопросы, а документацию читают не только лишь все.
Comment 8 Anton Farygin 2022-10-25 11:43:50 MSK
А что тогда будет делать статус ASSIGNED ?
Comment 9 Олег Соловьев 2022-10-25 11:50:00 MSK
(In reply to Anton Farygin from comment #8)
> А что тогда будет делать статус ASSIGNED ?

То же, что и сейчас: насколько я знаю, это понимается как "взято в работу"
Comment 10 Олег Соловьев 2022-10-25 11:54:24 MSK
PS судя по нашей же вики, UNCONFIRMED был выброшен ещё в далеком 2008 году, но документацию в соответствие с этим никто не приводил: https://www.altlinux.org/BugTracking/BugzillaMiniHowto

Отсюда и путаница -- статус отсутствует в базе, им давно никто не пользуется, но он почему-то ещё задокументирован
Comment 11 Олег Соловьев 2022-10-25 11:59:44 MSK
Пока что я понимаю workflow так:

NEW         - багу только только завели, никто её не подтверждал
CONFIRMED   - багу подтвердил либо ментейнер, либо QA
ASSIGNED    - бага в работе

ИЛИ

ASSIGNED    - ментейнер знает про багу и добавил её в очередь
IN_PROGRESS - ментейнер работает над багой / исправление готово, ждёт одобрения QA
Comment 12 Sergey V Turchin 2022-10-25 12:06:15 MSK
(Ответ для Олег Соловьев на комментарий #11)
> IN_PROGRESS - ментейнер работает над багой / исправление готово, ждёт
> одобрения QA
По идее, это 2 разных статуса.
Comment 13 Vitaly Chikunov 2022-10-25 15:58:59 MSK
> NEW -> CONFIRMED -> ASSIGNED -> IN_PROGRESS -> RESOLVED -> CLOSED

1. Путает наличие RESOLVED и CLOSED, которые навскидку не понятно чем отличаются.
Скорее всего нужно оставить только 1 так как у нас в Сизифе нет QA для этих багов. Наше описание: "RESOLVED A resolution has been performed, and it is awaiting verification by QA." Если нужно чтоб было QA, то лучше сделать (как у Redhat) явный статус ON_QA. (Так как слово RESOLVED не подразумевает QA, а подразумевает завершение.) По мне так лучше просто убрать CLOSED.

2. Resolution UPSTREAM - означает что баг перенаправлен в апстрим и фикс ждать оттуда, он не означает что баг уже исправлен, а означает что мы им не занимаемся здесь, как WONTFIX - но он не заброшен. Было бы ещё лучше, для установки UPSTREAM обязательно заполнять поле со ссылкой на апстрим багтрекер или обсуждение в апстрим рассылке куда перенаправлен репорт.

У Suse: UPSTREAM The responsibility for the bug lies upstream. NOTE: In TAG practice, its meaning varies by team, but commonly means that this problem is actually tracked outside Bugzilla.
У Redhat: UPSTREAM The problem described has been filed in an upstream bug tracker or reported to the upstream mailing list. [...] Там есть еще длинное объяснение зачем это надо.

3. NEW я считаю надо оставить -- это понятный статус. Пользователь завел баг и дальше мы должны его рассортировать, где только что заведенный баг - NEW.

Замена NEW на UNCONFIRMED не слишком удачна так как не все баги надо подтверждать, да и не всё подтвердишь - это излишняя моральная ответственность на обработчика багов. Маинтайнер может сразу поставить себе ASSIGNED/IN_PROGRESS.
CONFIRMED нужно до назначения, чтоб подтвердить качество багрепорта, а пользователь понимает, что его не игнорируют.

> по новому регламенту ошибка в stable ветках будет сначала вешаться на qateam и ими подтверждаться и уже потом перевешиваться на исполнителя или ментейнера.

Если это только для stable, то тут замена NEW на UNCONFIRMED смеет смысл. Но все равно можно остаться и на NEW, как привычном статусе, но для stable он будет означать ещё обработку QA.

> И что делать с багами IN_PROGRESS? Никто не будет гарантировать что IN_PROGRESS будет находиться в "висячем" состоянии как ASSIGNED.

4. Да с ASSIGNED проблема. По предложенной схеме выходит что это лишний статус.

ASSIGNED - менеджерский статус - значит найден ответственный, который должен решить что делать дальше - над багом надо работать, или закрыть, или перенаправить.

Но, это используется не как "ответственный" (потому что "ответственный" Assignee у нас и так всегда есть), а как конечный исполнитель. Так что по смыслу, это то же самое что и "в работе", только двусмысленнее.

Видимо поэтому у Сусе нет ASSIGNED, а только IN_PROGRESS, а у Редхат описание этих статусов одинаковое:

  ASSIGNED
    This bug report is being worked on by the Assigned Engineer. Use of this state is optional.
  ON_DEV
    This bug report is being worked on by the Assigned Engineer. Use of this state is optional.

5.
> NEW         - багу только только завели, никто её не подтверждал
> CONFIRMED   - багу подтвердил либо ментейнер, либо QA

Багу подтвердил кто-либо компетентный. Как правило не маинтайнер.

> ASSIGNED    - бага в работе
> 
> ИЛИ
> 
> ASSIGNED    - ментейнер знает про багу и добавил её в очередь
> IN_PROGRESS - ментейнер работает над багой / исправление готово, ждёт одобрения QA

Эти статусы можно различить - один менеджерский а другой разработческий.
Comment 14 Олег Соловьев 2022-10-25 17:14:18 MSK
(In reply to Vitaly Chikunov from comment #13)
> 3. NEW я считаю надо оставить -- это понятный статус. Пользователь завел баг
> и дальше мы должны его рассортировать, где только что заведенный баг - NEW.
> 
> Если это только для stable, то тут замена NEW на UNCONFIRMED смеет смысл. Но
> все равно можно остаться и на NEW, как привычном статусе, но для stable он
> будет означать ещё обработку QA.

Как раз это я и предлагал: оставить NEW в качестве состояния по умолчанию и после проверки перевешивать на CONFIRMED.

Так, например, сделано в https://bugs.kde.org

Из их статусов у нас уже есть:
REPORTED == NEW
ASSIGNED
REOPENED
RESOLVED
CLOSED
Comment 15 Sergey V Turchin 2022-10-25 17:23:23 MSK
У них вроде достаточно компактно  https://bugs.kde.org/page.cgi?id=fields.html#bug_status
Comment 16 Олег Соловьев 2022-10-25 17:29:49 MSK
(In reply to Sergey V Turchin from comment #15)
> У них вроде достаточно компактно 
> https://bugs.kde.org/page.cgi?id=fields.html#bug_status

5 статусов, а в поиске 8. Явно не трогали документацию
Comment 17 Mikhail Chernonog 2022-11-15 13:06:16 MSK
Для бранча p10, где есть QA, сейчас следующая схема работы.
Пользователь заводит баг и он попадает в статус UNCONFIRMED.
QA - запрашивает необходимую информацию, если информация получена, то перепроверяет баг.

Баг воспроизвёлся - перевешивается на сопровождающего пакета, меняется состояние на NEW
Баг не воспроизвёлся - меняется состояние на RESOLVED WORKSFORME.

Если информация не получена, то мне кажется требуется добавить в RESOLVED ещё один статус INSUFFICIENTDATA
Пример как сделано в LO: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/RESOLVED#INSUFFICIENTDATA

Так же было бы полезно добавить состояние NEEDINFO https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO
Процесс для бранчей где есть QA будет следующий:
UNCONFIRMED -информации нет-> NEEDINFO -информация представлена-> UNCONFIRMED -ошибка проверена и воспроизводится-> NEW
UNCONFIRMED -информации есть-,-ошибка проверена и воспроизводится-> NEW
UNCONFIRMED -информации есть-,-ошибка проверена и не воспроизводится-> RESOLVED WFM
UNCONFIRMED -информации нет-> NEEDINFO -информация не представлена-> RESOLVED INSUFFICIENTDATA
Comment 18 Anton Farygin 2022-11-15 20:42:35 MSK
А кто будет переводить в случае с UNCONFIRMED второй раз ?
UNCONFIRMED -информации нет-> NEEDINFO -информация представлена-> UNCONFIRMED -> ошибка проверена и воспроизводится-> NEW
Comment 19 Mikhail Chernonog 2022-11-16 18:47:10 MSK
В LO при запросе дополнительной информации последним предложением пишется разъяснение для пользователя, что после предоставления информации требуется перевести ошибку в статус UNCONFIRMED.
Таким образом перевешивает тот кто заводил баг и предоставил информацию.
Так же у них спустя время проходится qa-admin и если был дан ответ, но не изменён статус, то он сам меняет. После этого задача берётся в работу. У нас вместо qa-admin будет следить сотрудник который проверяет баг.
Comment 20 Anton Farygin 2022-11-16 21:02:28 MSK
по мне норм. 
у остальных возражений нет ?
Comment 21 Sergey V Turchin 2022-11-17 10:42:48 MSK
(Ответ для Mikhail Chernonog на комментарий #19)
> В LO при запросе дополнительной информации последним предложением пишется
> разъяснение для пользователя, что после предоставления информации требуется
> перевести ошибку в статус UNCONFIRMED.
Это слабое место. Разъяснение многим не поможет.
Comment 22 Mikhail Chernonog 2022-11-17 18:37:25 MSK
(Ответ для Sergey V Turchin на комментарий #21)
> (Ответ для Mikhail Chernonog на комментарий #19)
> > В LO при запросе дополнительной информации последним предложением пишется
> > разъяснение для пользователя, что после предоставления информации требуется
> > перевести ошибку в статус UNCONFIRMED.
> Это слабое место. Разъяснение многим не поможет.

Согласен что не все 100% пользователей так будут делать, но даже если 50% будет менять статус уже будет проще. Для оставшихся 50% всегда есть сотрудник, который ведёт баг и который запросил дополнительную информацию. В случае чего он сам переведёт баг в нужный статус.