Re: [devel] pockets

Re: [devel] pockets

[Dmitry V. Levin]

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

Hi,

On Tue, Mar 16, 2010 at 09:41:03PM +0300, Alexey Tourbin wrote:
> Альтернативное мнение: contrib не нужен, pocket'ы не нужны.

В связи с pockets могу привести аналогию.  Когда-то достаточно давно
пакеты в Сизиф собирались на сервере по имени altair, прямо в
хост-системе.  Помимо тех, кто имел возможность собрать пакет для
тестирования непосредственно на сервере, никто не мог знать заранее,
соберётся ли отправляемый в Сизиф пакет, и если соберётся, то насколько
полученный результат будет отличаться от собранного и протестированного
локально.  Потом (уже почти 7 лет назад) появился инструмент для
построения воспроизводимой сборочной среды.  Каждый мейнтейнер получил
возможность собирать и тестировать локально пакет в такой же среде, в
которой этот пакет собирается в Сизиф.

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

Какие могут быть способы сокращения разрыва между мейнтейнером и
Сизифом?  По второму вопросу напрашивается интерфейс, позволяющий
мейнтейнеру отправлять в Сизиф только те пакеты, которые он
протестировал.  Например, сборочное задание может остановится после
сборки и проверки пакетов с тем, чтобы мейнтейнер мог дополнительно
протестировать уже собранные пакеты.  Если тестирование даёт
положительный результат, то задание отправляется в Сизиф при условии,
что ни один из собранных пакетов не требует пересборки из-за изменений в
Сизифе, произошедших за время тестирования.  Если это условие не
выполнено, то цикл сборка-тестирование повторяется.

Какие видны варианты решения первого вопроса?  Либо girar/girar-builder
должен стать не более сложным в развёртывании и использовании
инструментом, чем hasher, либо сборочная система должна предоставлять
т.н. карманы: интерфейс для ветвления Сизифа, коллективной сборки
заданий в репозитории мейнтейнеров, и последующей интеграции в Сизиф.  

Какой вариант кажется вам более перспективным?  Имело ли смысл 7 лет
назад выделить каждому мейнтейнеру shell account на сборочном сервере
вместо того, чтобы реализовать hasher?  В какой степени эта аналогия
переносима на нашу нынешнюю ситуацию?


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] pockets

[Michael Shigorin]

On Fri, Apr 02, 2010 at 04:46:59AM +0400, Dmitry V. Levin wrote:
> On Tue, Mar 16, 2010 at 09:41:03PM +0300, Alexey Tourbin wrote:
> > Альтернативное мнение: contrib не нужен, pocket'ы не нужны.

Перевожу с турбинского на шигоринский: новички в команде не нужны,
нетривиальные программы в сизифе не нужны.  Только мне лично такой
сизиф не нужен, сразу говорю.

> Какие видны варианты решения первого вопроса?  Либо girar/girar-builder
> должен стать не более сложным в развёртывании и использовании
> инструментом, чем hasher, либо сборочная система должна предоставлять
> т.н. карманы: интерфейс для ветвления Сизифа, коллективной сборки
> заданий в репозитории мейнтейнеров, и последующей интеграции в Сизиф.  

Индивидуальный girar-builder не решает вопрос, когда перелопатить
надо слишком тяжёлый для двух рук / слишком развесистый для одной
головы кусок сизифа.  Например, тот же Xorg-7.5 зацепил и vnc,
и ещё что-то по бокам.  Про новый perl 5.x думать страшновато.

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

Re: [devel] pockets

[Dmitry V. Levin]

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

