Вопросы Теги

Как проект Ядра Linux отследил ошибки в Первые годы?

Корневой каталог - то, где большинство эмуляторов терминала запускается при открытии оболочки. Рабочий каталог - то, где Вы прямо сейчас. Можно обычно переходить непосредственно к корневому каталогу с командой cd и можно узнать то, с чем рабочий каталог pwd.

29
12.07.2019, 12:31
3 ответа

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

Не было контроля версий. Время от времени Линус устанавливал тарбол на FTP-сервере. Это был эквивалент "тега". Доступными инструментами в начале были RCS и CVS, а Линус их ненавидит, так что все просто присылали патчи по почте. (Есть объяснение от Линуса о том, почему он не хотел использовать CVS.)

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

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

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

Чтобы увидеть некоторые старые инструкции по созданию баг-репортажей, получите исторический репозиторий Linux. (Это git-репозиторий, содержащий все версии, существовавшие до появления git'а; в основном он содержит по одному коммиту на релиз, так как был восстановлен из тарболлов). Интересующие файлы включают 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.
20
27.01.2020, 19:38

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

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

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

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

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

Самая формальная часть метода - это еженедельное сообщение о состоянии состояния.
Он перечисляет вещи, которые в настоящее время происходят на различных ветвях как короткие предметы. Например, из разработки Git, см. Это в группе новостей GMANAECOMP.Version-Control.git Зеркальное отображение списка рассылки: Что готовит в Git.git

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


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

4
27.01.2020, 19:38

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

Начиная с Установка и начало работы с Linux (январь 1994 г., архивная копия версии 2.0) > 

 2,6 Дизайн и философия Linux

Когда новые пользователи сталкиваются с Linux, они часто имеют несколько заблуждений и
ложные ожидания системы. Linux - уникальная операционная система,
и важно понимать его философию и дизайн, чтобы
эффективно использовать его. Достаточно времени для мыльной коробки. Даже если вы в возрасте
Гуру UNIX, то, что следует ниже, вероятно, интересует вас.

В коммерческих домах разработки UNIX вся система является разработчика-
с жесткой политикой обеспечения качества, источника и пересмотра
системы управления, документация, отчеты об ошибках и разрешение. [...]

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

[...] По большей части, сообщество Linux communi-
обращается через различные списки рассылки и группы новостей USENET. Ряд кон-
вокруг усилий по развитию возникли инициативы: например, any-
желающий включить свой код в «официальное» ядро
должен отправить его по почте Линус Торвальдс, который он проверит и включит в
ядро [...]

1992

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

Очень рано появился список адресов электронной почты ml-linux-bugs (1992/1993), из этого раннего часто задаваемого вопроса в дистрибутиве 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 ).

Этот ранний часто задаваемый вопрос о Linux (v1.11 Nov 1992) из comp.os.linux также предлагает напрямую отправить Linus по электронной почте.

В 1992 Мэтт Уэлш ( Запуск Linux , Linux Bible , 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 сгенерированных diffs.

1995-1996

Примерно в это время (октябрь 1995) Дэвид С. Миллер начал использовать CVS для порта SPARC ядра Linux ( Порт Linux/SPARC ). К февралю 1996 года несколько других разработчиков ядра независимо использовали CVS для трека исправлений, начиная с linux-kernel этот поток и этот поток : Алан Кокс, Стивен Твиди, Кай Хеннингсен.

[1997-1998]

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

В декабре 1997 года Andrew Tridgell выпустил jitterbug , веб-трекер ошибок. К июню 1998 «участки Linux» JitterBug был защищен на ядре Linux Аланом Коксом . Это была, насколько я могу судить, первая фактическая система отслеживания ошибок, используемая Linus и другими ключевыми разработчиками, к сожалению, экземпляр «linux-patches» больше не в сети.

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

1999 и более поздние

С помощью 1999/2000 lkml FAQ начал ссылаться (Q 1-16) на дерево CVS на (исходном) vger. Это в то время поддерживал Эндрю Триджелл.

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

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

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

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

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

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

Ссылки

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

15
27.01.2020, 19:38

Теги

Похожие вопросы