Bug 44099

Кстати да, поддерживаю это предложение.

Особенно с учётом того, что у нас грядут некоторые изменения по разгребанию багов по stable непозиториям и статус UNCONFIRMED будет использоваться (вместо NEW).

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

(In reply to Anton Farygin from comment #1)
> Кстати да, поддерживаю это предложение.
> 
> Особенно с учётом того, что у нас грядут некоторые изменения по разгребанию
> багов по stable непозиториям и статус UNCONFIRMED будет использоваться
> (вместо NEW).

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

NEW -> CONFIRMED -> ASSIGNED -> IN_PROGRESS -> RESOLVED -> CLOSED

И что будут означать RESOLVED FIXED и RESOLVED UPSTREAM?

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

И что делать с багами IN_PROGRESS? Никто не будет гарантировать что IN_PROGRESS будет находиться в "висячем" состоянии как ASSIGNED.
Вместо этого можно сбрасывать ASSIGNED обратно в NEW через некоторое время после бездействия assignee.

(Ответ для Олег Соловьев на комментарий #3)
> > UNCONFIRMED будет использоваться (вместо NEW).
> раз "вместо", то лучше NEW не трогать?
UNCONFIRMED ещё и менее понятное.

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

Собственно статус UNCONFIRMED будет в этот момент.

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

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

Предлагаю: 

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

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

Изменение будет прозрачно для пользователей (как было NEW так и осталось при заведении бага).
Считаю, что если начальное состояние по каким-то причинам станет другим -- будут вопросы, а документацию читают не только лишь все.

А что тогда будет делать статус ASSIGNED ?

(In reply to Anton Farygin from comment #8)
> А что тогда будет делать статус ASSIGNED ?

То же, что и сейчас: насколько я знаю, это понимается как "взято в работу"

PS судя по нашей же вики, UNCONFIRMED был выброшен ещё в далеком 2008 году, но документацию в соответствие с этим никто не приводил: https://www.altlinux.org/BugTracking/BugzillaMiniHowto

Отсюда и путаница -- статус отсутствует в базе, им давно никто не пользуется, но он почему-то ещё задокументирован

Пока что я понимаю workflow так:

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

ИЛИ

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

(Ответ для Олег Соловьев на комментарий #11)
> IN_PROGRESS - ментейнер работает над багой / исправление готово, ждёт
> одобрения QA
По идее, это 2 разных статуса.

> 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

Эти статусы можно различить - один менеджерский а другой разработческий.

(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

У них вроде достаточно компактно  https://bugs.kde.org/page.cgi?id=fields.html#bug_status

(In reply to Sergey V Turchin from comment #15)
> У них вроде достаточно компактно 
> https://bugs.kde.org/page.cgi?id=fields.html#bug_status

5 статусов, а в поиске 8. Явно не трогали документацию

Для бранча 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

А кто будет переводить в случае с UNCONFIRMED второй раз ?
UNCONFIRMED -информации нет-> NEEDINFO -информация представлена-> UNCONFIRMED -> ошибка проверена и воспроизводится-> NEW

В LO при запросе дополнительной информации последним предложением пишется разъяснение для пользователя, что после предоставления информации требуется перевести ошибку в статус UNCONFIRMED.
Таким образом перевешивает тот кто заводил баг и предоставил информацию.
Так же у них спустя время проходится qa-admin и если был дан ответ, но не изменён статус, то он сам меняет. После этого задача берётся в работу. У нас вместо qa-admin будет следить сотрудник который проверяет баг.

по мне норм. 
у остальных возражений нет ?

(Ответ для Mikhail Chernonog на комментарий #19)
> В LO при запросе дополнительной информации последним предложением пишется
> разъяснение для пользователя, что после предоставления информации требуется
> перевести ошибку в статус UNCONFIRMED.
Это слабое место. Разъяснение многим не поможет.

(Ответ для Sergey V Turchin на комментарий #21)
> (Ответ для Mikhail Chernonog на комментарий #19)
> > В LO при запросе дополнительной информации последним предложением пишется
> > разъяснение для пользователя, что после предоставления информации требуется
> > перевести ошибку в статус UNCONFIRMED.
> Это слабое место. Разъяснение многим не поможет.

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