Mantis (Мантис) — управление запросами на изменение ПО

Здесь можно обсудить сайт Far Manager и предложить идеи по его дальнейшему развитию.
User avatar
t-rex
Страшный и ужасный
Posts: 4910
Joined: Tue 15 Mar, 2005 16:17
Location: Tel-Aviv
Has thanked: 1 time
Been thanked: 8 times
Contact:

Post by t-rex »

Latest post of the previous page:

Какие все умные думать за других.

Alextp
А ты найвный що аж просто страшно.
Alextp
Posts: 117
Joined: Wed 02 Nov, 2005 15:56
Location: Москва

Post by Alextp »

А ты найвный що аж просто страшно.
Я просто не вижу другого способа для FG заработать деньги, кроме как если Рошал поделится процентом с продаж. Но наверное это наивно, согласен. Делиться он вряд ли станет. Зачем?
UJvu
Posts: 156
Joined: Tue 03 May, 2005 15:38
Location: Севастополь
Contact:

Post by UJvu »

а ФАР кто-то покупает? :)
Alextp
Posts: 117
Joined: Wed 02 Nov, 2005 15:56
Location: Москва

Post by Alextp »

Во времена 1.65 покупали, как сейчас - надо спросить Рошала.

PS
Анекдот знаешь? "Покупают, но маленько-маленько" :)
User avatar
WARP ItSelf
Самый умный
Posts: 1011
Joined: Tue 15 Mar, 2005 23:19
Contact:

Post by WARP ItSelf »

Все, заканчиваем бред.
Никто не знал, а я...
Alextp
Posts: 117
Joined: Wed 02 Nov, 2005 15:56
Location: Москва

Post by Alextp »

OK

PS Хотя интересно, что ты назвал "бредом".
DiRTy_GaRRy
Posts: 705
Joined: Tue 05 Apr, 2005 09:26
Been thanked: 3 times
Contact:

Предложение по Мантису

Post by DiRTy_GaRRy »

Текущая схема движения ошибки, по-моему, не очень удобна.

Вот список некоторых неудобств проявляющихся при работе с Far-м баг-трекером:
  1. Состояние resolved присваивает багу не создатель, а тот, кто его исправил;
  2. Вследствие этого становится невозможно прокомментировать баг до его закрытия;
  3. В списке постоянно болтаются resolved баги (в принципе, решается фильтром).
Предлагаю следующую систему (подсмотрено тут: https://www.ritlabs.com/bt/):
  1. Создание нового бага остаётся как есть;
  2. Далее багу могут присваиваться состояния assigned, confirmed, in work, acknowledged и т. д. и т. п. В общем, на этом шаге тоже ничего не меняется;

    Далее идут отличия.
  3. При исправлении бага разработчик переводит его не в состояние resolved, а в состояние verify wait;
  4. Из состояния verify wait создатель может перевести баг либо в состояние resolved, если баг исправлен, либо в состояние verify fail, если баг не исправлен;
  5. Из состояния resolved разработчик переводит баг в состояние closed;
  6. Resolved и closed баги создатель может снова перевести в состояние verify fail, т. е. сделать reopen issue.
Ы?
User avatar
bormant
Posts: 118
Joined: Fri 01 Apr, 2005 13:17
Contact:

Post by bormant »

DiRTy_GaRRy
+1
User avatar
HaRT
Moderator
Posts: 10823
Joined: Tue 30 Aug, 2005 17:21
Has thanked: 221 times
Been thanked: 358 times

Post by HaRT »

DiRTy_GaRRy
Здраво, поддерживаю.
Желательно при этом, чтобы а) при изменении статуса на verify wait запрос автоматически переводился на того, кто его занёс (в знак того, что пора протестировать); б) при действии reopen — на того, кто произвёл последний fix.
7. А ещё хочется, чтобы номер сборки, в который войдёт исправление, был отдельным полем запроса, обязательным к заполнению при действии fix (а то сейчас его приходится вычитывать из комментариев исправлявшего, да и то если он не забыл написать).
DiRTy_GaRRy
Posts: 705
Joined: Tue 05 Apr, 2005 09:26
Been thanked: 3 times
Contact:

Post by DiRTy_GaRRy »

