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

65

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

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

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

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

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

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

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

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

naught101
источник
2
Да, нет, я согласен с вами, Git использует списки рассылки :) То, что я говорил, это то, что вы смешиваете это с «некоторыми действительно большими проектами», и я просто думал, что если вы сделаете это, вы должны дать немного больше примеры для тех действительно больших проектов. В противном случае вопрос сводится к "Git использует список рассылки, почему это так?" в этом случае ответ Йорг W Миттаг лучше подходит ...
Shivan Dragon
1
Хм, у меня сложилось впечатление, что их было больше ... Debian использует систему , основанную на почте , хотя и более сложную, чем список рассылки. Хорошо, но главное - «каковы преимущества использования списка рассылки по сравнению с трекером ошибок»? Если ответ «нет, разработчики git - просто луддиты».
naught101
@ naught101: почему ты срываешься, когда видишь это? Нестабильный Debian может быть установлен и использован без необходимости использования каких-либо удаленных эксплойтов root, без необходимости перезагрузки в течение шести месяцев. Это для нестабильной версии Debian. У меня заблокированы серверы Debian, которые работали в течение 4-х раз в сутки (ни один удаленный эксплойт root, требующий перезагрузки, влияющий на мои настройки в этот период). Эти ребята, возможно, не используют новейшие технологии, но они, очевидно, делают все правильно. Я бы отказался от веб-трекеров для стабильности Debian в любое время.
Седрик Мартин
2
@CedricMartin: я знаю, я согласен. Отслеживание ошибок в почтовой рассылке работает вполне адекватно для некоторых команд, но для меня это все еще не так просто, как для отслеживания ошибок. Я думал, однако, что для разработчиков основного проекта разница может показаться очень небольшой: они следуют почти всему, что происходит в любом случае. Но для новичков список рассылки почти невозможно найти, поэтому простого обзора пригодности проекта невозможно. Система отслеживания ошибок позволяет новым пользователям / разработчикам быстро выяснить, как движется проект, и получить представление о том, какие улучшения считаются важными для основной команды.
naught101
Грег Кроа-Хартман берет это на себя, поскольку это относится к ядру Linux в рамках этого обсуждения . В частности: « НЕТ никакого способа, которым модель github / gerrit / gitorious работала бы для ядра. Масштаб, на котором мы работаем, - это совершенно другой уровень, чем те, которые могли бы обрабатываться этими инструментами. известный способ обработки 10000 патчей каждые 2 месяца в стабильном выпуске с экспертной оценкой, с более чем 3000 разработчиками, помимо того, что мы делаем сегодня ".
naught101

Ответы:

45

Наблюдаемое вами предпочтение выглядит как естественное следствие рекомендации, четко изложенной в стандартах кодирования 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


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

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

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

комар
источник
3
Отличный ответ! Электронная почта более известна, чем система отслеживания проблем, и ее легче понять (что не означает, что каждый «получает» электронную почту: P)
Andres F.
21
Кроме того, этот совет GNU является древним, намного старше, чем веб и сетевые трекеры.
Росс Паттерсон
@ RossPatterson Я так и думал. Но кажется маловероятным, что он старше, чем Интернет, учитывая, что он содержит несколько URL-адресов ...
naught101
6
@gnat: Основная часть того связанного ответа, который так велик, - это часть «если тебе легко, ты можешь ввести такую ​​вещь прямо здесь» . Это ключ ко многим проектам с открытым исходным кодом, так как нет поддержки по телефону. Список рассылки отключен для меня как пользователя, сообщающего об ошибках, так как я не хочу подписываться на ответы. С помощью системы отслеживания ошибок я вижу, что у меня проблема в системе, и могу вернуться и найти ее позже, и посмотреть, было ли она обновлена. Это трудно сделать со списком рассылки, если только нет действительно хорошего веб-трекера, что часто не так.
naught101
1
@ naught101 Возможно, он не старше Интернета, но определенно старше веб-трекеров
sakisk
30

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

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

