LinuxDoc.RuЛарс Вирзениус (Lars Wirzenius), один из первых мэйнтенеров Debian GNU/Linux, вовлечённый в развитие Linux с первых дней существования проекта, и Расс Олбери (Russ Allbery), отвечающий за сопровождение ряда подсистем Debian, выступили с предложением по изменению подхода к поддержанию репозитория Debian Testing. Для того чтобы избежать многомесячных заморозок репозитория, не допускающих внесения обновлений, предлагается поддерживать Debian Testing в состоянии постоянно готовым к релизу, т.е. не допускать нахождения незакрытых ошибок, помеченных как блокирующих релиз.
В процессе подготовки Wheezy стадия заморозки продолжалась 10 месяцев и потребовала исправления около 700 блокирующих релиз ошибок, что по мнению авторов предложения недопустимо долго и неэффективно. В качестве максимально допустимого времени нахождения Testing в состоянии заморозки называется 2 месяца. Для увеличения качества репозитория testing также предлагается более активно использовать средства автоматизированного тестирования и методы непрерывной интеграции. В итоге удастся не только сократить время подготовки релиза, но и повысить актуальность репозитория Testing, сделав его более пригодным для непосредственного использования.
В случае выявления блокирующих релиз проблем в репозитории Testing, вторичные пакеты предлагается удалять из репозитория, после истечения определённого незначительного таймаута, выделяемого для устранения ошибки. Для первичных пакетов, которые нельзя так просто удалить, могут применяться более жесткие методы, вплоть до блокирования любых иных исправлений для данных пакетов и прекращения загрузки обновлений в unstable до исправления ошибки. При преодолении определённого порога критических ошибок в репозитории также могут применяться мини-заморозки Testing, временно запрещающие перенос новых пакетов.
Изначальное блокирование проблемных пакетов в Testing позволит возвести исправление важных проблем в ряд высокоприоритетных задач, которые не могут быть отложены, что увеличит степень ответственности мэйнтейнеров пакетов и усилит их вовлечение в подготовку новых выпусков. При подобном подходе для окончательной стабилизации может быть достаточно заморозки на несколько недель. Для ускорения доведения релиза до готовности также предлагается сформировать набор эталонных установочных комплектов пакетов (почтовый сервер, рабочая станция, web-сервер и т.п.), рассматривая их как первичные критерии стабильности релиза и допуская наличие несущественных ошибок в сторонних пакетах.
В процессе подготовки Wheezy стадия заморозки продолжалась 10 месяцев и потребовала исправления около 700 блокирующих релиз ошибок, что по мнению авторов предложения недопустимо долго и неэффективно. В качестве максимально допустимого времени нахождения Testing в состоянии заморозки называется 2 месяца. Для увеличения качества репозитория testing также предлагается более активно использовать средства автоматизированного тестирования и методы непрерывной интеграции. В итоге удастся не только сократить время подготовки релиза, но и повысить актуальность репозитория Testing, сделав его более пригодным для непосредственного использования.
В случае выявления блокирующих релиз проблем в репозитории Testing, вторичные пакеты предлагается удалять из репозитория, после истечения определённого незначительного таймаута, выделяемого для устранения ошибки. Для первичных пакетов, которые нельзя так просто удалить, могут применяться более жесткие методы, вплоть до блокирования любых иных исправлений для данных пакетов и прекращения загрузки обновлений в unstable до исправления ошибки. При преодолении определённого порога критических ошибок в репозитории также могут применяться мини-заморозки Testing, временно запрещающие перенос новых пакетов.
Изначальное блокирование проблемных пакетов в Testing позволит возвести исправление важных проблем в ряд высокоприоритетных задач, которые не могут быть отложены, что увеличит степень ответственности мэйнтейнеров пакетов и усилит их вовлечение в подготовку новых выпусков. При подобном подходе для окончательной стабилизации может быть достаточно заморозки на несколько недель. Для ускорения доведения релиза до готовности также предлагается сформировать набор эталонных установочных комплектов пакетов (почтовый сервер, рабочая станция, web-сервер и т.п.), рассматривая их как первичные критерии стабильности релиза и допуская наличие несущественных ошибок в сторонних пакетах.
