Re: [devel] уже давно не о документации

[Sergey Alembekov <rt@aspirinka.net>]

On Sat, Feb 05, 2011 at 11:03:30PM +0300, Dmitry V. Levin wrote:
> On Sat, Feb 05, 2011 at 10:47:27PM +0300, Anton Farygin wrote:
> > 05.02.2011 10:09, Aleksey Novodvorsky пишет:
> > >5 февраля 2011 г. 7:34 пользователь Anton Farygin написал:
> > >>04.02.2011 22:34, Dmitry V. Levin пишет:
> > >>>Т.н. карманы можно было бы реализовать 
> > >>>ещё в прошлом году.  Параллельная
> > >>>обработка заданий была реализована в 
> > >>>первую очередь как первый шаг на
> > >>>пути к реализации этих карманов.  Потом 
> > >>>мы столкнулись с непреодоленными
> > >>>до сих пор организационно-техническими 
> > >>>преградами, о необходимости
> > >>>преодоления которых все 
> > >>>заинтересованные, надеюсь, помнят 
> > >>>постоянно.
> > >>
> > >>Т.е. - если я правильно понял этот тонкий 
> > >>намёк - у нас сейчас тонкое место
> > >>- это отсутствие необходимых серверных 
> > >>мощностей и каналов связи.
> > >
> > >Да. Это  главная и застарелая проблема, 
> > >которая не решается парой серверов.
> > 
> > А каким количеством серверов она 
> > решается ?
> 
> Это зависит от постановки задачи.  Например, от того, сколько карманов в
> единицу времени требуется обрабатывать одновременно (в среднем и
> максимально).  Реализация параллельной обработки показала, что большой
> объем вычислительных мощностей требуется не только для сборки самих
> пакетов на вычислительных узлах, но также и для вычисления нового
> состояния репозитория с последующими проверками целостности.  Сейчас все
> такие вычисления централизованы, и мне очевидно, что система начинает
> заметно проседать уже при параллельном вычислении двух состояний разных
> репозиториев.  Очевидно, что система, рассчитанная на _одновременную_
> обработку нескольких заданий с вычислением репозиториев, должна
> распределять по узлам не только сборку самих пакетов, но и все сложные
> вычисления по репозиториям.  Опыт показал, что качество кэширования
> радикально влияет на производительность системы, производящей вычисления
> над репозиторием.  Это значит, что последовательная обработка двух разных
> репозиториев на одном узле заметно снижает производительность этой
> обработки.

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

Если дать возможность мантейнерам публиковать такие репозитории(они очень
похожи на test-only таски) и возможность обновлять их полуавтоматически,
то таким образом можно было бы продлить срок жизни бранча. Ведь для
веб-сервиса обычно не столь важно каким компилятором он собран на сервере,
но жизненно важно иметь набор пакетов определённых версий, обеспечивающий
работоспособность прикладного софта.
Тоесть более или менее замороженная basesystem и несколько вариантов
высокоуровнего софта типа php, python, раздичных СУБД и т.д. в отдельных
репозиториях. Видимо это не есть те самые карманы, так же это не совсем и
backports, а что-то типа молодильных яблок для бранча )