On Fri, Apr 02, 2010 at 11:50:26AM +0300, Michael Shigorin wrote:
> On Fri, Apr 02, 2010 at 04:46:59AM +0400, Dmitry V. Levin wrote:
[...]
> > Какие видны варианты решения первого вопроса?  Либо girar/girar-builder
> > должен стать не более сложным в развёртывании и использовании
> > инструментом, чем hasher, либо сборочная система должна предоставлять
> > т.н. карманы: интерфейс для ветвления Сизифа, коллективной сборки
> > заданий в репозитории мейнтейнеров, и последующей интеграции в Сизиф.  
> 
> Индивидуальный girar-builder не решает вопрос, когда перелопатить
> надо слишком тяжёлый для двух рук / слишком развесистый для одной
> головы кусок сизифа.

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


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] pockets

[Michael Shigorin]

On Fri, Apr 02, 2010 at 01:12:42PM +0400, Dmitry V. Levin wrote:
> > Индивидуальный girar-builder не решает вопрос, когда
> > перелопатить надо слишком тяжёлый для двух рук / слишком
> > развесистый для одной головы кусок сизифа.
> Индивидуально развёртываемый girar-builder не обязательно
> означает индивидуальный girar-builder.

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

Вообще тут заметили offlist по мотивам параллельного треда про
git, что помогает сперва обдумывать методологию разработки,
а потом уже обдумывать и реализовывать средства таковой.
(если правильно понимаю ход твоей мысли)

> Разумеется, в распределённой системе girar-builder'ов должен
> быть продуман и механизм для совместной работы мейнтейнеров,
> и механизм для интеграции изменений в репозиторий, от которого
> было осуществлено ветвление.

Не всякий форк (особенно сильный) стремится к мержу,
даже если он вполне возможен, но всё равно трудоёмок.

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

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

Re: [devel] pockets

[Evgeny Sinelnikov]

2 апреля 2010 г. 13:12 пользователь Dmitry V. Levin <ldv@altlinux.org> написал:
> On Fri, Apr 02, 2010 at 11:50:26AM +0300, Michael Shigorin wrote:
>> On Fri, Apr 02, 2010 at 04:46:59AM +0400, Dmitry V. Levin wrote:
> [...]
>> > Какие видны варианты решения первого вопроса?  Либо girar/girar-builder
>> > должен стать не более сложным в развёртывании и использовании
>> > инструментом, чем hasher, либо сборочная система должна предоставлять
>> > т.н. карманы: интерфейс для ветвления Сизифа, коллективной сборки
>> > заданий в репозитории мейнтейнеров, и последующей интеграции в Сизиф.
>>
>> Индивидуальный girar-builder не решает вопрос, когда перелопатить
>> надо слишком тяжёлый для двух рук / слишком развесистый для одной
>> головы кусок сизифа.
>
> Индивидуально развёртываемый girar-builder не обязательно означает
> индивидуальный girar-builder.  Разумеется, в распределённой системе

А можно уточнить разницу между "индивидуально развёртываемым
girar-builder'ом" и "индивидуальным girar-builder'ом"? Мне эта разница
кажется важной, но, что имеется в виду, непонятно.

> girar-builder'ов должен быть продуман и механизм для совместной работы
> мейнтейнеров, и механизм для интеграции изменений в репозиторий, от
> которого было осуществлено ветвление.
>

Я так понимаю, смысл girar-builder'ов в распределённой системе состоит
в том, чтобы распределить вычислительныую и дисковую нагрузки. Такое
приближение к "облачным вычислениям";)

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


-- 
Sin (Sinelnikov Evgeny)

Re: [devel] pockets

[Alexander Bokovoy]

2010/4/2 Evgeny Sinelnikov <sin@altlinux.ru>:
>>> Индивидуальный girar-builder не решает вопрос, когда перелопатить
>>> надо слишком тяжёлый для двух рук / слишком развесистый для одной
>>> головы кусок сизифа.
>>
>> Индивидуально развёртываемый girar-builder не обязательно означает
>> индивидуальный girar-builder.  Разумеется, в распределённой системе
>
> А можно уточнить разницу между "индивидуально развёртываемым
> girar-builder'ом" и "индивидуальным girar-builder'ом"? Мне эта разница
> кажется важной, но, что имеется в виду, непонятно.
Тут нужно уточнить, что то, о чем пишет Дима, обсуждалось неделю назад
в офисе ALT, когда мне удалось оказаться в Москве. Вот небольшая
выдержка-резюме:

0. Успешная совместная деятельность возможна при хотя бы частичном
совпадении интересов и совпадении ритма деятельности.

1. Возможности совпадения ритма деятельности ограничиваются
коммуникационными возможностями взаимодействующих сторон. Лет десять
назад практическая возможность быстро реагировать на изменения
пакетной базы и устранение проблем в пакетах была ограничена
пропускной способностью каналов связи, за которыми находились члены
команды, а также их возможностью быстро обмениваться сообщениями "в
реальном времени". "Реальное время" конца 90-х -- несколько дней для
географически распределенных участников. "Реальное время" для ученых
XVII-XVIII веков -- месяцы, для сравнения.

2. В то время, когда сдерживающим фактором являются каналы связи,
крайне важно выполнять свою часть работы так, чтобы она не затрагивала
с отрицательной стороны других членов команды, коммуникация с которыми
затруднена. Фактически, увеличение стоимости того или иного пути за
счет ошибки в пакетировании/программе прямо пропорционально времени,
затраченному на коммуникацию сообщения об ошибке, разработку
исправления и доставку его корреспонденту. В этом контексте важным
становится возможность проведения локального эксперимента, не
затрагивающего других. В дискуссии в пятницу я назвал эту возможность
"what if", правом на независимый эксперимент.

3. Способы устранения сдерживающих фактором разнообразны. К сожалению,
технические возможности не всегда позволяют масштабировать эти способы
на реальные команды. В 2001-2002 году в SaM Solutions был разработан
способ поддержания разработки репозитория пакетов, позволявший
локальные эксперименты отдельных разработчиков -- sandman. Исходная
информация о пакетах хранилась в CVS, с возможностью построения
локального среза репозитория по ветке из CVS для конкретного пакета. В
таком локальном срезе можно было пересобирать разные пакеты, не
затрагивая основной репозитарий, а затем "сливать" изменения в
основную ветку, перемещая их в основной репозитарий. CVS не
масштабируется для географически распределенных команд, но в случае
SaM Solutions решение работало для приблизительно полусотни
разработчиков, размещенных в одном офисе. Результат локального
эксперимента дальше "сливался" с основным Сизифом традиционным
образом. Поскольку взаимодействующие команды, работавшие над общей
группой пакетов, были практически всегда локализованы в рамках одного
офиса, коммуникационные ограничения были сведены до минимума, а темп
взаимодействия с другими группами был ограничен каналами связи.
Поскольку результат, сливавшийся с основным Сизифом был уже
относительно протестирован в рамках локальных экспериментов, то каналы
связи не накладывали очень сильных ограничений на темп взаимодействия
при ошибках (количество ошибок было естественным образом меньше).

4. Нужно отметить, что Sandman+CVS не подходит для географически
распределенной группы команд и это ограничило его внедрение для всех в
team.

5. Когда в 2005 году появился hasher, независимо от него изменились
коммуникационные условия для многих участников team. Каналы связи
стали быстрее, а во многих случаях и неограничены по трафику. Hasher
реализовал часть функционала Sandman по автоматизации возможности
локального эксперимента, а появление git в том же году дало
возможность распределенной работы над исходником одного пакета. То
есть, появление git позволило решить проблему, которая препятствовала
внедрению Sandman для всей команды.

6. К сожалению, одна часть Sandman по-прежнему осталась не охваченной.
Локальный эксперимент хорош тогда, когда пакет или группу пакетов
ведет один человек или группа, имеющая физический доступ к общему
хранилищу, фактически, "географически нераспределенная команда". Такой
можно представить отдельных разработчиков и, например, всю комнату
разработчиков в ООО "ALT Linux". Если команда на самом деле
географически распределена, промежуточный результат необходимо
разделять между всеми ее участниками, а это как раз сейчас и
отсутствует. Фактически, отсутствует возможность подстройки ритма
деятельности географически распределенной команды при совпадении
интересов.

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

