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