Йорг Миттаг
источник
3
Я думал, что WWW предшествовал Linux. Слегка. Они оба были в значительной степени сделаны в одно и то же время и разными группами людей; это не было до середины 90-х годов, которые либо взлетели.
Донал Феллоуз
6
Хорошо, но ядро ​​Linux теперь имеет трекер ошибок: bugzilla.kernel.org . Очевидно, это не такой большой барьер.
naught101
7
-1 Git серьезно моложе, чем веб. Винтаж 2005 года. В то время было много трекеров, в том числе, конечно, Bugzilla. Линусу просто не нравятся трекеры, и его слово - закон в этой среде.
Росс Паттерсон
6
@ RossPatterson - он сказал, что Linux старше Интернета, а не Git. Я не думаю, что ваш комментарий оправдывает отрицательное голосование, поскольку вы в основном повторили то, что он сказал.
beatgammit
2
@tjameson Оглядываясь назад, вы правы. Вернуться к нейтральному.
Росс Паттерсон
17

Для Git:

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

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

  • Если вы ищете только информацию о решенных проблемах, поиск в архивах списков работает так же, как и поиск ошибок.
  • Если вы сообщаете о подлинной ошибке, и люди хотят позаботиться об этом, список также работает хорошо.
  • Если никто не заинтересован в работе над проблемой, она провалится через трещины, даже в трекере ошибок.
  • Система отслеживания ошибок - это еще одна система, которую необходимо обслуживать, регулярно проверять на наличие новых ошибок, закрывать исправленные ошибки и т. Д. Короче говоря, дополнительная работа приносит мало пользы.
sleske
источник
5
Хороший ответ, но я бы сказал, что ваш 3-й пункт является серьезным недостатком электронной почты: если ошибку трудно исправить, а текущие разработчики ленивы, она становится значительно более скрытой, чем запись в трекере. Это может означать, что некоторые ошибки никогда не исправляются, просто потому, что люди не знают их там
TheLQ
1
@TheLQ: правда. Однако, по-видимому, это риск, на который готовы пойти некоторые проекты. И, честно говоря, git - довольно солидная часть программного обеспечения, даже без системы отслеживания ошибок.
Слёске
1
@TheLQ: Разве простая веб-страница с упоминанием всех известных ошибок (и связанных с ними тем) не разрешит это? Нечто похожее на это, за исключением того, что ссылки указывают на архивные темы.
Привет, мир
1
@HelloWorld: Ну, это был бы (простой) трекер проблем. И точно так же, как система отслеживания проблем, кому-то придется справиться с этим ...
sleske
Есть ли хороший способ получить офлайн копию письма, которое было отправлено, когда я не был подписчиком?
PSkocik
6

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

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

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

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

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

Привет, мир
источник
почему люди настаивают на создании веб-версий для отслеживания проблем (кстати, этот вопрос не обо всем ) обсуждается в другом вопросе: как заставить пользователей писать достойные и полезные отчеты об ошибках "Редактируемые пользователем онлайн-отчеты об ошибках являются наиболее эффективным способом обучения пользователи улучшают ... "
Gnat
Спасибо. Но оправдывает ли это отрицательный голос? Основная тема этого ответа - преимущества ML, и он довольно хорошо отвечает на оригинальный вопрос. Я удалил «веб-форумы».
Hello World,
2
Недостаток, упомянутый в этом ответе, фактически не позволяет мне придерживаться большинства списков рассылки разработчиков. Они отправляют через все , поэтому после сообщения об ошибке я обычно отписываюсь через две недели. Багтрекеры прекрасно решают эту проблему, разрешая мне подписаться на конкретные сообщения об ошибках.
Роман Старков
6
Исправление: не пускает 25- летних. Только недавно я узнал, как эти списки рассылки работают, чтобы внести свой вклад в некоторые реальные проекты. И я ненавижу это !!
Сиро Сантилли 事件 改造 中心 法轮功 六四 事件
2
«Не нужно создавать отдельную учетную запись для каждого форума». - часто, чтобы предотвратить спам, вам нужно подписаться на список. Но это подписывается на все электронные письма. Таким образом, вам нужно подписаться И отказаться от «спама» И добавить запрос, чтобы держать вас в CC или TO. По сравнению с багзиллой это гораздо больше.
Мацей Пехотка