8. Решение конфликтов -- локализация процесса эксперимента, но уже не
по географическому признаку, как было в случае Sandman+CVS, а путем
построения временных срезов, контроль над состоянием которых полностью
в рамках рабочей группы, а принятие результатов ее эксперимента
осуществляется в рамках стандартного процесса пересборки относительно
текущего Сизифа. Если мы используем терминологию git, то это означает
регулярное ветвление репозитария с возможностью совместного коммита в
получаемые ветки и использование механизма проверок при слиянии
обратно в основную ветку разработки.

9. К сожалению, текущая инфраструктура проекта не содержит некоторых
критичных для реализации этого подхода компонент:
- возможность делать дешевые срезы репозитария (требует дисковое
пространство, в пятницу выяснилось, что этой проблемы больше нет на
обозримый горизонт планирования, а на этой неделе переезд git.alt
завершил и стадию нехватки дискового пространства сейчас) и
периодически перебазировать срезы на текущий сизиф
- возможность переопределения прав доступа на пакеты внутри среза
(перекрытие ACL пакетов внутри среза на ACL работающей над
срезом/пакетами группы), с тем, чтобы группа могла модифицировать
любой пакет в срезе, пока идет локальный эксперимент
- возможность выборочного отключения ряда проверок при сборке пакетов,
которые имеют смысл только при слиянии с основной веткой разработки
(Сизифом)
- разграничение прав доступа по записи в различные срезы между группами
- установление временных ограничений на существование локального
группового эксперимента с целью поощрения более быстрого темпа работы
и слияния с основной веткой разработки.

10. Последний момент крайне важен. Чаще всего локальный эксперимент не
занимает продолжительное время, для определенности -- двух недель.
Если позволить жить эксперименту вечно, то он рискует превратиться в
форк, без реального поощрения слияний с основным руслом разработки.
Для более сложных локальных групповых экспериментов может
потребоваться более продолжительный срок жизни, однако и здесь я бы
ограничился месяцем. За месяц можно синхронизировать большинство
ритмов взаимодействия, а если потребуется дополнительное время, то
расширение срока жизни эксперимента должно быть сопряжено с четким
планированием группой своей работы и может служить хорошим поводом
оценить свои достижения.

-- 
/ Alexander Bokovoy

Re: [devel] pockets

[Dmitry V. Levin]

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

On Fri, Apr 02, 2010 at 02:43:01PM +0400, Evgeny Sinelnikov wrote:
> 2 апреля 2010 г. 13:12 пользователь Dmitry V. Levin <ldv@altlinux.org> написал:
> > On Fri, Apr 02, 2010 at 11:50:26AM +0300, Michael Shigorin wrote:
> >> On Fri, Apr 02, 2010 at 04:46:59AM +0400, Dmitry V. Levin wrote:
> > [...]
> >> > Какие видны варианты решения первого вопроса?  Либо girar/girar-builder
> >> > должен стать не более сложным в развёртывании и использовании
> >> > инструментом, чем hasher, либо сборочная система должна предоставлять
> >> > т.н. карманы: интерфейс для ветвления Сизифа, коллективной сборки
> >> > заданий в репозитории мейнтейнеров, и последующей интеграции в Сизиф.
> >>
> >> Индивидуальный girar-builder не решает вопрос, когда перелопатить
> >> надо слишком тяжёлый для двух рук / слишком развесистый для одной
> >> головы кусок сизифа.
> >
> > Индивидуально развёртываемый girar-builder не обязательно означает
> > индивидуальный girar-builder.  Разумеется, в распределённой системе
> 
> А можно уточнить разницу между "индивидуально развёртываемым
> girar-builder'ом" и "индивидуальным girar-builder'ом"? Мне эта разница
> кажется важной, но, что имеется в виду, непонятно.

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

