Её ещё во втором апдейте статьи Distributed Bug Tracking похвалили. Я тоже двумя рукам за

Главная мысль статьи — что людей нужно учить и принуждать правильно пользоваться системой. Поэтому убеждать, что те, кто не пользуется централизованной базой багтрекинга — правы — это перебор. Скажу даже больше — это все фигня. Для долгоживущих проектов нужна централизованная база.

При этом я с успехом пользуюсь bzr для управления моим кодом, и централизованной базой Trac.

За последнее время я понял, что децентрализованные системы не живут сами по себе. Все равно должен быть центр, пусть он становится социальным, а не навязываемым trunk как в svn, но он должен быть. А с багами — это архиважно. Цитируя одно из высказываний выше: “как в системе BE я узнаю, что добавлен новый баг или починен какой-то старый, если я не объединял свою ветку с веткой другого разработчика? а если он вчера завел/починил баг, а сегодня уехал в отпуск?”

Причины:
- у разработчиков нет “своего” кода, в котором программист может делать что хочет – задачи часто назначаются произвольно (на это тоже есть причины). Поэтому делать что понравилось – большие шансы получить конфликты при покладке в SVN.
- через багтрекер ведутся ежедевные отчеты. Нет задачи – некуда отчитываться.
- при коммите нужно указывать номер исправленной баги – без баги в багтрекере указывать нечего.

При таком подходе вероятность того, что разработчик будет тайно фиксить ошибки, которых нет в багтрекере примерно равна вероятности того, что сантехник из ЖЭК-а будет забесплатно и тайно от всех ходить по квартирам и ремонтировать краны т.к. “дошел слух, что протекает”. Причем сантехников за это никто по рукам не бьет – я точно знаю

Если багтекер в достаточной степени интегрирован в процесс, то проблемы использования/не использования не возникает.

У меня нет метрик, к сожалению, но мне радостно что приходиться дело иметь именно с таким проектом, и не сказать чтобы он такой уж маленький

Баг треккинг – это давно уже не мода (если когда и была – я на своем веку не застал), а удобный и зачастую необходимый инструмент. Заметьте, никто не говорит о том, что все нужно заносить в эти “тяжеловесные системы” – ведь треккинг issue и их очередей – это накладные расходы. Я считаю вполне нормальной ситуацию

проще письмо написать или подойти

– пусть эксперт решает можно ли починить быстро или оформить по правилам. Баги – это не самоцель. Никакой формализации или идеализации – все в рамках прагматического подхода. По-этому, кстати, я в самом первом своем ответе провел речь между долго- и короткоживущими issues.

Для меня как раз более идеалистичным выглядит случай, когда действительно можно вполне обойтись без расходов на баг треккинг – это когда система очевидна и доступна пониманию, дефекты обнаруживаются, доносятся и чинятся быстрее, чем имело бы смысл их отслеживать, и скорее всего наличествует хорошая страховка в виде автоматических тестов. Увы, в подавляющем числе случаев это наблюдается на самых начальных этапах разработки

Скажу только что в нескольких средних проектах, в которых я работал и работаю багтреккером вообще почти не пользуются. На это были и есть разные причины, и не скажу что такой подход неэффективен. Все зависит от конкретных условий.

Налажены и “ими пользуются” — понятия разные.

В моем ответе читай “налажены и успешно используются”

… но я не видел и не слышал ни об одной более-менее крупной компании где bug&issue tracking был полностью централизован и являлся основным средством постановки задач подавляющему большинству разработчиков.

На счет более крупных компаний с централизацией багосистемы не скажу – давайте поговорим о том, в чем компетентны. Скажем, работа над одним продуктом и комманда до 10-20 человек. Приходилось участвовать в слиянии change requests – specifications/ bugs / future plans в одну систему. Стало намного проще, как с точки зрения product management в планировании ближайших релизов так и с более приземленного уровня отслеживания зависимостей. И этот случай не един. Если говорить о действительно больших организациях (более 100 человек, много проектов), то тут польза от централизированной единой системы – в унификации администрирования и подходов, при известных минусах, но это ИМХО совершенно не относится ни к поднятой теме ни к комментариям.

На счет основного средства постановки задач – я не совсем понимаю, о чем речь. Спецификации? Их можно держать в Issues, если очень хочется, в моем примере это заменено на общение с заказчиком.

А если в соседнем есть функционал который перекрывает эти баги или их там уже пофиксили, в то время как в основном этих фиксов/изменений нет?

Никаких проблем. Что-то типа: будет комментарий о починке в этой соседней ветке и баг будет взят на себя починившим до мержа в общую ветвь, что должно быть достаточно скоро в случае короткоживущих веток, или это будет по полной программе оформленно QA в случае фикса в одной из долгоживущих веток.

Как раз сложнее представить себе как в распределенной системе я узнаю что кто-то пофиксил некий баг, не слившись с его веткой.

Надо сказать что с такой позиции смотрит подовляющее большинство разработчиков и менеджеров.

В организациях, описанных Вами выше ( тестеры багят для отчетности, остальные – из вредности ) – вполне может быть. Лично я стараюсь избегать подобные среды. Есть много других. А в этих проблема не в инструментах, ИМХО.
А если вообще по индустрии – потрудитесь подкрепить свои слова фактами. Хотя бы корректно сформулированным опросником на сайте (хотя выборка и не совершенна).

В завершениие еще раз хотелось бы отметить, что описанный подход хоть и представляет собой интерес в качетве дополнения, но не может, судя по всему, в целом еще заменить традиционный bug/issue tracking механизм в более или менее серьезной разработке с участием 3х и более лиц, и тут я уверен – со мной согласится подавляющее большинство разработчиков, менеджеров, специалистов по качеству, и особенно клиентов и пользователей

Очень спорное утверждение, скажу даже “ложь” в булевом смысле Во всех более или менее серьезных коммерческих и нет проектах, которые мне приходилось наблюдать или участвовать, bug tracking (а еще лучше – в более общем смысле – change request) были налажены.

Налажены и “ими пользуются” — понятия разные. Багтреккером пользуются в основном тестеры — потому что это их основной способ отчетности, неравнодушные менеджеры и разработчики (кто-то периодами, по-настроению, кто-то регулярно, но точно не все, если в компании более одного-двух), или зануды (”сяду-ка я напишу 30 багов, пусть подавяться”) — классификация упрощенная, но я не видел и не слышал ни об одной более-менее крупной компании где bug&issue tracking был полностью централизован и являлся основным средством постановки задач подавляющему большинству разработчиков.

Скажем, если я в своем личном бранче обнаружил или создал баг, то незачем трекать какой именно это бранч

А если в соседнем есть функционал который перекрывает эти баги или их там уже пофиксили, в то время как в основном этих фиксов/изменений нет?

я смотрел с позиции, когда багтреккинг то не особенно и нужен

Надо было сразу так сказать:)

Надо сказать что с такой позиции смотрит подовляющее большинство разработчиков и менеджеров.

Даже когда речь идет об очень не маленьких проектах.

Да и сразу отвечу на вопрос ниже — нет, конечно картинку привязать на данном этапе к задаче нельзя. Я и не рассматриваю be как готовую замену Jira или какому-либо иному багтреккеру. На мой взгляд это очень интересное и перспективное направление развития. В be мне нравиться простота — это именно утилита, а не программа, в том числе и простота модификации . Вполне возможно что это направление будет развиваться, и скоро мы увидим полноценные и интересные VCS построенные по такому же принципу