ALT Linux Team development discussions
 help / color / mirror / Atom feed
From: Evgeny Sinelnikov <sin@altlinux.ru>
To: ALT Linux Team development discussions <devel@lists.altlinux.org>
Subject: Re: [devel] про автоматическое и ручное тестирование пакетов
Date: Tue, 16 Jun 2009 04:15:00 +0400
Message-ID: <921f6bb40906151715x72157e9bxa93d3bfdf24b5162@mail.gmail.com> (raw)
In-Reply-To: <20090615223338.GA28555@wo.int.altlinux.org>

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)

  parent reply	other threads:[~2009-06-16  0:15 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-15 22:33 Dmitry V. Levin
2009-06-15 22:35 ` Mikhail Gusarov
2009-06-15 23:00   ` Dmitry V. Levin
2009-06-15 23:06     ` Mikhail Gusarov
2009-06-15 23:25       ` Dmitry V. Levin
2009-06-15 23:43         ` Alexey Gladkov
2009-06-16  0:00           ` Dmitry V. Levin
2009-06-16  3:43             ` Денис Смирнов
2009-06-16  6:47             ` Anton Farygin
2009-06-16  5:47         ` Afanasov Dmitry
2009-06-16  0:03     ` Alexey I. Froloff
2009-06-17  5:14       ` Alexey Tourbin
2009-06-17  5:25         ` Alexey Tourbin
2009-06-17 18:28           ` Michael Shigorin
2009-06-18  7:18             ` Alexey Tourbin
2009-06-18 10:46               ` Dmitry V. Levin
2009-06-18 11:08                 ` Mikhail Gusarov
2009-06-18 11:09                   ` Dmitry V. Levin
2009-06-18 11:14                     ` Mikhail Gusarov
2009-06-18 22:41                 ` Michael Shigorin
2009-06-17  9:03         ` Alexey I. Froloff
2009-06-17 18:26         ` Michael Shigorin
2009-06-15 23:30 ` Alexey Gladkov
2009-06-15 23:51   ` Dmitry V. Levin
2009-06-16  0:19     ` Alexey Gladkov
2009-06-16 10:36   ` Michael Shigorin
2009-06-16 18:53     ` Денис Смирнов
2009-06-16 19:24       ` Michael Shigorin
2009-06-16 21:13         ` Afanasov Dmitry
2009-06-17  2:49         ` Денис Смирнов
2009-06-17 18:20           ` Michael Shigorin
2009-06-18  8:00             ` Денис Смирнов
2009-06-18 22:39               ` Michael Shigorin
2009-06-19  7:01                 ` Денис Смирнов
2009-06-16 22:29     ` Dmitry V. Levin
2009-06-16 22:52       ` Alexey I. Froloff
2009-06-16 23:14         ` Dmitry V. Levin
2009-06-17  2:58           ` Денис Смирнов
2009-06-16  0:15 ` Evgeny Sinelnikov [this message]
2009-06-17 12:32   ` Slava Semushin
2009-06-16  3:29 ` REAL
2009-06-16  3:37 ` Денис Смирнов

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=921f6bb40906151715x72157e9bxa93d3bfdf24b5162@mail.gmail.com \
    --to=sin@altlinux.ru \
    --cc=devel@lists.altlinux.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

ALT Linux Team development discussions

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://lore.altlinux.org/devel/0 devel/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 devel devel/ http://lore.altlinux.org/devel \
		devel@altlinux.org devel@altlinux.ru devel@lists.altlinux.org devel@lists.altlinux.ru devel@linux.iplabs.ru mandrake-russian@linuxteam.iplabs.ru sisyphus@linuxteam.iplabs.ru
	public-inbox-index devel

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://lore.altlinux.org/org.altlinux.lists.devel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git