Как проект ядра Linux отслеживал ошибки в первые дни?

Все мы знаем, что Линус Торвальдс создал Git из-за проблем с Bitkeeper. Что неизвестно (по крайней мере, мне), как проблемы / билеты / ошибки отслеживались до тех пор? Я пытался, но ничего интересного не получилось. Единственное обсуждение, которое я смог получить по этому вопросу, было то, где Линус разделял озабоченность по поводу использования Bugzilla .

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

Я видел и использовал Bugzilla, и если вы не знаете правильные «ключевые слова», вы будете в тупике. ПРИМЕЧАНИЕ: меня особенно интересуют первые годы (1991-1995) того, как они использовали для отслеживания проблем.

Я просмотрел два потока: « Kernel SCM saga » и « Общая информация: когда git self-host? », Но ни один из них не упоминал об отслеживании ошибок ядра в первые дни.

Я искал вокруг и не смог найти ни одного программного обеспечения для отслеживания ошибок FOSS, которое было там в 1991-1992 годах. Bugzilla, Request-tracker и другие появились намного позже, поэтому их, похоже, нет.

Ключевые вопросы

1. Как тогда Линус, разработчики подсистем и пользователи сообщали и отслеживали ошибки в те дни?
2. Использовали ли они какое-либо программное обеспечение для отслеживания ошибок, создавали ветки ошибок и фиксировали вопросы и обсуждали ошибки (было бы дорого и больно это делать) или просто использовали электронную почту.
3. Намного позже появился Bugzilla (первый выпуск 1998 года), и это, кажется, основной способ сообщать об ошибках впоследствии .

С нетерпением жду более четкого представления о том, как все было сделано в старые времена.

Вначале, если вам нужно было что-то внести (патч или отчет об ошибке), вы отправили это по почте Линусу. Это развилось в послав его в список (который был linux-kernel@vger.rutgers.eduдо того kernel.orgбыл создан).

Там не было никакого контроля версий. Время от времени Линус помещал тарбол на FTP-сервер. Это был эквивалент «тега». Изначально доступными инструментами были RCS и CVS, и Линус ненавидит их, так что все просто отправили патчи по почте. (У Линуса есть объяснение, почему он не хотел использовать CVS.)

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

Bitkeeper обошел обе эти проблемы: он не был централизованным, как CVS, и хотя он не был свободным программным обеспечением, разработчики ядра могли использовать его без оплаты. Это сделало это достаточно хорошим на некоторое время.

Даже при сегодняшней разработке на основе git, списки рассылки все еще находятся там, где есть действие. Если вы хотите внести что-то, вы, конечно, подготовите это с помощью git, но вам придется обсудить это в соответствующем списке рассылки, прежде чем это будет объединено. Bugzilla готова выглядеть «профессионально» и впитывать недоделанные сообщения об ошибках от людей, которые на самом деле не хотят вмешиваться.

Чтобы увидеть некоторые из старых инструкций по сообщению об ошибках, получите исторический репозиторий Linux . (Это git-репозиторий, содержащий все версии до появления git; в основном он содержит один коммит на релиз, поскольку он был восстановлен из tar-архивов). Файлы интересных объектов README, MAINTAINERSи REPORTING-BUGS.

Одна из интересных вещей, которую вы можете найти в Linux-0.99.12 README:

 - if you have problems that seem to be due to kernel bugs, please mail
   them to me (Linus.Torvalds@Helsinki.FI), and possibly to any other
   relevant mailing-list or to the newsgroup.  The mailing-lists are
   useful especially for SCSI and NETworking problems, as I can't test
   either of those personally anyway.

В процессах используются новостные группы (USENET) и (преимущественно) электронная почта. Ошибка «существовала» как нить, добавление [BUG REPORT]«или LINUX BUG REPORT» в тему было общим соглашением. Там не было никаких идентификаторов ошибок. Учитывая типичную пользовательскую базу, отчет об ошибках часто поставляется с патчем. Был использован один давно забытый программный инструмент: ibug(см. Ниже), кроме этого diff+ patch.

