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

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

[Dmitry V. Levin]

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

On Sun, Jun 14, 2009 at 03:51:18PM +0300, Kirill A. Shutemov wrote:
> 2009/6/14 Kirill Maslinsky <kirill@altlinux.org>:
[...]
> > Формализованные тесты на функциональность, включённые в пакет мантейнером,
> > выполняемые после успешной сборки пакета в безопасном окружении,
> > гаранитрующие отсутствие регрессий по данной функциональности
> > при пересборке в любом окружении.
> 
> Ядро и всё околожелезное так не протестируешь в принципе. Многое из оставшегося
> протестировать в автоматическом режиме тоже малореально.

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

Например, https://bugzilla.altlinux.org/show_bug.cgi?id=20463 не возникло
бы, если бы на момент сборки пакета было реализовано соответствующее
автоматическое тестирование.  Собственно говоря, я рассчитывал, что
тестирование принимаемых в Сизиф пакетов пересборкой зависящих от них
пакетов будет введено в строй ещё до окончания весны, но один не очень
хороший человек (по запросу я готов назвать его имя) нарушил
договорённость об использовании оборудования для этой цели.

Я на данный момент не вижу, в чём заключается значимое преимущество
централизованных "карманов" для предварительного тестирования, о которых
так много говорят последнее время, над распределёнными "карманами", которые
каждый может устроить где угодно при наличии соответствующих ресурсов.
Могу лишь предположить:
- информация (централизованный "карман" немного легче обнаружить);
- доступность (централизованная сборка в среднем более доступна всем
  заинтересованным);
- интеграция (централизованный "карман" теоретически должно быть немного
  легче интегрировать в "материнский" репозиторий);
На данный момент мне эти преимущества не кажутся значимыми.
Грубо говоря, я не вижу, каким образом появления централизованных
"карманов" заметно повысит качество предварительного ручного тестирования.

Есть другие соображения на эту тему?


-- 
ldv

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

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

[Mikhail Gusarov]

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


Twas brillig at 02:33:38 16.06.2009 UTC+04 when ldv@altlinux.org did gyre and gimble:

 DVL> На данный момент мне эти преимущества не кажутся значимыми.

После такого вывода...

 DVL> Есть другие соображения на эту тему?

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

-- 

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

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

[Dmitry V. Levin]

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

On Tue, Jun 16, 2009 at 05:35:42AM +0700, Mikhail Gusarov wrote:
> Twas brillig at 02:33:38 16.06.2009 UTC+04 when ldv@altlinux.org did gyre and gimble:

> > Я на данный момент не вижу, в чём заключается значимое преимущество
> > централизованных "карманов" для предварительного тестирования, о которых
> > так много говорят последнее время, над распределёнными "карманами",
> > которые каждый может устроить где угодно при наличии соответствующих ресурсов.
> > Могу лишь предположить:
> > - информация (централизованный "карман" немного легче обнаружить);
> > - доступность (централизованная сборка в среднем более доступна всем
> >   заинтересованным);
> > - интеграция (централизованный "карман" теоретически должно быть немного
> >   легче интегрировать в "материнский" репозиторий);

>  DVL> На данный момент мне эти преимущества не кажутся значимыми.
> 
> После такого вывода...
> 
>  DVL> Есть другие соображения на эту тему?
> 
> ... нет других соображений. Можно на этом тему закрывать.

Если нет других соображений, то тему можно закрывать.

> Ну, пока ты не
> переменишь своего мнения о том эти преимущества не являются значимыми.

Если никто не будет приводить новые аргументы, то я своё мнение менять
не стану.  Это общее правило ведения обсуждения.


-- 
ldv

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

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

[Mikhail Gusarov]

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


Twas brillig at 03:00:40 16.06.2009 UTC+04 when ldv@altlinux.org did gyre and gimble:

 >> > Могу лишь предположить:
 >> > - информация (централизованный "карман" немного легче обнаружить);
 >> > - доступность (централизованная сборка в среднем более доступна всем
 >> >   заинтересованным);
 >> > - интеграция (централизованный "карман" теоретически должно быть немного
 >> >   легче интегрировать в "материнский" репозиторий);

 DVL> Если никто не будет приводить новые аргументы, то я своё мнение
 DVL> менять не стану.  Это общее правило ведения обсуждения.

Можно провести опрос мейнтейнерского мнения на предмет того, стали бы
они складывать в карманы то, что сейчас лежит локально или неготовое
сваливается в сизиф. Это может изменить твоё мнение?

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

-- 

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

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

[Dmitry V. Levin]

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

On Tue, Jun 16, 2009 at 06:06:23AM +0700, Mikhail Gusarov wrote:
> Twas brillig at 03:00:40 16.06.2009 UTC+04 when ldv@altlinux.org did gyre and gimble:
> 
>  >> > Могу лишь предположить:
>  >> > - информация (централизованный "карман" немного легче обнаружить);
>  >> > - доступность (централизованная сборка в среднем более доступна всем
>  >> >   заинтересованным);
>  >> > - интеграция (централизованный "карман" теоретически должно быть немного
>  >> >   легче интегрировать в "материнский" репозиторий);
> 
>  DVL> Если никто не будет приводить новые аргументы, то я своё мнение
>  DVL> менять не стану.  Это общее правило ведения обсуждения.
> 
> Можно провести опрос мейнтейнерского мнения на предмет того, стали бы
> они складывать в карманы то, что сейчас лежит локально или неготовое
> сваливается в сизиф. Это может изменить твоё мнение?

Если отвечающие дадут более развёрнутые ответы, почему они станут поступать
так или иначе, то я смогу понять, чего они хотят на самом деле и какие
факторы для них являются существенными.

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

Это кажется слишком тривиальным, если бы не одно "но".
Всё вышеперечисленное не является обязательным следствием
централизованного карманохранилища при git.alt, и, наоборот,
централизованное карманохранилище при git.alt не является обязательным
требованием для всего вышеперечисленного.  И вообще, не факт, что
централизованное карманохранилище при git.alt является оптимальным
воплощением вышеперечисленных удобств.  Хуже того, я могу представить себе
такую реализацию централизованного карманохранилища, которая этих самых
удобств с собой не принесёт.


-- 
ldv

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

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

[Alexey Gladkov]

16.06.2009 03:25, Dmitry V. Levin wrote:
> Это кажется слишком тривиальным, если бы не одно "но".
> Всё вышеперечисленное не является обязательным следствием
> централизованного карманохранилища при git.alt, и, наоборот,
> централизованное карманохранилище при git.alt не является обязательным
> требованием для всего вышеперечисленного.  И вообще, не факт, что
> централизованное карманохранилище при git.alt является оптимальным
> воплощением вышеперечисленных удобств.  Хуже того, я могу представить себе
> такую реализацию централизованного карманохранилища, которая этих самых
> удобств с собой не принесёт.

Разумеется. Тут ты прав. Ничто не мешает тестировать свои сборки отдельно.

Скажи зачем был создан git.alt ?

http://www.altlinux.org/Git.alt :

<====
Выполняемые задачи:
* хостинг git-репозиториев, заточенный под нужды разработчиков Sisyphus,
* управление ACL пакетов,
* сборка пакетов в Сизиф и другие бранчи из gear-репозиториев,
располагающихся на нём самом
====>

Судя по тексту он не так уж и нужен т.к. на тот момент у нас были
srpm-пакеты, incoming для сизифа, acl-файлы и incoming для бранчей.

Насколько я помню, когда-то цель git.alt была помощь в совместной
разработке.

Так вот и "карманы" нужны для упрощения работы разработчиков Сизифа.

-- 
Rgrds, legion

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

[Dmitry V. Levin]

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

On Tue, Jun 16, 2009 at 03:43:01AM +0400, Alexey Gladkov wrote:
> 16.06.2009 03:25, Dmitry V. Levin wrote:
> > Это кажется слишком тривиальным, если бы не одно "но".
> > Всё вышеперечисленное не является обязательным следствием
> > централизованного карманохранилища при git.alt, и, наоборот,
> > централизованное карманохранилище при git.alt не является обязательным
> > требованием для всего вышеперечисленного.  И вообще, не факт, что
> > централизованное карманохранилище при git.alt является оптимальным
> > воплощением вышеперечисленных удобств.  Хуже того, я могу представить себе
> > такую реализацию централизованного карманохранилища, которая этих самых
> > удобств с собой не принесёт.
> 
> Разумеется. Тут ты прав. Ничто не мешает тестировать свои сборки отдельно.
> 
> Скажи зачем был создан git.alt ?
> 
> http://www.altlinux.org/Git.alt :
> 
> <====
> Выполняемые задачи:
> * хостинг git-репозиториев, заточенный под нужды разработчиков Sisyphus,
> * управление ACL пакетов,
> * сборка пакетов в Сизиф и другие бранчи из gear-репозиториев,
> располагающихся на нём самом
> ====>
> 
> Судя по тексту он не так уж и нужен т.к. на тот момент у нас были
> srpm-пакеты, incoming для сизифа, acl-файлы и incoming для бранчей.
> 
> Насколько я помню, когда-то цель git.alt была помощь в совместной
> разработке.

