Чому деякі великі проекти, такі як 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 не використовує трекер помилок - це, мабуть, просто те, що більшість учасників не вважають це корисним.

У дописі до списку розсилки Джуніо С Хамано (супроводжувач Гіта) підсумував, чому він вважає, що відслідковування помилок не дуже корисне. Я не хочу включати весь пост (він досить довгий), але він зводиться до:

• Якщо ви тільки шукаєте інформацію про вирішені проблеми, пошук архівів списків працює так само добре, як і пошук трекера помилок.
• Якщо ви повідомляєте про справжню помилку, і люди хочуть подбати про неї, список також працює добре.
• Якщо ніхто не зацікавлений у роботі над проблемою, вона потрапить через щілини, навіть у трекер помилок.
• Програма відслідковування помилок - це ще одна система, яку потрібно підтримувати, регулярно перевіряти наявність нових помилок, закривати виправлені помилки тощо.

Debian використовує трекер помилок, його інтерфейсом за замовчуванням є електронна пошта. І це зручно. Лукас Нуссбаум, нинішній керівник проекту Debian, опублікував кілька днів тому :

debugs - це програмне забезпечення, що стоїть за системою відстеження помилок Debian (BTS). Він також використовується проектом GNU. Незважаючи на те, що його часто сприймають як старий стиль, він має декілька унікальних особливостей, таких як відстеження стану помилок у кожній версії та відділенні пакета) або можливість виконувати всі взаємодії електронною поштою, що робить його дуже легким для роботи в режимі офлайн або в умовах поганого зв’язку.

Остання частина є вбивчою особливістю тут - просто в черзі ці звіти у вашій місцевій черзі, поки ви не вилетіли з літака!

• Зберігає 9-річних дітей.
• Не потрібно створювати окремий обліковий запис для кожного форуму.
• [мінор] Послідовний досвід користувачів у різних списках розсилки та нульова крива навчання під час підписки на новий список.
• Працює в режимі офлайн. ви можете підключитися до Інтернету та завантажити групу електронних листів, а потім піти в походи, написати свої відповіді, насолоджуючись материнською природою, та надіслати їх пізніше.
• Дозволяє шифрувати пошту та / або підписувати через GPG.
• Децентралізована - Якщо форум виходить з ладу, у вас все одно буде копія, вона також захищена від несанкціонованих дій, злий модератор / хакер не може легко підробити те, що ви сказали. Ніхто не може скасувати історію.
• Дозволяє фільтри, папки та всі розширені організаційні функції клієнта електронної пошти.
• "Надіслати сповіщення" - ви можете залишити свій електронний клієнт відкритим і отримувати сповіщення про нові відповіді.
• Одне місце, щоб ними керувати - не потрібно перестрибувати між різними сайтами.
• Імунізуйте всі вразливості безпеки, що стосуються Інтернету (html / javascript / ін'єкції тощо)
• Ніякого промахування - Без значків, химерних рухомих підписів, оголошень, веб-маяків, блокування Javascript. Все просто і до речі - обговорення.
• Менше навантаження сервера, ніж налаштування LAMP.

Одним з недоліків списків розсилки, що спадає на думку, є те, що форуми можна розділити на категорії та підкатегорії, тоді як списки розсилки - ні. Це можна імітувати, розділивши список розсилки на кілька списків розсилки, а потім користувачі можуть використовувати відповідні фільтри, щоб розмістити кожне повідомлення у відповідній папці (кожна папка - категорія). На веб-форумах це автоматично.