Из Linux Установка и начало работы (январь 1994 г., архив v2.0) >

2.6  The Design and Philosophy of Linux

 When new users encounter Linux, they often have a few misconceptions and
 false expectations of the system. Linux is a  unique  operating  system,
 and  it is important to understand its philosophy and design in order to
 use it effectively.  Time enough for a soapbox. Even if you are an  aged
 UNIX guru, what follows is probably of interest to you.

     In  commercial UNIX development houses, the entire system is devel-
 oped with a rigorous policy of quality assurance,  source  and  revision
 control systems, documentation, and bug reporting and resolution. [...]

     With  Linux,  you  can  throw  out  the entire concept of organized
 development, source control systems, structured bug reporting,  or  sta-
 tistical  analysis.   Linux  is,  and more than likely always will be, a
 hacker's operating system.(4)

                   [...]  For the most part, the Linux community communi-
 cates via various mailing lists and USENET newsgroups. A number of  con-
 ventions have sprung up around the development effort: for example, any-
 one wishing to have their  code  included  in  the  ``official''  kernel
 should  mail it to Linus Torvalds, which he will test and include in the
 kernel [...]

1992

Вот отчет об ошибке и исправление с декабря 1992 г. (0.98.6) на comp.os.linux: https://groups.google.com/d/topic/comp.os.linux/TwPA00rZMJo/discussion

В самом начале был список адресов электронной почты ml-linux-bugs (1992/1993) из этого раннего FAQ в дистрибутиве Slackware 1.01:

VI.01) Кажется, что $ # @! портированные на linux не работают правильно, что мне делать с сообщениями об ошибках?

[...] Обратите внимание, что мой список сообщений об ошибках «ml-linux-bugs@dg-rtp.dg.com» был прекращен. Оказывается, в Linux так мало ошибок, большинство из которых устраняются в группе новостей или через Linus, прежде чем я смогу их накапливать и публиковать. :) Вкратце: если есть ошибка в Linux или в портированном на Linux программном обеспечении, она обычно будет исправлена ​​в следующем уровне патча или версии.

Был список рассылки «linux-kernel» (который работал в оригинале vger), группы новостей alt.os.linux, затем comp.os.linux (который быстро разделился на иерархию в 1993 году ).

Этот ранний FAQ по Linux (v1.11, ноябрь 1992) из comp.os.linux также предлагает напрямую написать письмо Линусу.

В 1992 году Мэтт Уэлш (« Запуск Linux» , « Библия Linux» , TLDP ) объявилibug о помощи в создании отчетов об ошибках по электронной почте (по иронии судьбы, вы не могли запустить это в Linux в то время, так как в ней не было достаточно сетей для отправки электронной почты).

Шаблонlinux.temp сообщения об ошибке электронной почты также периодически публиковался на comp.os.linux, а обновления отчета об ошибках содержали шаблон обновленияlinux.fix.temp .

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

1993-1994

CVS-копии исходного кода ядра были обычным явлением, самое раннее, что я могу найти, это Дирк Стейнберг, из эпохи kernal-0.99.14. Первое заявление я могу найти с января 1993 года на Linux-активистов. Вы все еще можете найти архивные копии (1994) . Дирк также поддерживал двоичные файлы cvs и исходный код libc в CVS.

CVS не использовался для отслеживания ошибок в современном смысле, некоторые разработчики предпочитали его использовать, и патчи часто отправлялись в виде различий, созданных в cvs.

1995-1996

Примерно в это же время (октябрь 1995 г.) Дэвид С. Миллер начал использовать CVS для порта SPARC ядра Linux ( порт Linux / SPARC ). К февралю 1996 года несколько других разработчиков ядра независимо использовали CVS для отслеживания исправлений, от linux-kernel, этого потока и этого потока : Alan Cox, Stephen Tweedie, Kai Henningsen. (Вторая ветка сообщает, что Расс Нельсон говорит об отвращении Линуса к CVS.)

1997-1998

В апреле 1998 года, вскоре после рождения второго ребенка Линуса, снова возникла проблема с CVS, из linux-kernel смотрите эту подзадачу (Linus повторяет свою озабоченность по поводу CVS там непосредственно).