Хостинг git-репозиториев подразумевает и помощь в совместной разработке
(в т.ч. подписка на уведомления об изменениях).
Да и сборка пакетов (в т.ч. shared tasks) тоже.
Так что решаемые задачи способствуют достижению цели.
Если можешь улучшить текст, то заранее тебе спасибо.

> Так вот и "карманы" нужны для упрощения работы разработчиков Сизифа.

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


-- 
ldv

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

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

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

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

On Tue, Jun 16, 2009 at 04:00:55AM +0400, Dmitry V. Levin wrote:

DVL> В этом вся соль.  Прийти бы к взаимопониманию, какие карманы какой формы
DVL> нужны, кто их реализует и внедрит.

В настоящий момент мне кажется будет существенным шагом вперед если карман
будет таким себе task'ом со следующими особенностями:
- он экспортируется как apt repo;
- он может быть именованым (у каждого мантейнера свое пространство имен);
- добавление пакета в такой task автоматически означает запуск task'а;
- после запуска task'а в него можно добавлять пакеты и дальше, они будут
  собираться последовательно;
- в этот task можно отправлять несколько версий одного и того же пакета,
  сборка будет в порядке очередности добавления пакетов в task;
- в любой момент можно 'экспортировать' этот task в виде списка команд
  girar для сборки аналогичного task'а уже в Сизиф/5.0/и т.д.
  Подразумевается что слияние pocket'а с репозиторием процедура которую
  человек должен пока делать вручную, но у него для этого должна быть
  заготовка;
- при появлении в репозитории, от которого ответвлен этот pocket пакета
  собранного из того же commit'а, из которого был собран пакет в pocket'е
  - этот пакет из pocket'а удаляется;

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

http://freesource.info
----------------------------------------------------------------------------

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

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

[Anton Farygin]

Dmitry V. Levin пишет:

>> Так вот и "карманы" нужны для упрощения работы разработчиков Сизифа.
> 
> В этом вся соль.  Прийти бы к взаимопониманию, какие карманы какой формы
> нужны, кто их реализует и внедрит.

Я знаю, чем стал бы пользоваться я...

я бы стал пользоваться "карманами", в которых будут собираться новые 
версии пакетов, и которые пока нестабильны для попадания в центральный 
репозиторий.

usecase примерно таков:
мейнтейнер xorg делает shared "карман" xorg-2.0
дальше все операции типа task и build принимают в виде опции имя кармана.
другие мейнтенеры так-же имеют возможность создать подобный task, 
результат которого попадёт в карман xorg-2.0.

Собранные пакеты попадают в отдельный репозиторий, который можно 
подключить к apt'у и поставить из него всю бороду пакетов.

Перенос (пересборка) пакетов на сизиф из кармана осуществляется одной 
командой task merge. В этом случае все пакеты из кармана собираются на 
сизифе в том порядке, в котором они были собраны в кармане (в случае, 
если в сизиф ещё не вброшена более новая версия, естественно).

Т.е. - по сути - это не карманы, а варианты бранчей для кусочка 
репозитория. Такой продвинутый вариант дедала.

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

Ответы на вопросы "кто реализует" и "кто внедрит", я, к сожалению - не 
знаю...

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

[Afanasov Dmitry]

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

On Tue, Jun 16, 2009 at 03:25:38AM +0400, Dmitry V. Levin wrote:
> On Tue, Jun 16, 2009 at 06:06:23AM +0700, Mikhail Gusarov wrote:
> > Twas brillig at 03:00:40 16.06.2009 UTC+04 when ldv@altlinux.org did gyre and gimble:
> > 
> >  >> > Могу лишь предположить:
> >  >> > - информация (централизованный "карман" немного легче обнаружить);
> >  >> > - доступность (централизованная сборка в среднем более доступна всем
> >  >> >   заинтересованным);
> >  >> > - интеграция (централизованный "карман" теоретически должно быть немного
> >  >> >   легче интегрировать в "материнский" репозиторий);
> > 
> >  DVL> Если никто не будет приводить новые аргументы, то я своё мнение
> >  DVL> менять не стану.  Это общее правило ведения обсуждения.
> > 
> > Можно провести опрос мейнтейнерского мнения на предмет того, стали бы
> > они складывать в карманы то, что сейчас лежит локально или неготовое
> > сваливается в сизиф. Это может изменить твоё мнение?
> 
> Если отвечающие дадут более развёрнутые ответы, почему они станут поступать
> так или иначе, то я смогу понять, чего они хотят на самом деле и какие
> факторы для них являются существенными.
можно свой "за" в копилку мнений?

текущий workflow - 
1. сборка на локальном сизифе 
2. проверки работоспособности локально (apt-get install/dist-upgrade, service restart)
3. просто сборка на другой платформе
4. компиляция этого всего в репу на people
5. вопль в sisyphus@ - смотите щаз, а посмотрите, но позже :)

хотелось бы слить 1, 3 и 4 в одну команду сборки на git.alt. в этом
случае, кстати и удаленная хешерница потеряет свою актуальность.

автоматизация people - то, что очень хочется.


теперь теперь про то, что просто хочется :)

описанный выше worflow - 1 мантейнер с 1 пакетом.
бывают случаи:

1. проверка нескольких связанных пакетов.
   а) проверка сборки (п: gnutls 2.6 -> 2.8)
      проверяю пока точечно и только непосредственно зависимые. хотелось
      бы автоматизировать, пусть даже ждать надо неделю.
   б) проверка работоспособности.
      я не использовал, примером вижу здесь - lm-sensors 2 -> 3, xorg'и.

2. работа нескольких мантейнеров.
   случаи те же, только в кооперации, а не в одиночку.

ну и наконец push pocket to sisyphus - это было просто удобно.


что характерно - непрерывность синхронизации с родительским сизифом тут не
требуется. достаточно ручного sync при необходимости.
-- 
С уважением
Афанасов Дмитрий

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

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

[Alexey I. Froloff]

