On Mon, Nov 14, 2005 at 08:40:37PM +0300, Денис Смирнов wrote:
> MT> Период жизни не меньше 3-х лет.

Со средами сборки это реально, но у нас, например, на сейчас
нет настолько старых систем. (понятно, что их появление при
нормальном подходе -- дешевле, чем гонка обновлений)

> MT> Насколько часто вопрос более сложный. Мне хватает раз в 2 года.
> Ясно. То есть при таком режиме одновременно необходимо
> поддерживать не более двух веток, причём одну из них можно
> в виде "security fixes and critical bugfix only".

Угу.  Но с прочерченными сроками ожидаемого окончания поддержки,
если речь не только о "своём цеху".  Для себя-то хоть с закрытия
известных проблем начать, а там уж по оценке усилий выводы делать.

> Этого, вместе с наличием в updates фиксов к свежим багам
> достаточно?

С этого надо начинать.  Дима говорит, что с координацией
sec team поможет, если люди хорошие будут.

Собственно, мы попытались (с моей недожареной подачи)
организовать такой процесс; первая организованная пачка
обновлений по диминой сводке открытых проблем (выбрав наиболее
критичные IIRC) с сопутствующими анонсами была подписана 
"при поддержке EMT", чего в опубликованных анонсах не было.

Возобновление работ нашего народу именно по апдейтам
целенаправленно с тех пор не произошло; хотя дело не
в наивной рекламе именно себя, просто апдейты -- вещь
сугубо неинтересная, выгребная яма своего рода.

Соответственно Дима вполне мог писать "спонсировано
Димой Левиным", и это было бы 1) честно; 2) указывало 
на возможность получить лишнее внимание такой работой.

Короче говоря, на сейчас если строить здесь более общественную
инфраструктуру -- получается

- security-team@ как рассылка (сейчас алиас);
- перебраться туда теми, кто:
  + отслеживает проблемы и может быстрее проинформировать о них,
    чем майнтейнер узнает сам;
  + является майнтейнером, поддерживающим свои пакеты и в stable;
  + является заинтересованным в заткнутости дырок в используемых
    пакетах, в т.ч. других сборщиков (на момент выпуска/текущий);
- попросить Диму составить список текущих нерешённых критичных
  проблем в ALM2.4+updates;
- проверить наличие [попыток] решений в backports/2.4 и их
  пригодность;
- приступить к разгребанию обретённого счастья, благо во многих
  случаях патчи уже доступны (выковыриваются из RHEL или Debian);
- при уверенности в отсутствии регрессов в пакете вливать
  в /i/u/2.4, иначе с описанием подозрительных мест --
  в /i/b/2.4 с тем, чтобы через несколько дней тестирования 
  рекомендовать перекладывание в u/M/2.4 или отзыв;
- напустить на /u/M/2.4 робота по чтению вслух changelog'ов
  в security-announce@, уж если человеческого слова не хватает.
  Соответственно мои changelog'и уже довольно давно для этого 
  готовы.

PS: пошли в devel@?

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/