[devel] про автоматическое и ручное тестирование пакетов

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

On Tue, Jun 16, 2009 at 01:36:11PM +0300, Michael Shigorin wrote:

>>> Разумеется. Тут ты прав. Ничто не мешает тестировать свои
>>> сборки отдельно.
MS> Просто дальше возникает следующий вопрос: зачем мучиться их
MS> куда-то вливать?

Это фактор на который редко обращают внимание. Однако он является крайне
важным -- элементарная лень. Я для себя пакетик собрал, использую. Если
мне его выложить _легко_ -- точно выложу. Если _сложно_ -- точно не
выложу. Остальное посередине. Но удобство инфраструктуры влияет на то
будет ли код опубликован, или нет.

MS> По крайней мере попытка поддержки и отслеживания Sisyphus changes
MS> скорее заглохла, причём не в последнюю очередь из-за обычного
MS> "так что ж вы, даже в changes не читали? -- нет..."

Если я правильно понимаю -- это была инииатива lav@, и кроме тебя мало кто
ее поддержал активной поддержкой.

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

Нужны оба варианта. Вообще говоря следует воспринимать pocket как task со
слегка измененной логикой. И многое что касается task'ов (в том числе то,
что они бывают shared и не очень) к ним относится. Разве что у pocket'ов
могут быть acl, и при этом для сборки в pocket'е игнорируются acl
мантейнеров пакетов.

MS> Здесь есть очень важный момент: в отличие от Daedalus и более
MS> близко к одному из вариантов использования people, обновление
MS> и тестирование получается _узконаправленным_.  Т.е. нет опасения,
MS> что забыв карман xorg-2.0 подключенным, ты получишь из него
MS> firefox-4.0.  С дедалом такое было возможно, сам разок нарвался.

По этой причине daedalus у меня отсутствует в sources.list.

>> Перенос (пересборка) пакетов на сизиф из кармана осуществляется
>> одной командой task merge. В этом случае все пакеты из кармана
>> собираются на сизифе в том порядке, в котором они были собраны
>> в кармане (в случае, если в сизиф ещё не вброшена более новая
>> версия, естественно).
MS> Здесь может быть казус, если эта новая версия что-то сломала
MS> в кармане, но IMHO вполне обрабатывабельно как exception:
MS> ну не собрался перед мержем на Sisyphus+pocket, ну просигналили
MS> и пусть люди думают, у них это по крайней мере получается.

merge может быть и ручной, и даже пошаговый. Но это совершенно отдельное и
может быть сделано отдельными shared или не-shared task'ами.

>> Т.е. - по сути - это не карманы, а варианты
MS> а-ля гитовых?
>> бранчей для кусочка репозитория. Такой продвинутый вариант дедала.
MS> fine-grained.
MS> Кстати, да -- у нас сейчас получается CVS со всеми прелестями
MS> merge conflict'ов и HEAD, выданным на откуп сотне с лишним
MS> коммиттеров (вместо release engineer aka keeper), а предлагается
MS> git с topic branch'ами, которые мержатся "когда готово", а не 
MS> "побыстрее".

Именно так!


MS> Угу, причём и для простых случаев вроде смены soname мороки
MS> получается многовато.

По поводу смены soname я уже напоминал про то, что если такая смена
требует всяких shared task и прочего -- значит тот кто ее делает не читал
SharedLibsPolicy.

>> Не каждый вообще имеет ресурсы для того чтобы что-то куда-то
>> удобно выкладывать. Скажем у меня есть свой сервер на площадке,
>> однако у меня пока не было времени развернуть там аналог
>> git.alt, да еще и прикрутить туда pocket'ы.
MS> Хотя ты бы тоже скорее всего согласился предоставить часть его
MS> ресурсов, поскольку это было озвучено как один из важных вопросов?

Да, именно так. Машинка там слабенькая, но если несколько человек отдадут
под pocket'ы по VE, даже если и с небольшими лимитами -- проблема будет
решена.

>> Это является наиболее существенным преимуществом. Поясню --
>> использоваине pocket'ов само по себе это дополнительное
>> усложнение workflow разработки.
MS> Необязательно, если не отменяется и текущий путь.  Например,
MS> не вижу смысла усложнять попадание в сизиф "листьев", от которых 
MS> ничто не зависит по сборке и в рантайме, в случае несущественных
MS> изменений и уверенности сборщика в достаточности своей проверки.

Речь о том, что если надо все-таки собирать через pocket -- это лишнее
телодвижение. Оно должно быть оправдано.

MS> alterator/installer -- другое, тут нет внешнего фактора в виде
MS> апстрима и вопрос исключительно в удобстве координации между
MS> собой, когда надо подтянуть стопку разного и хорошо бы выложить
MS> в сизиф одновременно.

Тут есть внешний фактор в виде невозможности собрать дистрибутив из Сизифа
при очередных экспериментах в области alterator'а.

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

http://freesource.info
----------------------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://lists.altlinux.org/pipermail/devel/attachments/20090616/e3f9a86b/attachment-0001.bin>