44099 2022-10-20 20:42:20 +0300 Add more useful Status options 2025-08-26 10:10:34 +0300 1 1 2 Infrastructure Infrastructure bugzilla.altlinux.org unspecified x86 Linux CLOSED FIXED P5 normal --- 1 vt mcpain ldv rider snowmix snowmix zerg cas oldest_to_newest 216258 0 vt 2022-10-20 20:42:20 +0300 Может быть стоит добавить больше полезных статусов у багов[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 216259 1 rider 2022-10-20 21:03:38 +0300 Кстати да, поддерживаю это предложение. Особенно с учётом того, что у нас грядут некоторые изменения по разгребанию багов по stable непозиториям и статус UNCONFIRMED будет использоваться (вместо NEW). 216410 2 zerg 2022-10-24 14:23:38 +0300 IMHO если расширять, то минимально, чтоб не наплодить статусов, которые малопонятны простым пользователям. Они и так боятся. 216436 3 mcpain 2022-10-25 10:52:48 +0300 (In reply to Anton Farygin from comment #1) > Кстати да, поддерживаю это предложение. > > Особенно с учётом того, что у нас грядут некоторые изменения по разгребанию > багов по stable непозиториям и статус UNCONFIRMED будет использоваться > (вместо NEW). раз "вместо", то лучше NEW не трогать? NEW -> CONFIRMED -> ASSIGNED -> IN_PROGRESS -> RESOLVED -> CLOSED 216437 4 mcpain 2022-10-25 11:02:26 +0300 И что будут означать RESOLVED FIXED и RESOLVED UPSTREAM? Это зависит от того, кто исправил багу? Или RESOLVED UPSTREAM будет означать, что бага исправлена нами, но изменения вместо Сизифа отправлены в апстрим и ментейнер ждёт merge в стабильный бранч, чтобы собрать из очередного релиза (я часто так делаю со своими исправлениями в KDE, но иногда оно требуется "прямщаз" и я прикладываю его отдельным патчем)? И что делать с багами IN_PROGRESS? Никто не будет гарантировать что IN_PROGRESS будет находиться в "висячем" состоянии как ASSIGNED. Вместо этого можно сбрасывать ASSIGNED обратно в NEW через некоторое время после бездействия assignee. 216438 5 zerg 2022-10-25 11:03:48 +0300 (Ответ для Олег Соловьев на комментарий #3) > > UNCONFIRMED будет использоваться (вместо NEW). > раз "вместо", то лучше NEW не трогать? UNCONFIRMED ещё и менее понятное. 216441 6 rider 2022-10-25 11:17:19 +0300 с UNCONFIRMED всё просто: по новому регламенту ошибка в stable ветках будет сначала вешаться на qateam и ими подтверждаться и уже потом перевешиваться на исполнителя или ментейнера. Собственно статус UNCONFIRMED будет в этот момент. 216445 7 mcpain 2022-10-25 11:33:56 +0300 (In reply to Anton Farygin from comment #6) > с UNCONFIRMED всё просто: > по новому регламенту ошибка в stable ветках будет сначала вешаться на qateam > и ими подтверждаться и уже потом перевешиваться на исполнителя или > ментейнера. > > Собственно статус UNCONFIRMED будет в этот момент. Это заметят пользователи и начнут задавать вопросы. Предлагаю: > Пользователь вешает баг < Статус бага NEW как и раньше, исполнитель - qa > QA подтверждает наличие бага < NEW -> CONFIRMED, assignee qa -> maintainer Изменение будет прозрачно для пользователей (как было NEW так и осталось при заведении бага). Считаю, что если начальное состояние по каким-то причинам станет другим -- будут вопросы, а документацию читают не только лишь все. 216446 8 rider 2022-10-25 11:43:50 +0300 А что тогда будет делать статус ASSIGNED ? 216449 9 mcpain 2022-10-25 11:50:00 +0300 (In reply to Anton Farygin from comment #8) > А что тогда будет делать статус ASSIGNED ? То же, что и сейчас: насколько я знаю, это понимается как "взято в работу" 216450 10 mcpain 2022-10-25 11:54:24 +0300 PS судя по нашей же вики, UNCONFIRMED был выброшен ещё в далеком 2008 году, но документацию в соответствие с этим никто не приводил: https://www.altlinux.org/BugTracking/BugzillaMiniHowto Отсюда и путаница -- статус отсутствует в базе, им давно никто не пользуется, но он почему-то ещё задокументирован 216451 11 mcpain 2022-10-25 11:59:44 +0300 Пока что я понимаю workflow так: NEW - багу только только завели, никто её не подтверждал CONFIRMED - багу подтвердил либо ментейнер, либо QA ASSIGNED - бага в работе ИЛИ ASSIGNED - ментейнер знает про багу и добавил её в очередь IN_PROGRESS - ментейнер работает над багой / исправление готово, ждёт одобрения QA 216452 12 zerg 2022-10-25 12:06:15 +0300 (Ответ для Олег Соловьев на комментарий #11) > IN_PROGRESS - ментейнер работает над багой / исправление готово, ждёт > одобрения QA По идее, это 2 разных статуса. 216471 13 vt 2022-10-25 15:58:59 +0300 > 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 Эти статусы можно различить - один менеджерский а другой разработческий. 216490 14 mcpain 2022-10-25 17:14:18 +0300 (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 216496 15 zerg 2022-10-25 17:23:23 +0300 У них вроде достаточно компактно https://bugs.kde.org/page.cgi?id=fields.html#bug_status 216498 16 mcpain 2022-10-25 17:29:49 +0300 (In reply to Sergey V Turchin from comment #15) > У них вроде достаточно компактно > https://bugs.kde.org/page.cgi?id=fields.html#bug_status 5 статусов, а в поиске 8. Явно не трогали документацию 217368 17 snowmix 2022-11-15 13:06:16 +0300 Для бранча 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 217406 18 rider 2022-11-15 20:42:35 +0300 А кто будет переводить в случае с UNCONFIRMED второй раз ? UNCONFIRMED -информации нет-> NEEDINFO -информация представлена-> UNCONFIRMED -> ошибка проверена и воспроизводится-> NEW 217469 19 snowmix 2022-11-16 18:47:10 +0300 В LO при запросе дополнительной информации последним предложением пишется разъяснение для пользователя, что после предоставления информации требуется перевести ошибку в статус UNCONFIRMED. Таким образом перевешивает тот кто заводил баг и предоставил информацию. Так же у них спустя время проходится qa-admin и если был дан ответ, но не изменён статус, то он сам меняет. После этого задача берётся в работу. У нас вместо qa-admin будет следить сотрудник который проверяет баг. 217480 20 rider 2022-11-16 21:02:28 +0300 по мне норм. у остальных возражений нет ? 217497 21 zerg 2022-11-17 10:42:48 +0300 (Ответ для Mikhail Chernonog на комментарий #19) > В LO при запросе дополнительной информации последним предложением пишется > разъяснение для пользователя, что после предоставления информации требуется > перевести ошибку в статус UNCONFIRMED. Это слабое место. Разъяснение многим не поможет. 217575 22 snowmix 2022-11-17 18:37:25 +0300 (Ответ для Sergey V Turchin на комментарий #21) > (Ответ для Mikhail Chernonog на комментарий #19) > > В LO при запросе дополнительной информации последним предложением пишется > > разъяснение для пользователя, что после предоставления информации требуется > > перевести ошибку в статус UNCONFIRMED. > Это слабое место. Разъяснение многим не поможет. Согласен что не все 100% пользователей так будут делать, но даже если 50% будет менять статус уже будет проще. Для оставшихся 50% всегда есть сотрудник, который ведёт баг и который запросил дополнительную информацию. В случае чего он сам переведёт баг в нужный статус. 271395 23 mcpain 2025-08-26 10:10:34 +0300 наличия UNCONFIRMED достаточно?