[devel] I: no t8 for the time being

[devel] I: no t8 for the time being

[Igor Vlasenko]

Господа,

Я недавно поднимал вопрос, делать ли нам t8.
Заинтересованный народ в рассылке не отозвался,
t8 дело накладное (его надо будет администрировать 
и синхронизировать, я и так уже синхронизирую p6->t6 и p7->t7,
( кому интересно - скрипты на
http://git.altlinux.org/people/viy/packages/repodiff.git )
а лично свои проблемы с p8 я смог решить,
получив у Андрея (cas@) acl на интересующие меня пакеты в p8.

Так что вместо t8 предлагается альтернатива -
берите в p8 у Андрея (cas@) acl на интересующие вас пакеты.

-- 

I V

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

[Ruslan Hihin]

Как-бы не правильно. На t-ветках можно обкатывать решения для p-веток (в Сизифе все не проверить),
-- 
Простите за краткость, создано в K-9 Mail.

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

[Michael Shigorin]

On Tue, Oct 11, 2016 at 12:19:29PM +0000, Ruslan Hihin wrote:
> Как-бы не правильно. На t-ветках можно обкатывать решения для
> p-веток (в Сизифе все не проверить),

Это понятно -- речь о том, кто и почему заинтересован
в достаточной мере, чтобы тратить минимум усилий по
синхронизации репозиториев (p5/5.1 на этом погорели,
что было усугублено разъездом по ядру и _различными_
проблемами с тогдашними 2.6.30 и 2.6.32).

Обычно новый t* тащили мы с viy@ и mithraen@; на сейчас
у меня особой необходимости нет (при набранном cas@
опыте решается в рамках p8 и тестовых заданий), теперь
и у viy@ мотивация тащить форк поубавилась.

Т.е. технической проблемы нет, вопрос только в том,
кто готов ежесуточно уделять дольку внимания (cron
не справится с проблемами, которые порой бывают).

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

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

[Hihin Ruslan]

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

Здравствуйте Michael Shigorin
  В сообщении от 11 октября 2016 Michael Shigorin написал(a):

> Обычно новый t* тащили мы с viy@ и mithraen@; на сейчас
> у меня особой необходимости нет (при набранном cas@
> опыте решается в рамках p8 и тестовых заданий), теперь
> и у viy@ мотивация тащить форк поубавилась.

Ну, не знаю ;-).
Как только Сизиф отойдёт от p8 достаточно далеко, всё равно 
придётся делать. 
cas@ конечно молодец, но всё он всё равно протестировать не 
сможет. 
С другой сторны, каждый раз дёргать его то-же как-то не очень. Да 
и по факту поддержка ветки tx всегда более продолжительная, чем 
px.
Но возможно, стоит вначале продумать назначение ветки tx и путь 
попадания пакетов в ветку px. 
Мне кажется, сейчас путь не очень логичен. Наверное, было-бы 
правильнее, что-бы  пакеты в ветку pх попадали из ветки tx, а не 
напрямую.  
Хотя возможны варианты,

-- 
  А ещё говорят так  (fortune): 
 
Man must shape his tools lest they shape him. -- Arthur R. Miller 
________________________________________________________________________
С уважением Хихин Руслан 

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

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

[Sergey Afonin]

On Tuesday 11 October 2016, Hihin Ruslan wrote:

> cas@ конечно молодец, но всё он всё равно протестировать
> не сможет.

Можно сделать задание для p8 и объявить в рассылке/на форуме.
Заинтересованные могут тоже попробовать перед отправкой.

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

-- 
С уважением, Сергей Афонин.

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

[Hihin Ruslan]

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

Здравствуйте Sergey Afonin
  В сообщении от 12 октября 2016 Sergey Afonin написал(a):
> Можно сделать задание для p8 и объявить в рассылке/на форуме.

Кстати - очень то-же интересный момент . То-ли в рассылке, то-ли 
на форуме, а стандартного места, о котором все договорились и 
знают - нет ;-)

-- 
  А ещё говорят так  (fortune): 
 
Success is a journey, not a destination. 
________________________________________________________________________
С уважением Хихин Руслан 

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

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

[Anton Farygin]

11.10.2016 15:19, Ruslan Hihin пишет:
> Как-бы не правильно. На t-ветках можно обкатывать решения для p-веток (в Сизифе все не проверить),
>

Как показывает практика и время - в p ветку больше всего проблем вносил 
как раз Андрей (не специально естественно), т.к. всё знать невозможно, а 
протестировать обновление во сех вомзжных конфигурациях не получается. 
На мой взгляд только мейнтейнер пакета способен более-менее качественно 
обеспечить его поддержку в стабильной ветке.

Т.е. - t ветку надо делать, но боюсь что она не будет тестовой для p 
ветки, а будет жить отдельно (как и раньше).

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

