ALT Linux Team development discussions
 help / color / mirror / Atom feed
From: "Vladimir D. Seleznev" <vseleznv@altlinux.org>
To: ALT Linux Team development discussions <devel@lists.altlinux.org>
Subject: Re: [devel] [I] rpm-build-vm: vm-run
Date: Tue, 15 Oct 2019 22:06:20 +0300
Message-ID: <20191015190620.GA2576259@portlab> (raw)
In-Reply-To: <194fdb47-10a6-42d1-467c-f6ddd77b6638@basealt.ru>

On Tue, Oct 15, 2019 at 02:30:16PM +0300, Anton Farygin wrote:
> On 15.10.2019 10:32, Michael Shigorin wrote:
> > Зачем это тащить в hasher, особенно если на сборочнице?
> > Собрал тестовое задание, гоняешь по нему спокойно тесты.
> 
> Есть цель сделать автоматическое тестирование воспроизводимым образом и 
> сразу в процессе сборки пакета.

Если воспроизводимым образом, то прокидывать репозитории в сборочную
среду не нужно: все требуемые пакеты нужно указать в BuildRequires.

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

Отдельно замечу про стабильные ветки репозитория. Стабильность означает
неизменность общего поведения приложений. Т.е., не должно быть ситуации,
когда в результате обновления пакета в стабильной ветке его поведение
меняется, например, на противоположное. И стабильность невозможно в
общем случае гарантировать обширным тестированием пакетов: довольно
трудно формализовать неизменность поведения, в отличие от некорректного
поведения программы. В некоторых проектах в стабильных ветках
замораживают версии пакетов и бэкпортируют только security fixes. Это
довольно строгое требование, особенно для прикладных программ, но
оправданное для базовой системы. А когда, допустим, в стабильной ветке
находится некая MyNiceDB, которая к некоторому моменту уже устарела, и
хочется новую функциональность из новой версии (скажем, третьей), то
лучше не обновлять эту версию, а собрать новый пакет MyNiceDB3
(возможно, с правильным указанием конфликтов). Таким образом никому
поведение не будет сломано, и кому надо, сможет воспользоваться новой
версией с новой функциональностью. То же самое можно сказать и про
разделяемые библиотеки (shared library policy в т.ч. для этого
предлагалось).

-- 
   С уважением,
   Владимир Селезнев


  parent reply	other threads:[~2019-10-15 19:06 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-13 21:29 Vitaly Chikunov
2019-10-14  6:18 ` Anton Farygin
2019-10-14 11:16   ` Vitaly Chikunov
2019-10-14 11:25     ` Anton Farygin
2019-10-14 12:22       ` Vitaly Chikunov
2019-10-14 12:33         ` Anton Farygin
2019-10-14 12:36           ` Alexey V. Vissarionov
2019-10-14 12:39           ` Vitaly Chikunov
2019-10-14 12:42             ` Alexey V. Vissarionov
2019-10-14 20:54           ` Dmitry V. Levin
2019-10-14 21:53             ` Vladimir D. Seleznev
2019-10-15  3:56               ` Anton Farygin
2019-10-15  6:19                 ` Vladimir D. Seleznev
2019-10-15  7:05                   ` Anton Farygin
2019-10-15  7:17                     ` Alexey V. Vissarionov
2019-10-15 11:31                       ` Anton Farygin
2019-10-15  7:32                     ` Michael Shigorin
2019-10-15 11:30                       ` Anton Farygin
2019-10-15 18:22                         ` Dmitry V. Levin
2019-10-15 18:28                           ` Anton Farygin
2019-10-15 18:33                             ` Dmitry V. Levin
2019-10-15 18:48                               ` Anton Farygin
2019-10-15 19:08                                 ` Vladimir D. Seleznev
2019-10-16  4:48                                   ` Anton Farygin
2019-10-16  4:51                                     ` Alexey V. Vissarionov
2019-10-15 19:24                                 ` Dmitry V. Levin
2019-10-15 19:44                                   ` Vitaly Chikunov
2019-10-16  4:52                                     ` Anton Farygin
2019-10-15 22:33                                   ` Alexey V. Vissarionov
2019-10-16  4:56                                   ` Anton Farygin
2019-10-15 19:06                         ` Vladimir D. Seleznev [this message]
2019-10-16  5:05                           ` Anton Farygin
2019-10-18  0:40                             ` Vladimir D. Seleznev
2019-10-18  4:48                               ` Anton Farygin
2019-10-18 17:43                                 ` Vladimir D. Seleznev
2019-10-19  5:16                                   ` Anton Farygin
2019-10-18  8:32                               ` Michael Shigorin
2019-10-18  9:12                                 ` Anton Farygin
2019-10-18  9:29                                   ` Michael Shigorin
2019-10-18  9:36                                     ` Anton Farygin
2019-10-18 10:39                                       ` [devel] [JT] сборочница 3.0, qa/ci, ресурсы, приоритеты (was: [I] rpm-build-vm: vm-run) Michael Shigorin
2019-10-18 10:52                                         ` [devel] [JT] сборочница 3.0, qa/ci, ресурсы, приоритеты Anton Farygin
2019-10-15  4:04             ` [devel] [I] rpm-build-vm: vm-run Anton Farygin
2019-10-15  4:16               ` Alexey V. Vissarionov
2019-10-15  5:22                 ` Anton Farygin
2019-10-15  5:25                   ` Alexey V. Vissarionov
2019-12-11 11:15 ` Anton Farygin
2019-12-11 12:33   ` Vitaly Chikunov
2019-12-11 16:48     ` Anton Farygin
2019-12-12 15:12       ` Anton Farygin
2019-12-12 16:06         ` Vitaly Chikunov
2019-12-12 16:25           ` Anton Farygin
2019-12-16  4:04           ` Anton Farygin
2019-12-12 16:21 ` [devel] [I] rpm-build-vm: vm-run (update 1.3) Vitaly Chikunov
2020-02-18  7:56 ` [devel] [I] rpm-build-vm: vm-run Oleg Solovyov
2020-02-18 10:32   ` Vitaly Chikunov

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=20191015190620.GA2576259@portlab \
    --to=vseleznv@altlinux.org \
    --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