Насколько полезно сообщать об ошибках в отношении пакетов «Стабильный»?

Если ошибка исправлена ​​в более новой версии (Testing или Unstable) пакета, есть ли надежда на то, что исправление может довести ее до «Стабильного» до следующего основного выпуска? Я полагаю, что нет, если только это не имеет серьезности. Могила или тому подобное.

Действительно ли это полезно для разработчиков, работающих над версиями, которые, возможно, два или даже три года новее? Я хотел бы быть настолько полезен в отчетах об ошибках, насколько смогу, и с этой целью я хотел бы установить установку Sid на виртуальной машине, чтобы я мог попытаться воспроизвести мои стабильные ошибки перед их сообщением, но даже если ошибка все еще присутствует в более новой версии, будут ли разработчики уделять большое внимание ошибке, сообщаемой против Stable?

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

2 Solutions collect form web for “Насколько полезно сообщать об ошибках в отношении пакетов «Стабильный»?”

Чтобы сначала уточнить, существует разница между дистрибутивным (двоичным) пакетом и исходным исходным пакетом. Хотя некоторые дистрибутивы разбивают репозитории на, например, «тестирование», «неустойчивое» и «стабильное», а некоторые разработчики также поддерживают «стабильную», «неустойчивую», «ночную» и т. Д. Версии, это не то же самое ( но номера версий соответствуют).

Также обратите внимание, что здесь «исходный пакет» не относится к пакету дистрибутива -src . Он относится к исходному источнику, распределенному независимо от дистрибутива. То есть это пакеты, которые вы обычно не используете напрямую – дистрибутив переупаковывает их в свою двоичную (и -src ) форму.

Например, я поддерживаю исходный источник foobar ; текущий стабильный исходный пакет – 1.2.4 и текущий нестабильный исходный пакет, 1.2.5 . Debian (не я) пакеты для распространения; их текущая стабильная версия репо – 1.2.3 а их текущая версия репо – 1.2.5 . Я (оригинальный разработчик) не несем ответственности за пакет debian, или в какой исходной версии находится пакет репо. Я не делаю компиляцию или упаковку дистрибутивной бинарной версии. Я просто поддерживаю исходный источник.

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

Если ошибка исправлена ​​в более новой версии (Testing или Unstable) пакета, есть ли надежда на то, что исправление может довести ее до «Стабильного» до следующего основного выпуска?

Исправления очень редко обращаются, то есть если ваш дистрибутив-стабильный пакет равен 1.2.3, и вы знаете, что 1.2.5 имеет исправление, то, если следующий стабильный дистрибутив не равен 1.2.5, он не будет содержать исправление. Т.е., если дистрибутив выпускает 1.2.4 в качестве следующей стабильной, исправление с 1.2.5 не будет возвращено обратно, поэтому ошибка все равно будет там.

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

Действительно ли это полезно для разработчиков, работающих над версиями, которые, возможно, два или даже три года новее?

Это зависит от того, исправлена ​​ли ошибка или нет. Точка управления версиями заключается в том, что она исправлена ​​- вы не изменяете версию 1.2.3 после ее выпуска, несмотря ни на что. Если вы исправите что-то в 1.2.3, это исправление появится в следующей версии. Если это то, что было нарушено в течение многих лет, этот выпуск может составлять 1,2,6 и т. Д.

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

Во-первых, отчет об ошибках – это, как правило, хорошая идея, даже если это часто неблагодарная работа, как и многое в бесплатном программном обеспечении.

Чтобы привести ваши вопросы в порядок,

Если ошибка исправлена ​​в более новой версии (Testing или Unstable) пакета, есть ли надежда на то, что исправление может довести ее до «Стабильного» до следующего основного выпуска?

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

Действительно ли это полезно для разработчиков, работающих над версиями, которые, возможно, два или даже три года новее?

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

Имейте в виду, что даже если нестабильная версия является самой последней версией, ошибка может быть исправлена ​​в версии разработки, поэтому, если вы не тестируете текущую версию программного обеспечения (обычно доступную только из репозитория программного обеспечения), вы можете ' Убедитесь, что ошибка не исправлена. Тем не менее, я часто слишком ленив, чтобы протестировать абсолютно полный код, потому что он не был упакован, и мне нравится работать с упакованным программным обеспечением. Но YMMV.

Если ошибка исправлена ​​в более поздней версии программного обеспечения, я обычно не сообщаю об этом. Теоретически это можно сделать, но разработчикам, занимающимся разведкой и разработкой, наверняка это не понравится, и пакеты разработчиков программного обеспечения Debian также маловероятны.

Наконец, вы пишете:

но даже если ошибка все еще присутствует в более новой версии, будут ли разработчики действительно уделять большое внимание ошибке, сообщаемой против Stable?

Я не понимаю, что это значит. Если ошибка присутствует в более новой версии, сообщите об этом в новой версии. Зачем сообщать об этом в отношении стабильной версии?

  • Как сделать эти старые графические интерфейсы (например, установщик debian / arch)
  • Как вы выбираете дистрибутив?
  • Как настроить дистрибутив Gnu / Linux для детей?
  • Изменение удаленного дистрибутива Linux при сохранении данных
  • Построить полное Distro с LFS
  • Как распределить дистрибутивы?
  • Где все ISO-файлы Debian?
  • Получение противоречивой информации о дистрибутиве Linux
  • Как определить, является ли сборка основанной на Debian?
  • Совместное использование документов Apache-httpd в нескольких дистрибутивах Linux?
  • Параметры прошивки маршрутизатора с открытым исходным кодом?
  • Что делает дистрибутив GNU и есть ли дистрибутивы Linux, которые не являются GNU?
  • Linux и Unix - лучшая ОС в мире.