Может быть стоит добавить больше полезных статусов у багов[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
Кстати да, поддерживаю это предложение. Особенно с учётом того, что у нас грядут некоторые изменения по разгребанию багов по 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% всегда есть сотрудник, который ведёт баг и который запросил дополнительную информацию. В случае чего он сам переведёт баг в нужный статус.
наличия UNCONFIRMED достаточно?