[Nikolay A. Fetisov]

[-- 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 --]

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

[Хихин Руслан]

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

Здравствуйте !
On Thursday 13 October 2016 10:24:18 Nikolay A. Fetisov написал(а):

> Ещё большая консервативность и стабильность до замшелости и 
> неработоспособности на современном железе - это ветка c6.

Если отвлечься от постороннего, то МСВС  ещё более замшелый с этой точки 
зрения, но они (вынужденно) портируют свежие фичи в старые пакеты, в том 
числе и в ядро. И к великому удивлению многих неосведомлённых, такая политика 
приводит к тому, что проблем с поддержкой железа (даже достаточно 
современного) там не наблюдается. 
Другое дело, что там есть пополняющийся список поддерживаемого оборудования, 
на котором ОС должна всегда работать. И тянет эту работу коллектив, который 
можно пересчитать по пальцам одной руки (если убрать начальство и т.п.).

В общем я хочу сказать, что c6 требует совсем другой политики, и он тут не в 
тему ;-)

-- 
C уважением, Хихин Руслан.

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

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

[Nikolay A. Fetisov]

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

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

В Чт, 13/10/2016 в 13:04 +0300, Хихин Руслан пишет:
> ....
> В общем я хочу сказать, что c6 требует совсем другой политики, и он
> тут не в тему ;-)
> 

Почему - не в тему? Вопрос именно в политиках в разных ветках.

Есть набор веток/репозиториев. У каждой ветки (в т.ч. Sisyphus) - своя
политика, свои правила добавления / обновления / удаления пакетов. 
Для Sisyphus - достаточно желания майнтейнеров и выполнения формальных 
автоматически проверяемых критериев, 
для tN - дополнительно заинтересованности майнтейнеров в поддержке
более-менее стабильных систем, 
для pN - правила определяются ответственным за ветку и поставленными
перед ним задачами, 
для c6 - ещё и внешней сертифицирующей  организацией.

Разные ветки - разные политики, и разные категории пользователей.

Разделение веток t6/p6 с разными политиками для них появилось как 
следствие проблем с веткой 5.1 - в т.ч. из-за политик обновления 
её состояния.
Итогом сейчас имеется более стабильные и менее обновляемые p6/p7,
и менее стабильные и более обновляемые t6/t7. Сложившиеся правила
игры пользователям известны и (наверное) понятны.

В отсутствии t8 пользователям t7 сейчас, очевидно, будет предложено
уходить на p8. Вопрос, куда они будут уходить дальше с p8 - через 
полгода/год, когда стабильно-устаревающее состояние p8 будет уже 
заметно отличаться от актуально-нестабильного Sisyphus.

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

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

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

[Igor Vlasenko]

On Thu, Oct 13, 2016 at 05:04:48PM +0300, akv@altlinux.org wrote:
> Кто эти загадочные люди, которые пользовались веткой t8?

Повод им в рассылке отозваться :)

> Каждый раз когда я туда смотрел пакеты в p8 были актуальнее.

Здесь небольшое недоразумение. Многие майнтайнеры выкладывали
напрямую в pX, и такие пакеты попадают в tX c задержкой в день-два.

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

надо бы все-таки переделать эту схему и запускать
робота по крону -- за пять лет эксплуатацмм
проблем не выявлено.
завести еще одного робота cronsync и вписать его в @qa_tX.

-- 

I V

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

[Igor Vlasenko]

On Thu, Oct 13, 2016 at 03:26:08PM +0300, Nikolay A. Fetisov wrote:
> Разные ветки - разные политики, и разные категории пользователей.
> 
> Разделение веток t6/p6 с разными политиками для них появилось как 
> следствие проблем с веткой 5.1 - в т.ч. из-за политик обновления 
> её состояния.
> Итогом сейчас имеется более стабильные и менее обновляемые p6/p7,
> и менее стабильные и более обновляемые t6/t7. Сложившиеся правила
> игры пользователям известны и (наверное) понятны.
> 
> В отсутствии t8 пользователям t7 сейчас, очевидно, будет предложено
> уходить на p8. Вопрос, куда они будут уходить дальше с p8 - через 
> полгода/год, когда стабильно-устаревающее состояние p8 будет уже 
> заметно отличаться от актуально-нестабильного Sisyphus.

Я не против t8, и готов быть его соадминистратором.

Однако хотелось бы понять, скольким разработчикам он
нужен (сколько человек в него готовы собирать пакеты).
Когда я 3 недели назад спрашивал в рассылке,
будет ли t8, то в той теме желающих t8 не нашлось,
чтобы меня поддержать, я смирился и обошелся доступом к p8.

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

-- 

I V

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

[Nikolay A. Fetisov]

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

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