> > girar-builder'ов должен быть продуман и механизм для совместной работы
> > мейнтейнеров, и механизм для интеграции изменений в репозиторий, от
> > которого было осуществлено ветвление.
> 
> Я так понимаю, смысл girar-builder'ов в распределённой системе состоит
> в том, чтобы распределить вычислительныую и дисковую нагрузки. Такое
> приближение к "облачным вычислениям";)
> 
> Наверное, это более перспективная тема, чем развитие централизованного
> сервиса. Но вопрос в том, что архитекутра такого решения не ясна и
> когда она будет реализована тоже непонятно. А вопрос совместных тестов
> над репозиторием вполне актуален.

Вопрос ещё и в достижимости распределённой системы.  Чем более
ресурсоёмкие тесты реализованы в централизованной системе, тем меньше
мейнтейнеров смогут развернуть локально аналогичную ресурсоёмкую систему.
Так что вопрос не праздный.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] pockets

[Денис Смирнов]

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

On Fri, Apr 02, 2010 at 01:12:42PM +0400, Dmitry V. Levin wrote:

DVL> Индивидуально развёртываемый girar-builder не обязательно означает
DVL> индивидуальный girar-builder.  Разумеется, в распределённой системе
DVL> girar-builder'ов должен быть продуман и механизм для совместной работы
DVL> мейнтейнеров, и механизм для интеграции изменений в репозиторий, от
DVL> которого было осуществлено ветвление.

Индивидуально развертываемый girar-buidler это относительно простая
задача. Например если у меня будет возможность подергать тебя и тех кто в
Etersoft его развертывал, то я мог бы сделать соответствующий bundle.

С индивидуальными (вне зависимости от того где они развернуты) возникает
обсуждавшаяся уже проблема принуждения к merge.

Мне кажется что pocket'ы и индивидуальные girar-builder'ы это практически
равноважные задачи, но их могут реализовывать совершенно разные люди.

И если первое требует высокой квалификации и твоего личного доверия, то
второе требует только базовых знаний по админитсрированию, умение печь
bundle'ы для mkve, и иметь возможность расспросить тебя по поводу того
"как эта конструкция устроена?".

Тем более что в первом приближении я уже поднимал у себя girar как
хранилище (правда без сборки).

-- 
С уважением, Денис

http://mithraen.ru/
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] pockets

[Michael Shigorin]

On Fri, Apr 02, 2010 at 02:49:15PM +0400, Денис Смирнов wrote:
> Индивидуально развертываемый girar-buidler это относительно
> простая задача. Например если у меня будет возможность
> подергать тебя и тех кто в Etersoft его развертывал, то я мог
> бы сделать соответствующий bundle.

http://www.altlinux.org/Инструкция_по_разворачиванию_girar-builder

> С индивидуальными (вне зависимости от того где они развернуты)
> возникает обсуждавшаяся уже проблема принуждения к merge.

s/принуждения/побуждения/ :)

> Мне кажется что pocket'ы и индивидуальные girar-builder'ы это
> практически равноважные задачи [...] второе требует только [...]

Если копать в сторону географически распределённой сборки,
сперва светит решать вопрос аутентификации и авторизации.
А это не пять минут совсем.  И насколько понимаю, сейчас
не самое важное всё же.

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

Re: [devel] pockets

[Evgeny Sinelnikov]

2 апреля 2010 г. 16:19 пользователь Michael Shigorin <mike@osdn.org.ua> написал:
> On Fri, Apr 02, 2010 at 02:49:15PM +0400, Денис Смирнов wrote:
>> Индивидуально развертываемый girar-buidler это относительно
>> простая задача. Например если у меня будет возможность
>> подергать тебя и тех кто в Etersoft его развертывал, то я мог
>> бы сделать соответствующий bundle.
>
> http://www.altlinux.org/Инструкция_по_разворачиванию_girar-builder
>

