Почему некоторые крупные проекты, такие как Git и Debian, используют только список рассылки, а не систему отслеживания проблем?

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

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

• Git - Страница сообщества :

  ... Сообщения об ошибках должны быть отправлены в этот список рассылки.

• Система отслеживания ошибок Debian , согласно Википедии:

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

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

Итак, каковы основные преимущества списка рассылки по сравнению с веб-трекером? Почему некоторые крупные проекты используют только список рассылки?

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

4.7.2 --help

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

Ближе к концу ‘--help’вывода опции, пожалуйста, разместите строки, дающие адрес электронной почты для отчетов об ошибках , домашнюю страницу пакета (обычно ‘http://www.gnu.org/software/pkg’, и общую страницу для помощи при использовании программ GNU. Формат должен быть таким:

    Report bugs to: mailing-address
    pkg home page: <http://www.gnu.org/software/pkg/>
    General help using GNU software: <http://www.gnu.org/gethelp/>

Можно упомянуть другие соответствующие списки рассылки и веб-страницы.

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

Система отслеживания проблем может быть (и я думаю, что это лучше) для разработчика, работающего в проекте, но для более широкой аудитории будет сложнее представить и объяснить, как его использовать, особенно с учетом большого разнообразия и различий между различными системами отслеживания проблем. ,

Один проект может использовать Bugzilla, другой придерживается JIRA, третий - ... GNATS , и т. Д., И т. Д. И т. Д. Просто невозможно представить весь этот "зоопарк" так, чтобы он был настолько стандартным и единообразным, как

Report bugs to: mailing-address

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

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

Вы должны быть в состоянии ввести проблемы и назначить их вручную клиенту ...

В частности, у Git есть простая историческая причина: Git был запущен хакерами Linux для хакеров Linux и использует ту же модель разработки и инструменты, что и сам Linux. Linux, однако, старше, чем WWW, поэтому, когда Linux был запущен, просто не было сетевых средств отслеживания проблем, потому что не было сети!

Как следствие, сообщество Linux разработало чрезвычайно эффективные инструменты и рабочие процессы для работы с отчетами об ошибках и обзорами кода по электронной почте, и у них не было никаких причин, чтобы отбрасывать всю эту работу и начинать с нуля, когда они начинали проект Git.

Для Git:

В списке рассылки есть несколько обсуждений, где люди предлагают использовать какой-то трекер ошибок. Похоже, что эти инициативы провалились, поэтому причина, по которой Git не использует трекер ошибок, заключается в том, что большинство участников не находят это полезным.

В сообщении к списку рассылки Джунио С. Хамано (сопровождающий Git) подытожил, почему он считает, что средство отслеживания ошибок не очень полезно Я не хочу включать весь пост (он довольно длинный), но он сводится к следующему:

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

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

debbugs - это часть программного обеспечения системы отслеживания ошибок Debian (BTS). Он также используется проектом GNU. Несмотря на то, что его часто воспринимают как старый стиль, он имеет несколько уникальных функций (таких как отслеживание состояния ошибок в каждой версии и ветви пакета) или возможность выполнять все взаимодействия по электронной почте, что делает его очень простым в работе в автономном режиме или в плохо подключенных средах.

Последняя часть здесь - убийственная особенность - просто ставьте эти отчеты в очередь в локальной почте, пока вы не сойдете с самолета!

• Не пускает 9 лет.
• Не нужно создавать отдельную учетную запись для каждого форума.
• [несовершеннолетний] Согласованный пользовательский опыт в разных списках рассылки и нулевая кривая обучения при подписке на новый список.
• Работает в автономном режиме. Вы можете подключиться к Интернету и загрузить партию писем, а затем отправиться в поход, написать свои ответы, наслаждаясь природой, и отправить их позже.
• Позволяет шифровать и / или подписывать почту через GPG.
• Децентрализованный - Если форум рухнет, у вас все равно будет копия, она также устойчива к несанкционированному изменению, злой модератор / хакер не может легко подделать то, что вы сказали. Никто не может отменить историю.
• Позволяет фильтры, папки и все расширенные организационные функции почтового клиента.
• «Push-уведомления» - вы можете оставить свой почтовый клиент открытым и получать уведомления о новых ответах.
• Одно место, чтобы управлять ими всеми - не нужно прыгать между разными сайтами.
• Невосприимчив ко всем уязвимостям безопасности, связанным с сетью (html / javascript / инъекции и т. Д.)
• Нет раздувания - Нет значков, причудливых движущихся подписей, рекламы, веб-маяков, раздувания javascript. Все просто и по существу - обсуждение.
• Меньшая нагрузка на сервер, чем настройка LAMP.

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