В Чт, 13/10/2016 в 17:04 +0300, akv@ пишет:
> ...
> 
> Кто эти загадочные люди, которые пользовались веткой t8?

Гарантированно никто - за отсутствием сейчас таковой.

> Каждый раз когда я туда смотрел пакеты в p8 были актуальнее.
> ...

Если смотреть по текущему состоянию, сравнивая наборы src.rpm,
и считая одинаковыми версии, отличающиеся только суффиксами 
веток в релизах, то:

для пары репозиториев t6 / p6:

                     |      t6  |     p6
---------------------+----------+----------
всего пакетов        |   12907  |  11692
нет в p6/t6          |    1242  |     27
собрано для t6       |     572  |     65
собрано для p6       |     769  |    861
одинаковые версии    |   10721  |  10721
более новые версии   |     941  |      3
более старые версии  |       3  |    941


для пары репозиториев t7 / p7:

                     |      t7  |     p7
---------------------+----------+----------
всего пакетов        |   15334  |  14990
нет в p7/t7          |     345  |      1
собрано для t7       |     663  |    335
собрано для p7       |     939  |    990
одинаковые версии    |   14124  |  14124
более новые версии   |     845  |     20
более старые версии  |      20  |    845


В t7 по сравнению с p7 нет пакета altlinux-release-p7,
и более старые версии у kernel-image-un-def и его модулей.


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

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

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

[Hihin Ruslan]

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

Здравствуйте Igor Vlasenko
  В сообщении от 13 октября 2016 Igor Vlasenko написал(a):
> On Thu, Oct 13, 2016 at 03:26:08PM +0300, Nikolay A. Fetisov 
wrote:
> > Разные ветки - разные политики, и разные категории
> > пользователей.
> >
> > Разделение веток t6/p6 с разными политиками для них
> > появилось как  следствие проблем с веткой 5.1 - в т.ч. из-за
> > политик обновления её состояния.
> > Итогом сейчас имеется более стабильные и менее обновляемые
> > p6/p7, и менее стабильные и более обновляемые t6/t7.
> > Сложившиеся правила игры пользователям известны и (наверное)
> > понятны.
> >
> > В отсутствии t8 пользователям t7 сейчас, очевидно, будет
> > предложено уходить на p8. Вопрос, куда они будут уходить
> > дальше с p8 - через полгода/год, когда
> > стабильно-устаревающее состояние p8 будет уже заметно
> > отличаться от актуально-нестабильного Sisyphus.
>
> Я не против t8, и готов быть его соадминистратором.
>
> Однако хотелось бы понять, скольким разработчикам он
> нужен (сколько человек в него готовы собирать пакеты).
> Когда я 3 недели назад спрашивал в рассылке,
> будет ли t8, то в той теме желающих t8 не нашлось,
> чтобы меня поддержать, я смирился и обошелся доступом к p8.
>
> Поэтому прошу всех, кому нужен t8, высказаться.
> Чем больше народу, тем более понятно, зачем нужен t8.

Я за t8 ;-)

На самом деле, мне бы хватило t7/t8, если-бы мои пакеты потом 
попадали автоматом (например через неделю) в p7/p8,  
Например, если не выявлены какие-то ошибки, которые-бы мешали им 
там оказаться. Ну типа, если я что-то заметил сам, или явная 
бага на пакет (у нас кстати в багзиле есть ветки для t7/t8 ?), 
то я обращаюсь к мантейнеру p7/p8 с просьбой не перекладывать 
пакет в ветку p7/p8. 
Иначе какой-то робот перекладывает их из t7/t8 в p7/p8. 
Естественно, мантейнеры p7/p8 могут и сами заблокировать каие-то 
пакеты как навечно, так и на какое-то время.

-- 
  А ещё говорят так  (fortune): 
 
Semper Fi, dude. 
________________________________________________________________________
С уважением Хихин Руслан 

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

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

[Nikolay A. Fetisov]

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

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

В Чт, 13/10/2016 в 22:46 +0300, Igor Vlasenko пишет:
> ...
> Однако хотелось бы понять, скольким разработчикам он
> нужен (сколько человек в него готовы собирать пакеты).

Можно посмотреть, наверное, кто собирал пакеты для t6/p7 и t7/p7. 
Правда, есть вопросы с тем, как учитывать имеющие пакеты *M70P* в t7
(*M60T* в t6) и наоборот. Здесь возможны два варианта - майнтейнер 
собрал пакет для p7, и далее сам запустил копирование его в t7, или
это потом сделал по своей инициативе ответственный за ветку. 

Список я какой-то попробовал сделать, но нужен ли он здесь, исходя из 
его длины - не знаю.

Так - для t7:
- собирали пакеты только в t7 - 11 человек (включая робота cronport@) ,
- собирали пакеты и для t7, и для p7 - 15 человек, из них
  преимущественно в t7 - 5, примерно поровну - 3.