HaRT wrote:DiRTy_GaRRy
Здраво, поддерживаю.
Желательно при этом, чтобы а) при изменении статуса на verify wait запрос автоматически переводился на того, кто его занёс (в знак того, что пора протестировать); б) при действии reopen — на того, кто произвёл последний fix.
Вообще-то всё это решается своевременным Assigned To. Или я чего-то не понимаю?
HaRT wrote:DiRTy_GaRRy7. А ещё хочется, чтобы номер сборки, в который войдёт исправление, был отдельным полем запроса, обязательным к заполнению при действии fix (а то сейчас его приходится вычитывать из комментариев исправлявшего, да и то если он не забыл написать).
Поддерживаю. При этом удобно будет смотреть что в какой версии исправлено.
Ы?
User avatar
HaRT
Moderator
Posts: 10823
Joined: Tue 30 Aug, 2005 17:21
Has thanked: 221 times
Been thanked: 358 times

Post by HaRT »

DiRTy_GaRRy wrote:Вообще-то всё это решается своевременным Assigned To. Или я чего-то не понимаю?
Ключевое слово — автоматически.
Наверняка понадобятся и другие правила для авто-назначения запросов на людей. Практика показывает, что хорошо настроенный набор таких правил сильно упрощает командное взаимодействие.
DiRTy_GaRRy
Posts: 705
Joined: Tue 05 Apr, 2005 09:26
Been thanked: 3 times
Contact:

Post by DiRTy_GaRRy »

HaRT wrote:
DiRTy_GaRRy wrote:Вообще-то всё это решается своевременным Assigned To. Или я чего-то не понимаю?
Ключевое слово — автоматически.
Наверняка понадобятся и другие правила для авто-назначения запросов на людей. Практика показывает, что хорошо настроенный набор таких правил сильно упрощает командное взаимодействие.
Что автоассигн багов это круто, как раз и так понятно. Но вот к теме топика это имеет весьма отдалённое отношение. ;)
Ы?
User avatar
Skirda
Posts: 3475
Joined: Wed 16 Mar, 2005 11:01
Been thanked: 8 times

Post by Skirda »

DiRTy_GaRRy wrote:Предлагаю следующую систему...
На первый взгляд... потянет :-)
HaRT wrote:7. А ещё хочется, чтобы номер сборки, в который войдёт исправление, был отдельным полем запроса, обязательным к заполнению при действии fix (а то сейчас его приходится вычитывать из комментариев исправлявшего, да и то если он не забыл написать).
Добавил пользовательское поле "build" - при переводе в "Решение" добавилось поле "Подверсия" - все верно?
User avatar
HaRT
Moderator
Posts: 10823
Joined: Tue 30 Aug, 2005 17:21
Has thanked: 221 times
Been thanked: 358 times

Post by HaRT »

Skirda wrote:
HaRT wrote:7. А ещё хочется, чтобы номер сборки, в который войдёт исправление, был отдельным полем запроса, обязательным к заполнению при действии fix (а то сейчас его приходится вычитывать из комментариев исправлявшего, да и то если он не забыл написать).
Добавил пользовательское поле "build" - при переводе в "Решение" добавилось поле "Подверсия" - все верно?
Со слов непонятно. Пощупать бы…
User avatar
Skirda
Posts: 3475
Joined: Wed 16 Mar, 2005 11:01
Been thanked: 8 times

Post by Skirda »

HaRT wrote:
Skirda wrote:
HaRT wrote:7. А ещё хочется, чтобы номер сборки, в который войдёт исправление, был отдельным полем запроса, обязательным к заполнению при действии fix (а то сейчас его приходится вычитывать из комментариев исправлявшего, да и то если он не забыл написать).
Добавил пользовательское поле "build" - при переводе в "Решение" добавилось поле "Подверсия" - все верно?
Со слов непонятно. Пощупать бы…
http://www.farmanager.com/mantis/view.php?id=307
User avatar
t-rex
Страшный и ужасный
Posts: 4910
Joined: Tue 15 Mar, 2005 16:17
Location: Tel-Aviv
Has thanked: 1 time
Been thanked: 8 times
Contact:

Post by t-rex »

DiRTy_GaRRy
Implemented.

1. Репортер создаёт новый тикет (new)
2. Девелопер или принимает тикет на себя (assigned) или закрывает (closed) если это скажем левый виш.
3. При исправлении бага или если нужна доп. информация девелопер выставляет статус feedback.
4. Репортер выставляет статус в resolved если баг исправлен или в new если нет.
5. Если всё ок то девелопер закрывает тикет (closed).

Мантис настроен соответствено.
Post Reply

Return to “Обсуждение www.farmanager.com”