В декабре 1997 года Эндрю Триджелл выпустил jitterbug , веб-трекер ошибок. К июню 1998 года Алан Кокс выступил в защиту linux-патчей JitterBug на linux-kernel . Насколько я могу судить, это была первая настоящая система отслеживания ошибок, используемая Линусом и другими ключевыми разработчиками, к сожалению, экземпляр "linux-patches" больше не подключен.

В сентябре 1998 года Ларри МакЭвой впервые продвинул bitkeeper на linux-kernel .

1999 и позже

К 1999/2000 году часто задаваемые вопросы по lkml начали ссылаться (Q 1-16) на дерево CVS на (оригинальном) vger. Это было поддержано в то время Эндрю Триджеллом.

К декабрю 2001 года Jitterbug потерял самообладание, см. Этот поток ядра Linux , Линус, Алан Кокс и многие другие участвуют в обсуждении причин.

К январю 2002 года Линус начал интересоваться bitkeeper (уже используется командой ядра PowerPC Linux).

В феврале 2002 года Линус начал использовать Bitkeeper для дерева разработки 2.5.

В ноябре 2002 г. OSDL принимал Linux Bugzilla для 2,5 дерево было объявлено . (Если вы еще не прочитали ссылку на bugzilla в вопросе, перейдите и прочитайте ее сейчас, она содержит винтажные сообщения Линуса).

В апреле 2005 года Линус объявил об уходе от BitKeeper , в то время, когда он впервые назвал gitпо имени . Вскоре после того, как git стал способен к самостоятельному хостингу , Линус прекратил использовать BitKeeper и начал использовать git для ядра.

В декабре 2008 года был анонсирован патч-трекер Patchwork для linux-kernel , это независимый от SCCS веб-трекер-патч, который интегрируется со списками рассылки для отслеживания патчей и последующих действий. Его использование продолжается и по сей день, примерно 40 списков отслеживаются таким образом на https://patchwork.kernel.org/ , но не все из них активны.

Ссылки

Полезные ссылки:

• Суть распределенной работы: случай с ядром Linux (Jae Yun Moon, Ли Спроулл) http://www.firstmonday.org/ojs/index.php/fm/article/view/801/710 (ноябрь 2000 г.)
• Руководство по сообщению об ошибках в Linux (июль 1992 г.) http://www.linuxmisc.com/19-linux/c27174dbc2bf7185.htm
• Кеннет Р. Саборио, архив важных публикаций / электронных писем по Linux: http://www.informatica.co.cr/linux/index.htm (1991-2005)
• архивы ядра Linux с сегодняшнего дня (ноябрь 2014 г.) и до 1995 г. http://lkml.iu.edu/hypermail/linux/kernel/ (к сожалению, первое письмо отправлено в июне 1995 г., где администратор Крис Дент объявляет, что потерял ранее архивы ...) Архив LKML только восходит к 1996
• Фрагменты из linux-devel 1993-1994 от tsx11 http://www.ibiblio.org/pub/historic-linux/ftp-archives/tsx-11.mit.edu/Oct-07-1996/mail-archive/linux- devel / (игнорировать даты в URL и в файлах)
• Инструменты управления версиями : CVS to BK в ядре Linux , Sjaikh & Cornford (около 2003 г.)
• См. Также эту ветку Hacker News (март 2015 г.), посвященную 10-летию git: https://news.ycombinator.com/item?id=9263336

Я могу рассказать, как сообщения об ошибках обрабатываются для развития самого gitсебя.

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

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

Дело не в том, что «мы еще не нашли достаточно хороший трекер ошибок»;
Но это также не о том, что «у нас есть превосходный метод».

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

Наиболее формальной частью метода является еженедельное сводное сообщение о состоянии.
Это перечисляет вещи, которые в настоящее время происходят в различных ветвях, как короткие пункты. Для примера из разработки git посмотрите это в группе новостей, gmane.comp.version-control.gitотражающей список рассылки: что готовит в git.git

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

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