Т.е., некая грубая оценка - t7 нужен 15-20 участникам проекта.


Для p7:
- собирали пакеты только в p7 - 27 человек,
- собирали пакеты и для p7, и для t7 - 11 человек, из них
 
преимущественно в p7 - 4, примерно поровну - 3.
Т.е., некая грубая
оценка - p7 интересен 30-35 участникам проекта.



Для t6:
- собирали пакеты только в t6 - 20 человек (считая cronbuild и
  cronport за одного),
- собирали пакеты и для t6, и для p6 - 17 человек, из них
 
преимущественно в t6 - 2, примерно поровну - 10.
Т.е., некая грубая
оценка - t6 нужен 20-25 участникам проекта.

Для p6:
- собирали пакеты только в p6 - 31 человек,
- собирали пакеты и
для p6, и для t6 - 11 человек, из них
  преимущественно в p6 - 6,
примерно поровну - 2.
Т.е., некая грубая оценка - p7 интересен 35-40
участникам проекта.


Чисто для сравнения, в текущем Sisyphus из 17555 лежащих в нём src.rpm,
собрано/обновлено:
за последний год    -  8809 пакетов 68 разными людьми,
за последние 2 года - 10691 пакетов 78 разными людьми,
за последних 3
года - 12145 пакетов 85 разными людьми.

Обновления пакетов в t7/p7 считал вчера, это где-то 10-12% от 
обновлений в Sisyphus. 


> Поэтому прошу всех, кому нужен t8, высказаться.
> Чем больше народу, тем более понятно, зачем нужен t8.

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

Лично мне стабильные ветки интересны 
0. возможностью сделать на базе них в некий момент виртуальный сервер, 
   под фиксированный набор задач и который после первоначальной 
   настройки спокойно бы работал без существенных изменений 
   конфигурации и состава установленных в нём пакетов.
При этом этот виртуальный сервер далее:
1. можно периодически и _хотя бы_ полу-автоматически обновлять без 
   особого риска получить в итоге что-то нерабочее из ранее 
   установленного и настроенного;
2. в которые можно как-нибудь потом поставить что-либо дополнительное,
   без необходимости при этом по зависимостям обновлять полсистемы,
   см. п. 1;
3. в отсутствии этого чего-то в стабильной ветке - это что-то
   можно пересобрать под стабильную ветку и установить в систему, 
   см. п. 2;
4. и, если это что-то представляет потенциальный интерес для 
   окружающих - добавить эту сборку в эту стабильную ветку.
Последний пункт, очевидно, опционален.

При этом для п. 0, 2 и 3 мне зачастую интересно, чтобы в стабильной
ветке были более-менее актуальные версии ПО. Т.е., где-то год-полтора
назад для части виртуальных серверов мне приходилось выбирать 
Sisyphus - по соотношению проблем портирования свежих версий в t7
и работы на нестабильной ветке.


Насколько нужен сейчас t8 - честно говоря, не знаю. После разных 
подсчётов по пакетной базе [tp][67] сомнения viy@ и mike@ мне
более чем понятны. У меня изначально были несколько другие
представления о ситуации.
Формальная разница t7/p7 (t6/p6) только в политиках сборки туда 
пакетов
, при этом из t6/t7 "расширенная" версия p6/p7 получилась,
скажем так,
не очень. Ну и разрыв в полгода должен затруднять 
сопровождение.
В
обратном направлении, p8 от отсутствия параллельного ему t8
вряд ли
будет сильно страдать. Если при этом будет добавлен 
ещё какой-либо
автоматизированный механизм для отправки пакетов 
в p8 - то p8 вообще
ничего не заметит.


Т.е.: сказать, что лично мне очень нужен t8 - не могу. На ближайшее
время под мои задачи вполне сгодится и p8. 

Опять же, лично мне более неприятна другая сторона текущей ситуации
с ветками: у нас, по факту, что t7/p6, что t7/p7 - это ветки LTS,
со сроками жизни в 5-6-7 лет. t6 появилась в 2011-ом, t7 уже 
исполнилось 3 года. p8 вышла в мае - p9 будет в 2019-ом?
Хотелось бы чего-то стабилизированного (стабильными пусть будут pN), 
но выходящего где-то раз в год. Исходя из ограниченности ресурсов - 
с ограниченным сроком жизни в 1.5-2 года. 
(Это именно лично мои мечты, исходя из моих вариантов использования
стабильных веток.)
Правда, трудоёмкость поддержки таких веток будет заметно выше, чем
парных tN/pN. Но, по-идее, они будут востребованы как минимум 
продвинутыми пользователями настольных систем - они более всего 
затронуты старыми версиями пакетов в стабильных веток.


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

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