Re: [devel] I: no t8 for the time being

["Nikolay A. Fetisov" <naf@altlinux.ru>]

[-- Attachment #1: Type: text/plain, Size: 5459 bytes --]

Здравствуйте!

В Вт, 11/10/2016 в 22:45 +0300, Hihin Ruslan пишет:
> 
> ...
> Но возможно, стоит вначале продумать назначение ветки tx и путь 
> попадания пакетов в ветку px. 
> Мне кажется, сейчас путь не очень логичен. Наверное, было-бы 
> правильнее, что-бы  пакеты в ветку pх попадали из ветки tx, а не 
> напрямую.  
> 

Насколько помню основную идею, ветки pN - это база для выпуска 
официальных дистрибутивов. Сами дистрибутивы собираются из некоторого 
проверенного рабочего состояния pN, далее ветки pN служат для 
обновления официальных дистрибутивов. 
У официального дистрибутива есть ответственный, он решает, что и как 
попадает в ветку pN. По-видимому, при этом предполагается, что перед 
попаданием новых пакетов в ветку их работа _где-то_ _как-то_ 
тестируется ответственным - т.е. pN - это предполагающиеся стабильными
ветки.
Также, наверно, предполагается, что внутри ветки pN не собирающихся на
её базе пакетов нет.
Отсюда - предполагается достаточно консервативный подход к обновлению 
версий пакетов ради новых версий, с отдачей приоритета совместимости
работы фиксированного набора пакетов и беспроблемностью установки
обновлений по сравнению со свежестью версий.
(Ещё большая консервативность и стабильность до замшелости и 
неработоспособности на современном железе - это ветка c6.)


Sisyphus - это нестабильный репозиторий, что и как в нём обновляется и
добавляется - зависит от желаний участников проекта. Развал части 
системы или системы целиком при обновлении до текущего состояния 
Sisyphus - вполне возможен.

tN - база для выпуска неофициальных дистрибутивов и репозиторий для 
обновления тех, кому хочется более свежего ПО по сравнению с pN, но
меньше потенциальных проблем с совместимостью, чем в Sisyphus.
Соответственно, решение об обновлении пакетов в tN лежит на участниках
проекта, ответственность за работу и предварительное тестирование на 
совместимость - на них же.

И, отсюда же - предполагаемая квалификация пользователей веток,
от начинающих и/или не готовых возиться с совместимостью ПО для 
официальных дистрибутивов до готовых и умеющих решать проблемы
самостоятельно для Sisyphus. И, по-видимому, предполагаемый объём 
этой пользовательской базы - от широких масс у официальных 
дистрибутивов до достаточно узкого круга пользователей Sisyphus.

Т.е., при получении неудовлетворительного результата после запуска
apt-get update && apt-get -y dist-upgrade :
- пользователь Sisyphus рассмотрит это как возможность в очередной раз 
  проверить актуальность имеющихся у него процедур восстановления
  системы из актуальной резервной копии,
- пользователь tN - будет вспоминать, как восстанавливать систему из
  резервной копии,
- пользователь pN - будет вспоминать, есть ли у него вообще резервные 
  копии.


Соответственно, и различающийся подход для обновления версий ПО в
репозиториях. Как пример: обновить Apache до 2.4 в Sisyphus - 
замечательно. То, что при этом меняется mod_rpaf на mod_remoteip после 
обновления надо править руками конфигурацию, и заодно теряется 
возможность запуска  httpd2 в  контейнерах OpenVZ - это издержки 
Sisyphus и это нормально.

В tN (если такое обновление версии решит устроить майнтейнер пакета) -
то при установке нового Apache надо бы уже предусматривать
автоматическое переделывание  конфигурации 
rpaf.{conf,load} -> remoteip.{conf,load}, или хотя бы класть в пакет
шаблоны remoteip.{conf,load}. И далее разбираться с невозможностью 
запуска под OpenVZ, уже после попадания пакета в ветку и появлением 
жалоб.

А для конкретной ветки pN такое обновление версии пакета, по-видимому, 
уже делать нельзя - и это должно блокироваться ответственным за 
ветку pN.



Исходя из всего этого - логичнее всего была бы схема движения пакетов 
unstable (Sisyphus) -> staging (tN) -> stable (pN) (и это вроде бы 
изначально предполагалось по названиям релизов пакетов и пути 
обновления между репозиториями pN -> tN -> Sisyphus).
По факту оно не сложилось, и окончательно закрепилось политикой 
создания t7 через полгода после p7. 


Если сейчас не будет t8 - ну, значит, часть пользователей t7 уйдёт 
на p8, часть - переберётся на Sisyphus, часть уйдёт на другие
дистрибутивы. В итоге это скорее приведёт к некому числу дополнительно
выявленных (возможно, и исправленных) багов в t8, и снижением числа 
продвинутых пользователей проекта в целом.
Будут ли при этом активнее обновляться пакеты в p8 - вопрос сложный.
Если и будут - то ценой снижения стабильности самого p8.

Плюс, скорее всего появятся отдельные репозитории с локально собранными
новыми версиями пакетов на кодовой базе p8 - по аналогии с имеющимся
для, скажем, того же CentOS. В отсутствии "карманов", обсуждаемых 
с начала десятилетия - локального же качества и локального же
тестирования.


Т.е.: отказаться от t8 можно, и посмотреть, к чему в итоге приведёт 
такой эксперимент. Если бы ветки делались раз в год - было бы совсем
не страшно. При текущем цикле в 2-3 года - надо будет смотреть, куда
будут уходить продвинутые пользователи с плавно протухающего по 
версиям p8 - на нестабильный Sisyphus, или другие дистрибутивы. 

Ещё один вариант - перейти к годовому циклу выпуска (квази)стабильных 
веток. Т.е., делать t8 не сейчас, а весной 2017 г. Сейчас тогда с t7
желающие более-менее свежих версий и некоторой стабильности переходят 
на p8, с более-менее свежим ПО, далее через полгода - на появившийся 
t8, в 2018г - на p9 (а при его отсутствии - на новый t8.1), и т.д.



-- 
С уважением,
Николай Фетисов

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 181 bytes --]