У меня в git'е лежит сборка girar-builder в rpm.
http://git.etersoft.ru/people/sin/packages/girar-builder.git

работает в связке с модифицированным girar (для поддержки карманов):
http://git.etersoft.ru/people/sin/packages/girar.git

>> С индивидуальными (вне зависимости от того где они развернуты)
>> возникает обсуждавшаяся уже проблема принуждения к merge.
>
> s/принуждения/побуждения/ :)
>
>> Мне кажется что pocket'ы и индивидуальные girar-builder'ы это
>> практически равноважные задачи [...] второе требует только [...]
>
> Если копать в сторону географически распределённой сборки,
> сперва светит решать вопрос аутентификации и авторизации.
> А это не пять минут совсем.  И насколько понимаю, сейчас
> не самое важное всё же.
>
> --
>  ---- WBR, Michael Shigorin <mike@altlinux.ru>
>  ------ Linux.Kiev http://www.linux.kiev.ua/
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel



-- 
Sin (Sinelnikov Evgeny)

Re: [devel] pockets

[Денис Смирнов]

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

On Fri, Apr 02, 2010 at 08:27:38PM +0400, Evgeny Sinelnikov wrote:

ES> У меня в git'е лежит сборка girar-builder в rpm.
ES> http://git.etersoft.ru/people/sin/packages/girar-builder.git
ES> работает в связке с модифицированным girar (для поддержки карманов):
ES> http://git.etersoft.ru/people/sin/packages/girar.git

А на wiki? ;)

-- 
С уважением, Денис

http://mithraen.ru/
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] pockets

[Vitaly Lipatov]

On 3 апреля 2010, Денис Смирнов wrote:
...
 работает в связке с модифицированным girar (для поддержки
> карманов): ES>
> http://git.etersoft.ru/people/sin/packages/girar.git
>
> А на wiki? ;)
http://wiki.etersoft.ru/UsesGitEtersoft?v=5a9#h257-8


-- 
С уважением,
Виталий Липатов
Санкт-Петербург
GNU! ALT Linux Team! WINE! LaTeX! LyX! http://freesource.info

Re: [devel] pockets

[Денис Смирнов]

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

On Fri, Apr 02, 2010 at 03:19:48PM +0300, Michael Shigorin wrote:

MS> http://www.altlinux.org/Инструкция_по_разворачиванию_girar-builder

О!

>> С индивидуальными (вне зависимости от того где они развернуты)
>> возникает обсуждавшаяся уже проблема принуждения к merge.
MS> s/принуждения/побуждения/ :)

:)

MS> Если копать в сторону географически распределённой сборки,
MS> сперва светит решать вопрос аутентификации и авторизации.
MS> А это не пять минут совсем.  И насколько понимаю, сейчас
MS> не самое важное всё же.

Ну, это уж слишком.

Я скорее про создание местных песочниц. Но таки хотя приоритеты и
одинаковые (с моей точки зрения) реализовывать их надо совсем разным
людям. Тем более что процесс документирован -- кому надо, тот и сделает.

В свободное время я подумываю сделать у себя такую песочницу (для более
оперативной сборки, особенно когда в Сизифе очередь задач оказывается
большая).

-- 
С уважением, Денис

http://mithraen.ru/
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] pockets

[Michael Shigorin]

On Sat, Apr 03, 2010 at 12:19:30AM +0400, Денис Смирнов wrote:
> MS> http://www.altlinux.org/Инструкция_по_разворачиванию_girar-builder
> Тем более что процесс документирован -- кому надо, тот и сделает.

Эту документацию ещё проверить-обновить-доработать надо.
ldv@ поправил, спасибо; хорошо бы ещё неявности около упоминаний
слова "репозиторий" раскрыть или примерами снабдить.

Вообще там наполовину скрипт вырисовывается,
вспоминая sandman-*-setup...

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