[-- Attachment #1.1: Type: text/plain, Size: 515 bytes --]

On Tue, Jun 16, 2009 at 03:00:40AM +0400, Dmitry V. Levin wrote:
> Если никто не будет приводить новые аргументы, то я своё мнение менять
> не стану.  Это общее правило ведения обсуждения.
Мне было бы удобно, если бы build/*/*/rpms/*.rpm были бы
проиндексированы для apt'а:

rpm http://git.altlinux.org/tasks/НОМЕР/build/repo $(ARCH) task

Кривоскрипт в аттаче делает что-то в этом роде (вызывается в
конце gb-task-build-arch).

P.S. А ещё есть rsync://git.altlinux.org/...

-- 
Regards,
Sir Raorn.

[-- Attachment #1.2: gb-task-build-arch-makerepo --]
[-- Type: text/plain, Size: 602 bytes --]

#!/bin/sh -efu

arch="$1"; shift

. gb-sh-functions

rm -rf "build/repo/$arch"
mkdir -p "build/repo/$arch/base"
mkdir -p "build/repo/$arch/RPMS.task"
mkdir -p "build/repo/$arch/SRPMS.task"
for i in $(src_nums); do
	[ -d "build/$i/$arch/rpms" ] || continue
	find "build/$i/$arch/rpms" -type f -name "*.rpm" -exec ln -f -t "build/repo/$arch/RPMS.task" '{}' '+'

	[ -d "build/$i/$arch/srpm" ] || continue
	find "build/$i/$arch/srpm" -type f -name "*.rpm" -exec ln -f -t "build/repo/$arch/SRPMS.task" '{}' '+'
done
genbasedir \
	--topdir=build/repo \
	--flat --no-oldhashfile --bz2only --mapi "$arch" task

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

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

[Alexey Tourbin]

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

On Tue, Jun 16, 2009 at 04:03:24AM +0400, Alexey I. Froloff wrote:
> On Tue, Jun 16, 2009 at 03:00:40AM +0400, Dmitry V. Levin wrote:
> > Если никто не будет приводить новые аргументы, то я своё мнение менять
> > не стану.  Это общее правило ведения обсуждения.
> Мне было бы удобно, если бы build/*/*/rpms/*.rpm были бы
> проиндексированы для apt'а:
> 
> rpm http://git.altlinux.org/tasks/НОМЕР/build/repo $(ARCH) task

С этим есть несколько маленьких, но неприятных проблем.

Во-первых, в $(ARCH)-repo лежат разные noarch пакеты.  Строго говоря,
пока не выполнена проверка идентичности noarch пакетов, такие noarch
пакеты нежелательно выпускать во внешний мир.  А когда идентичность
noarch пакетов установлена, только тогда можно выбрать один noarch
пакет и сформировать noarch-repo одинаковый для всех архитектур.
Сейчас для этого выбирается i586-noarch пакет, по косвенному признаку
(потому что i586 лексикографически наименьшая архитектура).

Во-вторых, подписи пакетов.  Пакеты подписываются довольно серьезным
ключом.  Если пакеты не проходят, то этим ключом их нежелательно
подписывать.  Это спорный вопрос.  Я когда над ним думал, то поступил
острожно -- сделал подпись пакетов в gb-task-commit-repo (прямо перед
копированием их в master репозиторий).  Это выглядело несколько нелепо,
и ldv перенес подпись пакетов в gb-task-build-arch-i (сразу после
сборки).

В третьих, stacked мини-репозитории (оверлеи) могут иметь проблемы с
файловыми зависимостями.

RPMS.hasher
 |
 v
RPMS.classic

В этой схеме RPMS.classic генерируется независимо, и в нём удаляется
информация обо всех файлах, которые не нужны (не разрешают внутренние
зависимости).  Нельзя предсказать, какие файлы могут потребоваться в
стек-оверлеях.  Можно только вообще не удалять информацию о файлах в
RPMS.classic.  Но тогда при каждом 'apt-get update' придётся скачивать
индексы примерно вдвое большего размера.

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

> Кривоскрипт в аттаче делает что-то в этом роде (вызывается в
> конце gb-task-build-arch).

В принципе hasher repo автоматически генерируется на remote node,
и поэтому специально делать ничего не надо -- можно просто грамотно
его оттуда скопировать.

> for i in $(src_nums); do
> 	[ -d "build/$i/$arch/rpms" ] || continue
> 	find "build/$i/$arch/rpms" -type f -name "*.rpm" -exec ln -f -t "build/repo/$arch/RPMS.task" '{}' '+'
> 
> 	[ -d "build/$i/$arch/srpm" ] || continue
> 	find "build/$i/$arch/srpm" -type f -name "*.rpm" -exec ln -f -t "build/repo/$arch/SRPMS.task" '{}' '+'
> done
> genbasedir \
> 	--topdir=build/repo \
> 	--flat --no-oldhashfile --bz2only --mapi "$arch" task

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

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

[Alexey Tourbin]

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

On Wed, Jun 17, 2009 at 09:14:44AM +0400, Alexey Tourbin wrote:
> Во-вторых, подписи пакетов.  Пакеты подписываются довольно серьезным
> ключом.  Если пакеты не проходят, то этим ключом их нежелательно
> подписывать.  Это спорный вопрос.  Я когда над ним думал, то поступил
> острожно -- сделал подпись пакетов в gb-task-commit-repo (прямо перед
> копированием их в master репозиторий).  Это выглядело несколько нелепо,
> и ldv перенес подпись пакетов в gb-task-build-arch-i (сразу после
> сборки).

> > Кривоскрипт в аттаче делает что-то в этом роде (вызывается в
> > конце gb-task-build-arch).
> 
> В принципе hasher repo автоматически генерируется на remote node,
> и поэтому специально делать ничего не надо -- можно просто грамотно
> его оттуда скопировать.

Но если подпись пакетов идёт в girar-builder, то скопировать remote repo
тоже не получится.  Дело в том, что в pkglist.hasher добавляются md5sum
rpm-файлов (CRPMTAG_MD5).  А при добавлении подписи суммы меняются.

Тут появляется ещё одна маленькая неприятная проблема -- должна ли
сборка на remote node в режиме --with-stuff идти с подписанными или
неподписанным (ранее собранными) пакетами.  Правда, добавление подписи
вроде бы влияет на %{sha1header}.

> > for i in $(src_nums); do
> > 	[ -d "build/$i/$arch/rpms" ] || continue
> > 	find "build/$i/$arch/rpms" -type f -name "*.rpm" -exec ln -f -t "build/repo/$arch/RPMS.task" '{}' '+'
> > 
> > 	[ -d "build/$i/$arch/srpm" ] || continue
> > 	find "build/$i/$arch/srpm" -type f -name "*.rpm" -exec ln -f -t "build/repo/$arch/SRPMS.task" '{}' '+'
> > done
> > genbasedir \
> > 	--topdir=build/repo \
> > 	--flat --no-oldhashfile --bz2only --mapi "$arch" task

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

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

[Michael Shigorin]

On Wed, Jun 17, 2009 at 09:25:15AM +0400, Alexey Tourbin wrote:
> Тут появляется ещё одна маленькая неприятная проблема -- должна
> ли сборка на remote node в режиме --with-stuff идти с
> подписанными или неподписанным (ранее собранными) пакетами.
> Правда, добавление подписи вроде бы влияет на %{sha1header}.

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

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

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

[Alexey Tourbin]

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

On Wed, Jun 17, 2009 at 09:28:00PM +0300, Michael Shigorin wrote:
> On Wed, Jun 17, 2009 at 09:25:15AM +0400, Alexey Tourbin wrote:
> > Тут появляется ещё одна маленькая неприятная проблема -- должна
> > ли сборка на remote node в режиме --with-stuff идти с
> > подписанными или неподписанным (ранее собранными) пакетами.
> > Правда, добавление подписи вроде бы влияет на %{sha1header}.
> 
> А почему твой осторожный вариант был изменён?  В любом случае
> здесь я бы предпочёл работать с неподписанными карманами, чем
> подписывать сизифным ключом потенциальное чтопопало.

Мой осторожный вариант выглядел несколько нелепо -- в процедуру
копирования собранных пакетов в master-репозиторий вклинивалась
процедура подписи пакетов.

К тому же я реализовал "суперосторожный" коммит в master-репозиторий:
http://git.altlinux.org/people/at/packages/girar-builder.git?a=blob;f=gb-y-task-commit-packages
Там идёт сначала 'test commit' на уровне возможности выполнения и потом
'real commit'.  Потому что мало ли что.  Тогда ещё была идея, что новый
girar-builder и старый incoming будут работать с master-репозиторием
некоторое время параллельно (конкурентно).  Так что минимизация допущений
и минимизация рисков мне казалось достаточно актуальной проблемой.

Ну и вот, там было что между 'test commit' и 'real commit' была вклинена
подпись пакетов.  В общем короче долго объяснять как всё это появилось и
к чему всё это привело.

Дело ровно в том, чтО должна означать подпись пакета (альтовским
ключом).  Варианта есть два:

1) Пакет собрался (слабое условие).
2) Пакет собрался, прошел все проверки и включен в репозиторий (сильное
условие).

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

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

[Dmitry V. Levin]

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

On Thu, Jun 18, 2009 at 11:18:45AM +0400, Alexey Tourbin wrote:
[...]
> Дело ровно в том, чтО должна означать подпись пакета (альтовским
> ключом).  Варианта есть два:
> 
> 1) Пакет собрался (слабое условие).
> 2) Пакет собрался, прошел все проверки и включен в репозиторий (сильное
> условие).

Сейчас это (1), но если мы всё же будем делать какие-нибудь карманцы, то,
я думаю, надо будет завести новый карманный ключ для (1), а подпись ныне
используемым ключом перенести на (2).


-- 
ldv

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

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

[Mikhail Gusarov]

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


Twas brillig at 14:46:50 18.06.2009 UTC+04 when ldv@altlinux.org did gyre and gimble:

 DVL> Сейчас это (1), но если мы всё же будем делать какие-нибудь
 DVL> карманцы, то, я думаю, надо будет завести новый карманный ключ для
 DVL> (1),

PPA генерирует отдельные ключики для каждого кармана, что достаточно
осмысленно.

-- 

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

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

[Dmitry V. Levin]

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

On Thu, Jun 18, 2009 at 06:08:11PM +0700, Mikhail Gusarov wrote:
> 
> Twas brillig at 14:46:50 18.06.2009 UTC+04 when ldv@altlinux.org did gyre and gimble:
> 
>  DVL> Сейчас это (1), но если мы всё же будем делать какие-нибудь
>  DVL> карманцы, то, я думаю, надо будет завести новый карманный ключ для
>  DVL> (1),
> 
> PPA генерирует отдельные ключики для каждого кармана, что достаточно
> осмысленно.

А в чём смысл?


-- 
ldv

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

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

[Mikhail Gusarov]

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


Twas brillig at 15:09:57 18.06.2009 UTC+04 when ldv@altlinux.org did gyre and gimble:

 >> PPA генерирует отдельные ключики для каждого кармана, что достаточно
 >> осмысленно.

 DVL> А в чём смысл?

К примеру, есть у меня
http://ppa.launchpad.net/chromium-daily/ppa/ubuntu с известным ключиком,
и никакой админ моего провайдера свой пакет на той же сборочнице не
соберёт, DNS не заспуфит и не подсунет вместо настоящего.

В общем случае - дополнительная защита от "синдрома дедала": подключил
репозиторий что-нибудь одно пощупать, а приехало совсем другое,
неожиданное, и всё разломало.

-- 

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

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

[Michael Shigorin]

On Thu, Jun 18, 2009 at 02:46:50PM +0400, Dmitry V. Levin wrote:
> > Дело ровно в том, чтО должна означать подпись пакета
> > (альтовским ключом).  Варианта есть два:
> > 1) Пакет собрался (слабое условие).
> > 2) Пакет собрался, прошел все проверки и включен в
> > репозиторий (сильное условие).
> Сейчас это (1), но если мы всё же будем делать какие-нибудь
> карманцы, то, я думаю, надо будет завести новый карманный ключ
> для (1), а подпись ныне используемым ключом перенести на (2).

О том и говорил (как минимум в качестве дефолта при отсутствии
смысла генерировать "среднесрочный" специфический ключ).

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

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

[Alexey I. Froloff]

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

On Wed, Jun 17, 2009 at 09:14:44AM +0400, Alexey Tourbin wrote:
> С этим есть несколько маленьких, но неприятных проблем.
Это были бы проблемы, если бы область применения такого
"репозитария" не была ограничена.

Дать _удобный_ доступ к собранным пакетам задачи, независимо от
статуса выполнения этой задачи.  Можно и скрипт нарисовать,
который вытащит что-то откуда-то, куда-то сложит и что-то
запустит, только на стороне girar-builder это сделать проще и
почти ничего не стОит.

> Во-первых, в $(ARCH)-repo лежат разные noarch пакеты.
Нету noarch репозитария.  $(ARCH) и noarch собранные на одной
архитектуре лежат вместе.

> Во-вторых, подписи пакетов.
rpm пакеты подписаны, поскольку прошли сборку.  apt-репозитарий
НЕ подписан, поскольку пакеты не проходили все необходимые тесты.
Помойму всё в порядке.

> В третьих, stacked мини-репозитории (оверлеи) могут иметь проблемы с
> файловыми зависимостями.
А могут не иметь.  Если уже прям совсем проблемы возникнут, то
всегда можно "подложить" в задачу нужный пакет, который бы
честным образом разрешал эту зависимость в этом оверлее.
"Карманы" делаются для удобства мантейнеров, пусть мантейнеры эти
проблемы и решают.

> В самом общем виде эту проблему решить нельзя, потому что иначе бы
> появилась возможность предсказывать будущее.
Можно делать клон сизифа и получестным образом "коммитить" туда
этот оверлей.  Только это долго, дорого и неюзабельно.

> В принципе hasher repo автоматически генерируется на remote node,
> и поэтому специально делать ничего не надо -- можно просто грамотно
> его оттуда скопировать.
Он уже копируется неграмотно, зачем копировать два раза?

-- 
Regards,
Sir Raorn.

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

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

[Michael Shigorin]

On Wed, Jun 17, 2009 at 09:14:44AM +0400, Alexey Tourbin wrote:
> В этой схеме RPMS.classic генерируется независимо, и в нём
> удаляется информация обо всех файлах, которые не нужны (не
> разрешают внутренние зависимости).  Нельзя предсказать, какие
> файлы могут потребоваться в стек-оверлеях.  Можно только вообще
> не удалять информацию о файлах в RPMS.classic.  Но тогда при
> каждом 'apt-get update' придётся скачивать индексы примерно
> вдвое большего размера.

Может, это решаемо при помощи полного "девелоперского" base
и публикуемого оптимизированного варианта?

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

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

[Alexey Gladkov]

16.06.2009 02:33, Dmitry V. Levin wrote:
> Есть другие соображения на эту тему?

Представь ситуацию:

Я хочу выложить в сизиф новый firefox, собранный из trunk. Он уже
открывает сайты и с ним работают расширения. На всё это можно написать
тесты.

Но вот на то, что на некоторых сайтах новый firefox валится на flash и
на то что на определённых сайтах javascript падает в корку ты тестов
не сделаешь, потому что это не регулярные ошибки, которые можно
выяснить только ручным тестированием.

Такой пакет сможет пройти автотесты, но в сизифе при регулярном
использовании он будет НЕСТАБИЛЕН и ПАГУБЕН.

Более живой пример: В данный момент, я проглядел изменения в
firefox-uk, что привело к неработоспособности сочетания
firefox-3.5+firefox-uk. Выявить такое через автотесты сложно.
Автотестировиние всего множетва расширений и локализаций firefox (с
учётом возможных конфликтов между расширениями) мне представляется
очень сложной задачей.

Вышесказанное относится и к многим большим сложным пользовательским
интерактивным программам (попробуй формализовать автотесты на
openoffice, kde, gnome, groff ...). Некоторые апстримные разработчики
сами бьются над автотестами.

Я не верю, что столь очевидные примеры, не приходили тебе в голову.

Многие сложные интерактивные (хотя бы) программы легче отлаживать и
притирать друг к другу не включая в HEAD сизифа. Ибо эта работа
требует времени и промежуточных результатов для тестирования.

P.S. Ситуация с firefox из trunk вымышленная. :)

-- 
Rgrds, legion

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

[Dmitry V. Levin]

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

On Tue, Jun 16, 2009 at 03:30:05AM +0400, Alexey Gladkov wrote:
> 16.06.2009 02:33, Dmitry V. Levin wrote:
> > Есть другие соображения на эту тему?
> 
> Представь ситуацию:
> 
> Я хочу выложить в сизиф новый firefox, собранный из trunk. Он уже
> открывает сайты и с ним работают расширения. На всё это можно написать
> тесты.
> 
> Но вот на то, что на некоторых сайтах новый firefox валится на flash и
> на то что на определённых сайтах javascript падает в корку ты тестов
> не сделаешь, потому что это не регулярные ошибки, которые можно
> выяснить только ручным тестированием.

На тему автоматического поиска багов в браузерах проводились исследования.
Я точно помню, что были работы у Michal Zalewski.

> Такой пакет сможет пройти автотесты, но в сизифе при регулярном
> использовании он будет НЕСТАБИЛЕН и ПАГУБЕН.

Не надо никого убеждать в пользе предварительного тестирования.  Всё дело в
том, как его организовать.  Помнится, ты не хотел выкладывать новые сборки
firefox в Дедал из-за слишком узкого круга тестирующих.  При этом ты
выкладываешь сборки firefox в people и даёшь ни них ссылки.
Вопрос в том, "карманы" какой формы подойдут тебе и пользователям пакетов,
которые ты собираешь, больше, чем репозитории в people.


-- 
ldv

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

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

[Alexey Gladkov]

16.06.2009 03:51, Dmitry V. Levin wrote:
> На тему автоматического поиска багов в браузерах проводились исследования.
> Я точно помню, что были работы у Michal Zalewski.

Ты готов эти работы прикрутить к вашей сборочнице ?

> Не надо никого убеждать в пользе предварительного тестирования.  Всё дело в
> том, как его организовать.  Помнится, ты не хотел выкладывать новые сборки
> firefox в Дедал из-за слишком узкого круга тестирующих. 

Давай не будем о Дедале. О покойниках или хорошо, или ничего.

> При этом ты выкладываешь сборки firefox в people и даёшь ни них ссылки.

Именно. Но в эти репозитории не могут собирать другие и перекладывать
пакеты из них в сизиф неудобно.

> Вопрос в том, "карманы" какой формы подойдут тебе и пользователям пакетов,
> которые ты собираешь, больше, чем репозитории в people.

То что подойдёт всем уже выясняется некоторое время во многих тредах.

-- 
Rgrds, legion

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

[Michael Shigorin]

содержание
~~~~~~~~~~
* mithraen, sin: в [[Pockets]] допишите, чтоб не по архивам
* ldv: это всё твоя гениальная идея ;)
* rider: ...плюс нотификация всей страны
* legion: а давай попробуем у себя?
* sin, at: и новички с peer review сюда же
* sin: о маргинальности
* mithraen: распределённость и A&A; ресурсы; усложнение ли
* ldv: о значимости преимуществ


On Tue, Jun 16, 2009 at 04:00:55AM +0400, Dmitry V. Levin wrote:
> > Разумеется. Тут ты прав. Ничто не мешает тестировать свои
> > сборки отдельно.

Просто дальше возникает следующий вопрос: зачем мучиться их
куда-то вливать?

> > Насколько я помню, когда-то цель git.alt была помощь в
> > совместной разработке.
> Хостинг git-репозиториев подразумевает и помощь в совместной
> разработке (в т.ч. подписка на уведомления об изменениях).
> Да и сборка пакетов (в т.ч. shared tasks) тоже.

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

> > Так вот и "карманы" нужны для упрощения работы разработчиков Сизифа.
> В этом вся соль.  Прийти бы к взаимопониманию, какие карманы
> какой формы нужны

По части формы -- просьба к понявшим, чего им-то надо,
фиксировать здесь: http://www.altlinux.org/Pockets
(перетащил список свойств из Contrib).

2 mithraen, sin: и вы тоже :)

> кто их реализует и внедрит.

Я берусь помочь с тестированием реализации (и, возможно, смогу
помочь с кодом, но пока не строил и не вычитывал подобные
системы, сложно сказать).  Если вдруг будет удобно получаться
и распределённость, то есть некоторые ресурсы, которые возможно
подключить к сборке (вероятно, это было бы удобней всего киевской
части команды, для которой уже года два как надеюсь сделать здесь
сборочный сервер).

Проверять у меня точно можно.  Как вот и alt.linux.kiev.ua был.

Дим, вообще это всё твоя идея, она тебе уже приходила в голову:
http://lists.altlinux.org/pipermail/devel/2008-July/157594.html
:)


On Tue, Jun 16, 2009 at 10:47:06AM +0400, Anton Farygin wrote:
> я бы стал пользоваться "карманами", в которых будут собираться
> новые версии пакетов, и которые пока нестабильны для попадания
> в центральный репозиторий.

Или "уже работает для меня", но лучше погонять подготовленным
составом перед вываливанием и на не ожидающий.

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

> usecase примерно таков:
> мейнтейнер xorg делает shared "карман" xorg-2.0
> дальше все операции типа task и build принимают в виде опции
> имя кармана.  другие мейнтенеры так-же имеют возможность
> создать подобный task, результат которого попадёт в карман
> xorg-2.0.

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

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

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

При этом у people исключительно ручная нотификация, а также
затруднения с совместной работой (мне известен один прецедент
обратного -- /people/gnome/ -- и неизвестна цена его создания).

Мне уже это отличие от тестирования изменений всего используемого
подмножества Sisyphus сразу _и_ от текущего неструктурированного
people кажется достаточным обоснованием для по крайней мере
компактного эксперимента -- другое дело, кто найдёт на него время.

> Перенос (пересборка) пакетов на сизиф из кармана осуществляется
> одной командой task merge. В этом случае все пакеты из кармана
> собираются на сизифе в том порядке, в котором они были собраны
> в кармане (в случае, если в сизиф ещё не вброшена более новая
> версия, естественно).

Здесь может быть казус, если эта новая версия что-то сломала
в кармане, но IMHO вполне обрабатывабельно как exception:
ну не собрался перед мержем на Sisyphus+pocket, ну просигналили
и пусть люди думают, у них это по крайней мере получается.

> Т.е. - по сути - это не карманы, а варианты

а-ля гитовых?

> бранчей для кусочка репозитория. Такой продвинутый вариант дедала.

fine-grained.

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

> Ответы на вопросы "кто реализует" и "кто внедрит",
> я, к сожалению - не знаю...

Лёш, а ты бы взялся за код?  Просто из всех уже желающих
подобного в системы сборки только ты вникал, насколько понимаю
(хотя viy@ и sin@ тоже подходили к снаряду, а я когда-то читал
incominger-code, но это было давно и неправда).

Требовать не могу, сам понимаешь, но спрашиваю -- загрузка-то
по работе понятна.


On Tue, Jun 16, 2009 at 03:30:05AM +0400, Alexey Gladkov wrote:
> Я не верю, что столь очевидные примеры, не приходили тебе в голову.

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

> Многие сложные интерактивные (хотя бы) программы легче
> отлаживать и притирать друг к другу не включая в HEAD сизифа.
> Ибо эта работа требует времени и промежуточных результатов для
> тестирования.

_И_ в случае подсистем или того же fx+extensions --
координированной работы нескольких человек.


On Tue, Jun 16, 2009 at 04:19:02AM +0400, Alexey Gladkov wrote:
> > При этом ты выкладываешь сборки firefox в people и даёшь ни
> > них ссылки.
> Именно. Но в эти репозитории не могут собирать другие
> и перекладывать пакеты из них в сизиф неудобно.

И следить за ними -- тоже.

> > Вопрос в том, "карманы" какой формы подойдут тебе и
> > пользователям пакетов, которые ты собираешь, больше, чем
> > репозитории в people.
> То что подойдёт всем уже выясняется некоторое время во многих тредах.

При этом один из основных вопросов -- вообще есть желание слышать
или нет.  Потому как можно хором убеждать, что нужно, но не убедить.


On Tue, Jun 16, 2009 at 04:15:00AM +0400, Evgeny Sinelnikov wrote:
> > Есть другие соображения на эту тему?
> Кроме того, текущая модель, не даёт возможности делать "мягкие"
> bootstrap'ы. Сейчас это всегда волевое решение.

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

> - средство для оценки и самооценки результатов сборок новичков.
> Дело в том, что ни один новичок с ходу, скорее всего, не
> придумает куда ему выкладывать свои предварительные наработки.
> Таким образом он вынужден долго топтаться на месте, вместо того
> чтобы получить грамотную оценку своих результатов у коллег из
> Team.

Мало того, как смотреть в глаза интересным людям в community@
и sisyphus@, которых приглашаешь сюда, а здесь им презрительно
кидают "неудачник"?  Действительно, идея at@ про peer review
технически более удобореализуема при помощи обособленных репо
без того, чтобы "позориться" в сизифе.

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

Это одно из главных; удивлён, что Дима не заметил(?) письма ab@:
http://lists.altlinux.org/pipermail/sisyphus/2009-May/339495.html

> И да... всё это можно делать отдельно на своей какой-то базе...
> Но от этого, мне кажется пропадает какое-то единство при работе
> в команде...  Я ведь могу попытаться сделать описанное и на
> git.etersoft.ru. Но вы ведь сами понимаете, что это будет
> маргинальный ресурс.

Ну этого как раз не стоит бояться, alt.linux.kiev.ua тоже был
некоторое время маргинальным ресурсом, как и некоторые рассылки
на lists.osdn.org.ua.  Главное, хоть что-то пригодилось и пошло
дальше (sisyphus.ru, sysadmins@).


On Tue, Jun 16, 2009 at 07:37:23AM +0400, Денис Смирнов wrote:
> DVL> Я на данный момент не вижу, в чём заключается значимое преимущество
> DVL> централизованных "карманов" для предварительного тестирования, о которых
> DVL> так много говорят последнее время, над распределёнными "карманами", которые
> DVL> каждый может устроить где угодно при наличии соответствующих ресурсов.
> DVL> Могу лишь предположить:
> 1. Затраты времени на создание этих распределенных карманов. То
> есть это означает необходимость каждому поднимать у себя girar,

Даже если не каждому, а сделать стопку таких точек -- я не очень
себе представляю авторизацию на них без ещё одного кусочка
инфраструктуры вроде ldap.altlinux.org с публичными ключами.

> DVL> - доступность (централизованная сборка в среднем более доступна всем
> DVL>   заинтересованным);
> Не каждый вообще имеет ресурсы для того чтобы что-то куда-то
> удобно выкладывать. Скажем у меня есть свой сервер на площадке,
> однако у меня пока не было времени развернуть там аналог
> git.alt, да еще и прикрутить туда pocket'ы.

Хотя ты бы тоже скорее всего согласился предоставить часть его
ресурсов, поскольку это было озвучено как один из важных вопросов?

> DVL> - интеграция (централизованный "карман" теоретически должно быть немного
> DVL>   легче интегрировать в "материнский" репозиторий);
> Это является наиболее существенным преимуществом. Поясню --
> использоваине pocket'ов само по себе это дополнительное
> усложнение workflow разработки.

Необязательно, если не отменяется и текущий путь.  Например,
не вижу смысла усложнять попадание в сизиф "листьев", от которых 
ничто не зависит по сборке и в рантайме, в случае несущественных
изменений и уверенности сборщика в достаточности своей проверки.

Вот доберусь обновить man-pages-uk -- так главная проблема с
кодировками будет сразу видна, и покеты не нужны, потому как 
в любом разе некритично.

> И если они хорошо интегрированы в git.alt, то будут причины
> _сначала_ собирать в pocket для тестирования, и в последующем
> выполнять перенос. Как минимум было бы важно чтобы этот
> workflow использовался для критичных подсистем -- kernel, xorg.

Угу.

> Да и alterator'у бы не помешал.

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

> > На данный момент мне эти преимущества не кажутся значимыми.

Ну а мне преимущества git.alt не кажутся значимыми.  Серьёзно,
SCM-то можно и локально использовать, а трафик нонче не проблема.
Собственно, потому я этими преимуществами и пользуюсь от случая
к случаю, а не постоянно и исключительно.

> > Грубо говоря, я не вижу, каким образом появления
> > централизованных "карманов" заметно повысит качество
> > предварительного ручного тестирования.

Дим, ты когда-нибудь что-нибудь из people помогал тестировать?

> > Есть другие соображения на эту тему?
> Несмотря на разговоры о карманах в течении нескольких _лет_ я
> пока ни у кого не видел собственной инфраструктуры карманов,
> которую бы он использовал для публикации. Таким образом есть
> основания считать что без появления карманов на git.alt эта
> технология использоваться на практике не будет.

У нас.  Повторюсь, в мире и это уже нашло применение, пока у нас
опять всё продумано и на том и встало.

Мне вот в 2005 было досадно, что в Ubuntu очень много _сделали_
продуманного гораздо раньше у нас по части инфраструктуры той же.
Хотя не думаю, что они позаимствовали идеи -- просто уже витало.

> Однако тот факт что некоторые пакеты необходимо публиковать
> до отправки в Сизиф, как мне кажется, очевиден.

Да вот да.  Но почему-то не всем.  Сам не пойму, почему,
но не думаю, что из вредности.

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

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

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

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

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
----------------------------------------------------------------------------

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

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

[Michael Shigorin]

On Tue, Jun 16, 2009 at 10:53:44PM +0400, Денис Смирнов wrote:
> MS> Угу, причём и для простых случаев вроде смены soname мороки
> MS> получается многовато.
> По поводу смены soname я уже напоминал про то, что если такая
> смена требует всяких shared task и прочего -- значит тот кто ее
> делает не читал SharedLibsPolicy.

Не всегда осмысленно оставлять старый сонейм.
Например, если его поддержка апстримом закончена.

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

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

[Afanasov Dmitry]

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

On Tue, Jun 16, 2009 at 10:24:28PM +0300, Michael Shigorin wrote:
> On Tue, Jun 16, 2009 at 10:53:44PM +0400, Денис Смирнов wrote:
> > MS> Угу, причём и для простых случаев вроде смены soname мороки
> > MS> получается многовато.
> > По поводу смены soname я уже напоминал про то, что если такая
> > смена требует всяких shared task и прочего -- значит тот кто ее
> > делает не читал SharedLibsPolicy.
> 
> Не всегда осмысленно оставлять старый сонейм.
> Например, если его поддержка апстримом закончена.
наглядный пример - gnutls13 (версия 2.0.4)
-- 
С уважением
Афанасов Дмитрий

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

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

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

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

On Tue, Jun 16, 2009 at 10:24:28PM +0300, Michael Shigorin wrote:

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

В SharedLibsPolicy описана эта процедура.

Вопрос -- считаешь ли ты что наличие в репо пакета который требует старый
soname и мантейнеру которого нет желания и причин сейчас переезжать на
новый поводом для удаления пакета из репо, например? ;)

Второе -- независимо от этого apt если делать переезд игнорируя
SharedLibsPolicy склеит ласты на upgrade/dist-upgrade.

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

http://freesource.info
----------------------------------------------------------------------------

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

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

[Michael Shigorin]

On Wed, Jun 17, 2009 at 06:49:40AM +0400, Денис Смирнов wrote:
> >> По поводу смены soname я уже напоминал про то, что если такая
> >> смена требует всяких shared task и прочего -- значит тот кто ее
> >> делает не читал SharedLibsPolicy.
> MS> Не всегда осмысленно оставлять старый сонейм.
> MS> Например, если его поддержка апстримом закончена.
> В SharedLibsPolicy описана эта процедура.

Держания неподдерживаемой версии, используемой, скажем,
сетевым софтом?

> Вопрос -- считаешь ли ты что наличие в репо пакета который
> требует старый soname и мантейнеру которого нет желания и
> причин сейчас переезжать на новый поводом для удаления пакета
> из репо, например? ;)

Нет, если с ним нет cri/blo вроде sec.

> Второе -- независимо от этого apt если делать переезд игнорируя
> SharedLibsPolicy склеит ласты на upgrade

Возможно.

> dist-upgrade.

Маловероятно, для этого пакет-клиент библиотеки должен был
вылететь из сизифа между бранчами или не попасть в новый бранч.
Для важной софтины я предпочту на этой точке задуматься -- брать
старый или поддерживать самому в актуальном состоянии.

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

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

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

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

On Wed, Jun 17, 2009 at 09:20:01PM +0300, Michael Shigorin wrote:

MS>>> Не всегда осмысленно оставлять старый сонейм.
MS>>> Например, если его поддержка апстримом закончена.
>> В SharedLibsPolicy описана эта процедура.
MS> Держания неподдерживаемой версии, используемой, скажем,
MS> сетевым софтом?

Да, все очевидно. Поясню на примере:
скажем есть некая библиотека libbugs. И есть два сетевых приложения -- A
и B, которые ее используеют. Так уж получилось, что A мантейнишь ты, а B
мантейню я. Оба приложения сложные, без поллитра в них не разберешься, и
фиксить эти предложения кому-то кроме мантейнера крайне трудоемко.

Теперь представим себе ситуацию -- у libbugs вышла версия с новым soname.
А в версии со старым soname обнаружили критическую багу.

Ты, как сознательный мантейнер, вместе с мантейнером libbugs в shared
task'е радостно исправляешь свой пакет A. А я, как несознательный
мантейнер, уехал на неделю в отпуск. Вы с мантейнером libbugs попытались
починить B но у вас ничего не получилось. Варианты действий:

- ждать моего возвращения из отпуска;
- звонить мне на мобильный с просьбой вернуться из отпуска пораньше;
- вынести B на время из репозитория;
- спокойненько собрать libbugs с новым soname согласно sharedlibspolicy, и
  повесить на B blocker, одновременно отписав мне в почту;

Как ты понимаешь, если будет выбран вариант 3, а при этом приложение B на
самом деле используется всего парой членов тим, да еще и в защищенных
подсетях, то кто-нибудь обидется.

Поэтому лично я являюсь сторонииком 4-го варианта.

А процедура удаления пакета, который уже не используется в
SharedLibsPolicy прописана. Разве что можно еще repocop научить
отстреливать тех кто requires подобны библиотеки.

>> Вопрос -- считаешь ли ты что наличие в репо пакета который
>> требует старый soname и мантейнеру которого нет желания и
>> причин сейчас переезжать на новый поводом для удаления пакета
>> из репо, например? ;)
MS> Нет, если с ним нет cri/blo вроде sec.

Какой срок ты считаешь разумным для отстрела пакета при наличии
critical/block bug'и? Поясню -- без исполнения SharedLibsPolicy пока ты не
острелишь пакет который не фиксят -- не можешь залить фикс для других
пакетов, получается.

>> Второе -- независимо от этого apt если делать переезд игнорируя
>> SharedLibsPolicy склеит ласты на upgrade
MS> Возможно.
>> dist-upgrade.
MS> Маловероятно, для этого пакет-клиент библиотеки должен был
MS> вылететь из сизифа между бранчами или не попасть в новый бранч.
MS> Для важной софтины я предпочту на этой точке задуматься -- брать
MS> старый или поддерживать самому в актуальном состоянии.

Миша, ты исходишь из того что apt поступает _разумно_. А apt поступает не
всегда разумно, и вместо обновления библиотеки иногда предпочитает вынести
пол-системы. Ты ведь неоднократно это наблюдал, когда набираешь apt-get
dist-upgrade а тебе предлагают вместо обновления -- удаления. Так вот
именно для решения _этой_ проблемы SharedLibsPolicy была написана.

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

http://freesource.info
----------------------------------------------------------------------------

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

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

[Michael Shigorin]

On Thu, Jun 18, 2009 at 12:00:08PM +0400, Денис Смирнов wrote:
> >> Вопрос -- считаешь ли ты что наличие в репо пакета который
> >> требует старый soname и мантейнеру которого нет желания и
> >> причин сейчас переезжать на новый поводом для удаления
> >> пакета из репо, например? ;)
> MS> Нет, если с ним нет cri/blo вроде sec.
> Какой срок ты считаешь разумным для отстрела пакета при наличии
> critical/block bug'и? Поясню -- без исполнения SharedLibsPolicy
> пока ты не острелишь пакет который не фиксят -- не можешь
> залить фикс для других пакетов, получается.

Я ж не говорю -- "или/или".  Голова для поиска решения дана.

> Миша, ты исходишь из того что apt поступает _разумно_.

Отнюдь. :)

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

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

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

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

On Fri, Jun 19, 2009 at 01:39:46AM +0300, Michael Shigorin wrote:
>>>> Вопрос -- считаешь ли ты что наличие в репо пакета который
>>>> требует старый soname и мантейнеру которого нет желания и
>>>> причин сейчас переезжать на новый поводом для удаления
>>>> пакета из репо, например? ;)
MS>>> Нет, если с ним нет cri/blo вроде sec.
>> Какой срок ты считаешь разумным для отстрела пакета при наличии
>> critical/block bug'и? Поясню -- без исполнения SharedLibsPolicy
>> пока ты не острелишь пакет который не фиксят -- не можешь
>> залить фикс для других пакетов, получается.
MS> Я ж не говорю -- "или/или".  Голова для поиска решения дана.
>> Миша, ты исходишь из того что apt поступает _разумно_.
MS> Отнюдь. :)

Фишка в том, что если даже транзакция обновления в Сизифе прошла
нормально, то во-первых от идиотизма apt при обновлении это не спасет, а
во-вторых точечные обновления -- сломает.

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

http://freesource.info
----------------------------------------------------------------------------

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

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

[Dmitry V. Levin]

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

On Tue, Jun 16, 2009 at 01:36:11PM +0300, Michael Shigorin wrote:
[...]
> > > Так вот и "карманы" нужны для упрощения работы разработчиков Сизифа.
> > В этом вся соль.  Прийти бы к взаимопониманию, какие карманы
> > какой формы нужны
> 
> По части формы -- просьба к понявшим, чего им-то надо,
> фиксировать здесь: http://www.altlinux.org/Pockets

Спасибо.  Я ещё немного подожду, пока все желающие выскажутся на тему
формы карманов, и потом напишу, какие варианты были предложены, насколько
они близки к действующей архитектуре git.alt и насколько сложно было бы
их реализовать.


-- 
ldv

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

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

[Alexey I. Froloff]

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

On Wed, Jun 17, 2009 at 02:29:25AM +0400, Dmitry V. Levin wrote:
> Спасибо.  Я ещё немного подожду, пока все желающие выскажутся на тему
> формы карманов, и потом напишу, какие варианты были предложены, насколько
> они близки к действующей архитектуре git.alt и насколько сложно было бы
> их реализовать.
Одну реализацию можно сделать уже сейчас.  Проиндексировать
build/*/$arch/{rpms,srpm} (кривоскрипт я сюда постил, репозитарий
делается хардлинками) и сделать режим сборки "собрать но не
публиковать".  Собираться это будет как и все остальные задачи
(при этом не нужно делать некоторых проверок), "карман" будет
жить пока задача не заархивируется, "переложить" "карман" в сизиф
можно повторной сборкой задачи.  Как приятный бонус получим
репозитарии пакетов от неудачных сборок, чтобы мантейнерам было
проще чинить свои пакеты (разбираться с новой версией какой-то
либы в локальном хашере, а не по логам сборки).


-- 
Regards,
Sir Raorn.

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

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

[Dmitry V. Levin]

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

On Wed, Jun 17, 2009 at 02:52:58AM +0400, Alexey I. Froloff wrote:
> On Wed, Jun 17, 2009 at 02:29:25AM +0400, Dmitry V. Levin wrote:
> > Спасибо.  Я ещё немного подожду, пока все желающие выскажутся на тему
> > формы карманов, и потом напишу, какие варианты были предложены, насколько
> > они близки к действующей архитектуре git.alt и насколько сложно было бы
> > их реализовать.
> Одну реализацию можно сделать уже сейчас.  Проиндексировать
> build/*/$arch/{rpms,srpm} (кривоскрипт я сюда постил, репозитарий
> делается хардлинками) и сделать режим сборки "собрать но не
> публиковать".  Собираться это будет как и все остальные задачи
> (при этом не нужно делать некоторых проверок), "карман" будет
> жить пока задача не заархивируется, "переложить" "карман" в сизиф
> можно повторной сборкой задачи.  Как приятный бонус получим
> репозитарии пакетов от неудачных сборок, чтобы мантейнерам было
> проще чинить свои пакеты (разбираться с новой версией какой-то
> либы в локальном хашере, а не по логам сборки).

Это похоже на развёрнутое описание кармана самой простой формы:
http://lists.altlinux.org/pipermail/devel/2008-July/157594.html


-- 
ldv

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

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

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

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

On Wed, Jun 17, 2009 at 03:14:31AM +0400, Dmitry V. Levin wrote:

>> Одну реализацию можно сделать уже сейчас.  Проиндексировать
>> build/*/$arch/{rpms,srpm} (кривоскрипт я сюда постил, репозитарий
>> делается хардлинками) и сделать режим сборки "собрать но не
>> публиковать".  Собираться это будет как и все остальные задачи
>> (при этом не нужно делать некоторых проверок), "карман" будет
>> жить пока задача не заархивируется, "переложить" "карман" в сизиф
>> можно повторной сборкой задачи.  Как приятный бонус получим
>> репозитарии пакетов от неудачных сборок, чтобы мантейнерам было
>> проще чинить свои пакеты (разбираться с новой версией какой-то
>> либы в локальном хашере, а не по логам сборки).
DVL> Это похоже на развёрнутое описание кармана самой простой формы:
DVL> http://lists.altlinux.org/pipermail/devel/2008-July/157594.html

Да, и это уже замечательный первый шаг. Следующие шаги:

- сделать пометки task'ов как pocket'ов, которые будут обрабатываться
  несколько другим способом:
- после того как task-pocket был запущен, добавление в него пакета
  означает запуск этого пакета на сборку (а не ожидание перезапуска
  task'а).
- возможность давать имя таким task'ам;
- поименованый task не архивируется автоматически;
- в такие task'и можно собирать один и тот же пакет несколько раз в рамках
  одного task'а;
- команда task status -- выводит:
  - timestamp когда был создан pocket, или timestamp последнего task merge
	(после реализации task merge)
  - tag'и из которых были собраны пакеты в этот pocket
- команда task merge -- попытка пересобрать содержимое task'а на
  обновленном репозитории, на базе которого был сделан этот task;
- публикация "кэширующего git repo" для этого pocket;

На любом этапе можно будет добавить параллельную сборку, независимо от
общей очереди. Так как у нас нет здесь необходимости в последовательной
сборке этих task'ов, то мы не обязаны даже собирать task целиком, и тем
самым блокировать других мантейнеров. Таким образом создание pocket'а с
KDE не будет блокировать остальные pocket'ы на сутки.

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

http://freesource.info
----------------------------------------------------------------------------


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

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

[Evgeny Sinelnikov]

16 июня 2009 г. 2:33 пользователь Dmitry V. Levin (ldv@altlinux.org) написал:
> On Sun, Jun 14, 2009 at 03:51:18PM +0300, Kirill A. Shutemov wrote:
>> 2009/6/14 Kirill Maslinsky <kirill@altlinux.org>:
> [...]
>> > Формализованные тесты на функциональность, включённые в пакет мантейнером,
>> > выполняемые после успешной сборки пакета в безопасном окружении,
>> > гаранитрующие отсутствие регрессий по данной функциональности
>> > при пересборке в любом окружении.
>>
>> Ядро и всё околожелезное так не протестируешь в принципе. Многое из оставшегося
>> протестировать в автоматическом режиме тоже малореально.
>
> Если ставить перед собой цель увеличивать покрытие автоматическими
> тестами, и работать в этом направлении, то можно получить положительный
> результат, недостижимый при тестировании вручную.  Это два ортогональных
> подхода, которые в принципе можно развивать независимо друг от друга.
>
> Например, https://bugzilla.altlinux.org/show_bug.cgi?id=20463 не возникло
> бы, если бы на момент сборки пакета было реализовано соответствующее
> автоматическое тестирование.  Собственно говоря, я рассчитывал, что
> тестирование принимаемых в Сизиф пакетов пересборкой зависящих от них
> пакетов будет введено в строй ещё до окончания весны, но один не очень
> хороший человек (по запросу я готов назвать его имя) нарушил
> договорённость об использовании оборудования для этой цели.
>
> Я на данный момент не вижу, в чём заключается значимое преимущество
> централизованных "карманов" для предварительного тестирования, о которых
> так много говорят последнее время, над распределёнными "карманами", которые
> каждый может устроить где угодно при наличии соответствующих ресурсов.
> Могу лишь предположить:
> - информация (централизованный "карман" немного легче обнаружить);
> - доступность (централизованная сборка в среднем более доступна всем
>  заинтересованным);
> - интеграция (централизованный "карман" теоретически должно быть немного
>  легче интегрировать в "материнский" репозиторий);
> На данный момент мне эти преимущества не кажутся значимыми.
> Грубо говоря, я не вижу, каким образом появления централизованных
> "карманов" заметно повысит качество предварительного ручного тестирования.
>
> Есть другие соображения на эту тему?
>

Да, кроме того, что уже было сказано о самодостаточной ценности
"упрощения работы разработчиков Сизифа", с которой я, в принципе
согласен, я хочу привести ещё ряд аргументов:
- распределённая модель разработки (Я уже приводил свою аналогию с
Git) - такая модель должна снизить издержки на предварительное
тестирование, которым, при текущей модели, вынуждены заниматься все
вместе. При этом взаимовлияние ошибок сейчас является трудно
отслеживаемым. Кроме того, текущая модель, не даёт возможности делать
"мягкие" bootstrap'ы. Сейчас это всегда волевое решение.
- средство для оценки и самооценки результатов сборок новичков. Дело в
том, что ни один новичок с ходу, скорее всего, не придумает куда ему
выкладывать свои предварительные наработки. Таким образом он вынужден
долго топтаться на месте, вместо того чтобы получить грамотную оценку
своих результатов у коллег из Team.
- возможность конкуренции и параллельных сборок в команде не
приводящая к конфликтам, а позволяющая вести технические споры на
техническом поле. Например, все вопросы по сборке samba4, а теперь уже
есть резон собирать её совместно с samba3, я мог бы выполнить в таком
отдельном Дедалусе под задачу. Последнее здесь мне кажется наиболее
важным. Исходный Дедалус был свалкой, мне бы не хотелось смешивать
сборочные среды своих отдельных задач.

И да... всё это можно делать отдельно на своей какой-то базе... Но от
этого, мне кажется пропадает какое-то единство при работе в команде...
Я ведь могу попытаться сделать описанное и на git.etersoft.ru. Но вы
ведь сами понимаете, что это будет маргинальный ресурс.

-- 
Sin (Sinelnikov Evgeny)

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

[Slava Semushin]

16 июня 2009 г. 7:15 пользователь Evgeny Sinelnikov (sin@altlinux.ru) написал:
[...]
> И да... всё это можно делать отдельно на своей какой-то базе...

М. Хорошая идея. Потому что сейчас я вижу только одни обсуждения и уже
было начал думать, что на этом всё закончится.

> Но от этого, мне кажется пропадает какое-то единство при работе в команде...

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

> Я ведь могу попытаться сделать описанное и на git.etersoft.ru. Но вы
> ведь сами понимаете, что это будет маргинальный ресурс.

Попытайтесь, если есть время/желание и возможность. Возможно ваши
наработки потом возьмут на git.alt, или же на git.alt подобное так и
не появится, а вашим сервисом некоторые будут пользоваться. (Например,
я время от времени пользуюсь акаунтом на вашем сборочном сервисе, за
что большое спасибо lav@!)


-- 
+ Slava Semushin | slava.semushin @ gmail.com
+ ALT Linux Team | php-coder @ altlinux.ru

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

[REAL]

Dmitry V. Levin пишет:
> Если ставить перед собой цель увеличивать покрытие автоматическими
> тестами, и работать в этом направлении, то можно получить положительный
> результат, недостижимый при тестировании вручную.

Что нужно прописать в спеке, чтобы в хэшере можно было бы тестировать 
вещи вроде обращения к alsa, gstreamer или запустить mpirun?

-- 

REAL aka Евгений Ростовцев, программист ЦНИТ КемГУ

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

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

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

On Tue, Jun 16, 2009 at 02:33:38AM +0400, Dmitry V. Levin wrote:

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

Да, именно это я и пытался донести до at@. Есть вещи которые вручную
практически невозможно полноцено тестировать, и роботы справятся с этой
работой безусловно лучше. Есть же вещи которые роботы или пока еще не
умеют тестировать (и тогда их надо научить), или написание тестов для
таких вещей является практически невозможным ввиду непредсказуемого
количество потенциальных проблемных ситуаций, которые выявляются
исключительно при тестировании человеком в конкретной конфигурации.

Например я плохо себе представляю автоматическое тестирование xorg без
тестовой лаборатории стоимостью в сотни тысяч долларов.

DVL> Я на данный момент не вижу, в чём заключается значимое преимущество
DVL> централизованных "карманов" для предварительного тестирования, о которых
DVL> так много говорят последнее время, над распределёнными "карманами", которые
DVL> каждый может устроить где угодно при наличии соответствующих ресурсов.
DVL> Могу лишь предположить:

1. Затраты времени на создание этих распределенных карманов. То есть это
означает необходимость каждому поднимать у себя girar, либо использовать
для сборки srpm. Первое достаточно сложно, второе мне не нравится так как
провоцирует на дальнейшее использование srpm.

2. Такой pocket, если он находится в git.alt может быть использован как
task, который отправится в Сизиф. Таким образом в тот момент когда
тестирование будет завершено, владельцу такого кармана будет достаточно
одной команды чтобы сделать попытку отправить этот pocket в Сизиф.

DVL> - информация (централизованный "карман" немного легче обнаружить);

Это также весьма важно.

DVL> - доступность (централизованная сборка в среднем более доступна всем
DVL>   заинтересованным);

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

DVL> - интеграция (централизованный "карман" теоретически должно быть немного
DVL>   легче интегрировать в "материнский" репозиторий);

Это является наиболее существенным преимуществом. Поясню -- использоваине
pocket'ов само по себе это дополнительное усложнение workflow разработки.
И если они хорошо интегрированы в git.alt, то будут причины _сначала_
собирать в pocket для тестирования, и в последующем выполнять перенос. Как
минимум было бы важно чтобы этот workflow использовался для критичных
подсистем -- kernel, xorg. Да и alterator'у бы не помешал.

DVL> На данный момент мне эти преимущества не кажутся значимыми.
DVL> Грубо говоря, я не вижу, каким образом появления централизованных
DVL> "карманов" заметно повысит качество предварительного ручного тестирования.
DVL> Есть другие соображения на эту тему?

Несмотря на разговоры о карманах в течении нескольких _лет_ я пока ни у
кого не видел собственной инфраструктуры карманов, которую бы он
использовал для публикации. Таким образом есть основания считать что без
появления карманов на git.alt эта технология использоваться на практике не
будет.

Однако тот факт что некоторые пакеты необходимо публиковать до отправки в
Сизиф, как мне кажется, очевиден.

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

http://freesource.info
----------------------------------------------------------------------------

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