On Fri, May 22, 2009 at 04:59:14PM +0300, Igor Vlasenko wrote:
> On Fri, May 22, 2009 at 04:43:17PM +0400, Alexey Novikov wrote:
> > Согласен, в чем-то Вы правы. Может стоит даже сделать наоборот.
> > Обновленные пакеты в течении скажем недели собираются в Сизифе,
> > если в течении допустим 7 дней с момента появления/обновления
> > пакета в Сизифе на него не поступило баги с severity > minor,
> > то пакет рассматривается как кандидат в testing. Так лучше?
> 
> Алексей, это было бы хорошо, будь у нас 
> так называемые "карманы", описание которых можно нагуглить
> в рассылке. 
> Коротко - это аналог SuSE factory, маленькие "карманные"
> репозитарии, куда любой желающий может собрать все, что угодно.
> 
> Сейчас даже при большом желании собрать что-то для 
> бранча очень трудно.
> 1000 раз повторялось, начиная с запретительных acl -
> то что хочу видеть в бранче, выложить не могу,
> а то что могу - не считаю нужным.
> 
> И предполагать, что RM компетентнее мейнтейнера
> по его пакетам --- тоже очень часто ошибочно.
> 
> Мне кажется, дискуссия порочна в основаниях.
> И так бранч огорожен так, что в него тяжело и неприятно собирать --
> любые повышения барьеров еще больше отрежут бранчи от
> community. 
> 
> Это обсуждалось весной.
> Господа,
> Давайте сделаем рабочие карманы!

У меня не сформировалось ясного представления, зачем нужны эти карманы,
какие принципиальные проблемы они решают, и как их реализовать.

Можно сделать в задании репозитарий RPMS.hasher.  С ним будет маленькая
проблема: могут появиться неудовлетворенные зависимости на файлы между
RPMS.hasher и основным репозитарием.  Дело в том, что когда генерируется
основной репозитарий, ненужные файлы исключаются (и на этом удается
сэкономить несколько мегабайтов, которые каждый раз скачиваются при
apt-get update).  Я время от времени думаю над этой проблемой, но пока
не придумал хорошего решения.

Сейчас проверка ACL в некоторых случаях выполняется до, а не после
сборки пакетов.  Это делает невозможным NMU.  Я считаю, что проверку
ACL нужно выполнять после сборки пакетов.  Атаки на распределение
сборочных ресурсов -- это слишком неинтересно и глупо.  Пока таких
атак у нас не было.  Правда, пока мы и не допускаем к git.alt абсолютно
всех желающих.

> Сейчас обсуждается, что если добавить кучу дорогого железа,
> можно немножко улучшить качество пакетов.

Можно улучшить очень сильно, если считать собираемость пакетов
комплексным показателем пригодности пакетов.

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

Ага, то есть содержимое карманов не предназначено для помещения
в репозитарий.  Всё равно с этим есть проблемы.  Когда мы начинаем
собирать карман, надо делать lock репозитария на чтение, чтобы во
время установки пакетов не оказалось, что репозитарий уже изменился.
И надо ли брать такой лок per package или per карман, это всё непростые
вопросы.

> Они сделают эту же работу, но гораздо эффективнее.
> Многие аспекты QA роботами принципиально невозможно выполнить.
> 
> А пока в бой идут одни старики :)
> Даешь рабочий карман!!! :)