Здравствуйте, Ник, Вы писали:

I>>>>Я описал конкретный сценарий. Интеграция для него нужна, но сценарий к ней не сводится.
LV>>>Если я хочу посмотреть кто работал над файлом, мне тут поможет только самам CVS и ее лог. Вы предлагаете полноценного клиента встроить в issue tracking?

I>>Еще раз. Девелопер заимплементил фичу. Другие девелоперы в среднем 2-3 раза в неделю в течение года фиксили баги связаные с этой фичей.
I>>Нужен инструмент, который поможет задетектить проблему как можно раньше.

Ник>Есть интегрированная система, MKS Integrity. Там можно из Issue сразу посмотреть список файлов, коммитов, изменений кода, относящихся к нему.
Ник>А вообще, можно взять Redmine + SVN. Если заставлять девелоперов в комменте к коммиту указывать номер Issue, то Redmine будет это подцеплять и тоже показывать связку между issues и кодом.

Ник>То есть, совершенно необязательно велосипед изобретать.

А если для фичи нужно модифицировать DAL, UI, Services ? Как Redmine будет разделять, что если коммиты в файл X, то часть из них относится к фичеА, часть — к фичеБ, хотя issue просто баги ?

SX>Хотелось услышать мнение уважаемых господ, знаю, что вопрос поднимался уже кучу раз, но по-моему бесплатной и хорошо сделанной вещи — толком и нету. + сделать интеграцию в Студию для удобства. Вот хороший аналог есть BugNet — http://www.bugnetproject.com/, но он на классике и тяжеловесный.
SX>Что скажете?

Что Jira до 10 пользователей стоит 10$ и там есть вообще все. Что оставшуюся нишу усиленно пилят бесплатные redmine, phabricator и bugzilla со товарищи. "бесплатной и хорошо сделанной вещи — толком и нету" — слишком общие слова. Тот же redmine много человек пилят уже много лет. Думаете, сможете сделать лучше за разумное время?

Здравствуйте, SuperXren, Вы писали:

SX>Народ, родилась чистая и светлая идея создать open source проект для разработки ASP.NET MVC решения для управления багами и проектами.

Идея светлая, но не чистая. Наструя там MVC?? Он надоел хуже горькой редьки, решает проблем меньше, чем привносит, код усложняется, нафига себе ставить грабли?

SX>... по-моему бесплатной и хорошо сделанной вещи — толком и нету.

+100. Ну а кому её делать-то?? Студота — те и двух классов связать не могут, а то и наоборот — 200 завяжут в вермишель Средние прогеры — времени в обрез, это они понимают, как много ещё нужно учиться. "Старики" — а тем воще пофиг что Джира, что Редмайн, Джек Дэниелз всё равно лучше.

SX> + сделать интеграцию в Студию для удобства.

Это уже самое последнее. Для начала нужна архитектура — кто что и как делает. И набрать побольше фич из других багтрекеров, чтобы вывести универсальные запросы к таким системам.
На сегодня есть хоть какое-то описание?

I>>>>>Я описал конкретный сценарий. Интеграция для него нужна, но сценарий к ней не сводится.
LV>>>>Если я хочу посмотреть кто работал над файлом, мне тут поможет только самам CVS и ее лог. Вы предлагаете полноценного клиента встроить в issue tracking?

I>>>Еще раз. Девелопер заимплементил фичу. Другие девелоперы в среднем 2-3 раза в неделю в течение года фиксили баги связаные с этой фичей.
I>>>Нужен инструмент, который поможет задетектить проблему как можно раньше.

Ник>>Есть интегрированная система, MKS Integrity. Там можно из Issue сразу посмотреть список файлов, коммитов, изменений кода, относящихся к нему.
Ник>>А вообще, можно взять Redmine + SVN. Если заставлять девелоперов в комменте к коммиту указывать номер Issue, то Redmine будет это подцеплять и тоже показывать связку между issues и кодом.

Ник>>То есть, совершенно необязательно велосипед изобретать.

I>А если для фичи нужно модифицировать DAL, UI, Services ? Как Redmine будет разделять, что если коммиты в файл X, то часть из них относится к фичеА, часть — к фичеБ, хотя issue просто баги ?

Ну если вы начали с открытия одного issue в redmine, то по результату работы надо просто коммитить redmine-ориентированно, то есть пофиксил в нескольких местах кода для одной фичи — всё одно за другим закоммитил под одним issue. Или я не понял проблему?

Здравствуйте, LeonidV, Вы писали:

LV>Я могу придумать два организационных варианта решения задачи. С помощью трассирования на уровне issue (ставим related to #XXX). Либо находить какой-то часто изменяемый файл и по комментария на добавления находим номер issue, для которой он был создан. Еще вариант — добавить в документацию исходных кодов (в javadoc, в случае java) свой тэг, который будет сразу ссылаться на issue tracker.

Либо related, либо теги ставить и при поиске — собирать related коммиты из тикетов с этим тегом.

Здравствуйте, Ник, Вы писали:

I>>А если для фичи нужно модифицировать DAL, UI, Services ? Как Redmine будет разделять, что если коммиты в файл X, то часть из них относится к фичеА, часть — к фичеБ, хотя issue просто баги ?

Ник>Ну если вы начали с открытия одного issue в redmine, то по результату работы надо просто коммитить redmine-ориентированно, то есть пофиксил в нескольких местах кода для одной фичи — всё одно за другим закоммитил под одним issue. Или я не понял проблему?

Ты контекст потерял. Был сценарий — возникла проблема, выяснить, сколько времени было затрачено, до того, как она была решена. Предположим, девелопер коммитает один раз на фичу, один раз на баг.

I>>>А если для фичи нужно модифицировать DAL, UI, Services ? Как Redmine будет разделять, что если коммиты в файл X, то часть из них относится к фичеА, часть — к фичеБ, хотя issue просто баги ?

Ник>>Ну если вы начали с открытия одного issue в redmine, то по результату работы надо просто коммитить redmine-ориентированно, то есть пофиксил в нескольких местах кода для одной фичи — всё одно за другим закоммитил под одним issue. Или я не понял проблему?

I>Ты контекст потерял. Был сценарий — возникла проблема, выяснить, сколько времени было затрачено, до того, как она была решена. Предположим, девелопер коммитает один раз на фичу, один раз на баг.

А, ну так при каждой передаче issue от одного к другому приписывать, сколько времени потратил на последнем этапе.

Здравствуйте, Ник, Вы писали:

I>>Ты контекст потерял. Был сценарий — возникла проблема, выяснить, сколько времени было затрачено, до того, как она была решена. Предположим, девелопер коммитает один раз на фичу, один раз на баг.

Ник>А, ну так при каждой передаче issue от одного к другому приписывать, сколько времени потратил на последнем этапе.

Допустим, есть время на каждый тикет. Как посчитать, сколько времени отняла проблема.