[devel] I: gyle: --fail-early by default

[devel] I: gyle: --fail-early by default

[Dmitry V. Levin]

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

Hi,

task new теперь устанавливает атрибут fail-early, другими словами,
build теперь по умолчанию --fail-early.

Для возврата прежнего поведения появились
build --fail-late и task run --fail-late.

task run без указания --fail-early/--fail-late теперь оставляет неизменным
значение атрибута fail-early, установленное для этого задания ранее.


-- 
ldv

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [devel] I: gyle: --fail-early by default

[Yuri Sedunov]

В Вс, 17/03/2019 в 15:03 +0300, Dmitry V. Levin пишет:
> Hi,
> 
> task new теперь устанавливает атрибут fail-early, другими словами,
> build теперь по умолчанию --fail-early.
> 
> Для возврата прежнего поведения появились
> build --fail-late и task run --fail-late.
> 
> task run без указания --fail-early/--fail-late теперь оставляет
> неизменным
> значение атрибута fail-early, установленное для этого задания ранее.

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

-- 
Yuri N. Sedunov

Re: [devel] I: gyle: --fail-early by default

[Dmitry V. Levin]

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

On Sun, Mar 17, 2019 at 03:30:13PM +0300, Yuri Sedunov wrote:
> В Вс, 17/03/2019 в 15:03 +0300, Dmitry V. Levin пишет:
> > Hi,
> > 
> > task new теперь устанавливает атрибут fail-early, другими словами,
> > build теперь по умолчанию --fail-early.
> > 
> > Для возврата прежнего поведения появились
> > build --fail-late и task run --fail-late.
> > 
> > task run без указания --fail-early/--fail-late теперь оставляет
> > неизменным
> > значение атрибута fail-early, установленное для этого задания ранее.
> 
> Еще бы хорошо иметь возможность делать аборт "прямщас", не дожидаясь
> некой "первой возможности".

Да, было бы неплохо.


-- 
ldv

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

[devel] I: gyle --test-only by default

[Dmitry V. Levin]

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

Hi,

task new теперь устанавливает атрибут test-only, другими словами,
сборка заданий теперь по умолчанию --test-only.

Для отправления заданий в репозиторий появились
build --commit и task run --commit.

task run без указания ----test-only/--commit теперь оставляет неизменным
значение атрибута test-only, установленное для этого задания ранее.

Значение атрибута test-only для заданий, созданных до этого изменения,
осталось прежним.


-- 
ldv

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [devel] I: gyle --test-only by default

[Anton Farygin]

18.03.2019 5:03, Dmitry V. Levin пишет:
> Hi,
>
> task new теперь устанавливает атрибут test-only, другими словами,
> сборка заданий теперь по умолчанию --test-only.
>
> Для отправления заданий в репозиторий появились
> build --commit и task run --commit.
>
> task run без указания ----test-only/--commit теперь оставляет неизменным
> значение атрибута test-only, установленное для этого задания ранее.
>
> Значение атрибута test-only для заданий, созданных до этого изменения,
> осталось прежним.
>
Дима, спасибо.

Re: [devel] I: gyle: --fail-early by default

[Ivan A. Melnikov]

On Sun, Mar 17, 2019 at 03:03:52PM +0300, Dmitry V. Levin wrote:
> Hi,
> 
> task new теперь устанавливает атрибут fail-early, другими словами,
> build теперь по умолчанию --fail-early.
> 
> Для возврата прежнего поведения появились
> build --fail-late и task run --fail-late.
> 
> task run без указания --fail-early/--fail-late теперь оставляет неизменным
> значение атрибута fail-early, установленное для этого задания ранее.

Попробовал разобраться, что это значит. Дмитрий, поправьте,
если я ошибаюсь.

Атрибут fail-early управляет поведением girar'а в случае падения
одной из сабтасок на одной из архитектур.

Традиционно (--fail-late) в этом случае сборка на других
архитектурах, где (пока) всё хорошо, продолжается, пока все
сабтаски не будут пересобраны или одна из них не упадёт именно
на этой архитектуре.

При наличии фалга --fail-early (новое поведение по умолчанию)
неудачная сборка на одной из архитектур приводит к abort'у
задачи (аналогично ssh girar task abort $task_id): сброрка
на других архитектурах, где (пока) всё хорошо, будет
остановлена при первой же возможности.

--
  wbr,
    iv m.

Re: [devel] I: gyle --test-only by default

[Sergey V Turchin]

On Monday, 18 March 2019 05:03:20 MSK Dmitry V wrote:
> Hi,
> 
> task new теперь устанавливает атрибут test-only, другими словами,
> сборка заданий теперь по умолчанию --test-only.
Спасибо!

[...]

-- 
Regards, Sergey.

Re: [devel] I: gyle: --fail-early by default

[Dmitry V. Levin]

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

On Mon, Mar 18, 2019 at 10:36:53AM +0400, Ivan A. Melnikov wrote:
> On Sun, Mar 17, 2019 at 03:03:52PM +0300, Dmitry V. Levin wrote:
> > Hi,
> > 
> > task new теперь устанавливает атрибут fail-early, другими словами,
> > build теперь по умолчанию --fail-early.
> > 
> > Для возврата прежнего поведения появились
> > build --fail-late и task run --fail-late.
> > 
> > task run без указания --fail-early/--fail-late теперь оставляет неизменным
> > значение атрибута fail-early, установленное для этого задания ранее.
> 
> Попробовал разобраться, что это значит. Дмитрий, поправьте,
> если я ошибаюсь.
> 
> Атрибут fail-early управляет поведением girar'а в случае падения
> одной из сабтасок на одной из архитектур.
> 
> Традиционно (--fail-late) в этом случае сборка на других
> архитектурах, где (пока) всё хорошо, продолжается, пока все
> сабтаски не будут пересобраны или одна из них не упадёт именно
> на этой архитектуре.
> 
> При наличии фалга --fail-early (новое поведение по умолчанию)
> неудачная сборка на одной из архитектур приводит к abort'у
> задачи (аналогично ssh girar task abort $task_id): сброрка
> на других архитектурах, где (пока) всё хорошо, будет
> остановлена при первой же возможности.

Кроме того, если установлен атрибут fail-early,
то install check заканчивается после первой неудачи.


-- 
ldv

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [devel] I: gyle: --fail-early by default

[Anton Farygin]

18.03.2019 14:56, Dmitry V. Levin пишет:
> On Mon, Mar 18, 2019 at 10:36:53AM +0400, Ivan A. Melnikov wrote:
>> On Sun, Mar 17, 2019 at 03:03:52PM +0300, Dmitry V. Levin wrote:
>>> Hi,
>>>
>>> task new теперь устанавливает атрибут fail-early, другими словами,
>>> build теперь по умолчанию --fail-early.
>>>
>>> Для возврата прежнего поведения появились
>>> build --fail-late и task run --fail-late.
>>>
>>> task run без указания --fail-early/--fail-late теперь оставляет неизменным
>>> значение атрибута fail-early, установленное для этого задания ранее.
>> Попробовал разобраться, что это значит. Дмитрий, поправьте,
>> если я ошибаюсь.
>>
>> Атрибут fail-early управляет поведением girar'а в случае падения
>> одной из сабтасок на одной из архитектур.
>>
>> Традиционно (--fail-late) в этом случае сборка на других
>> архитектурах, где (пока) всё хорошо, продолжается, пока все
>> сабтаски не будут пересобраны или одна из них не упадёт именно
>> на этой архитектуре.
>>
>> При наличии фалга --fail-early (новое поведение по умолчанию)
>> неудачная сборка на одной из архитектур приводит к abort'у
>> задачи (аналогично ssh girar task abort $task_id): сброрка
>> на других архитектурах, где (пока) всё хорошо, будет
>> остановлена при первой же возможности.
> Кроме того, если установлен атрибут fail-early,
> то install check заканчивается после первой неудачи.
>
Ещё было бы отлично проверку наследования делать как можно раньше.

Re: [devel] I: gyle: --test-early, --fail-only by default

[Michael Shigorin]

	Привет!
Задокументировал как-то на
https://www.altlinux.org/Git.alt/Справочник#task
-- заинтересованные приглашаются перепроверить
https://www.altlinux.org/index.php?title=Git.alt%2FСправочник&type=revision&diff=44262&oldid=43977


On Sun, Mar 17, 2019 at 03:03:52PM +0300, Dmitry V. Levin wrote:
> task new теперь устанавливает атрибут fail-early, другими словами,
> build теперь по умолчанию --fail-early.
> 
> Для возврата прежнего поведения появились
> build --fail-late и task run --fail-late.
> 
> task run без указания --fail-early/--fail-late теперь оставляет неизменным
> значение атрибута fail-early, установленное для этого задания ранее.


On Mon, Mar 18, 2019 at 05:03:20AM +0300, Dmitry V. Levin wrote:
> task new теперь устанавливает атрибут test-only, другими словами,
> сборка заданий теперь по умолчанию --test-only.
> 
> Для отправления заданий в репозиторий появились
> build --commit и task run --commit.
> 
> task run без указания ----test-only/--commit теперь оставляет неизменным
> значение атрибута test-only, установленное для этого задания ранее.
> 
> Значение атрибута test-only для заданий, созданных до этого изменения,
> осталось прежним.


On Mon, Mar 18, 2019 at 02:56:30PM +0300, Dmitry V. Levin wrote:
> Кроме того, если установлен атрибут fail-early,
> то install check заканчивается после первой неудачи.

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [devel] I: gyle --test-only by default

[Andrey Cherepanov]

18.03.2019 5:03, Dmitry V. Levin пишет:
> Hi,
>
> task new теперь устанавливает атрибут test-only, другими словами,
> сборка заданий теперь по умолчанию --test-only.
>
> Для отправления заданий в репозиторий появились
> build --commit и task run --commit.
>
> task run без указания ----test-only/--commit теперь оставляет неизменным
> значение атрибута test-only, установленное для этого задания ранее.
>
> Значение атрибута test-only для заданий, созданных до этого изменения,
> осталось прежним.
А чем это мотивировано? Какие ещё притянутые за уши параметры
планируется указывать, чтобы просто собрать задание?

-- 
Andrey Cherepanov
cas@altlinux.org

Re: [devel] I: gyle --test-only by default

[Paul Wolneykien]

19.03.2019 12:22, Andrey Cherepanov пишет:
> 18.03.2019 5:03, Dmitry V. Levin пишет:
>> Hi,
>>
>> task new теперь устанавливает атрибут test-only, другими словами,
>> сборка заданий теперь по умолчанию --test-only.
>>
>> Для отправления заданий в репозиторий появились
>> build --commit и task run --commit.
>>
>> task run без указания ----test-only/--commit теперь оставляет неизменным
>> значение атрибута test-only, установленное для этого задания ранее.
>>
>> Значение атрибута test-only для заданий, созданных до этого изменения,
>> осталось прежним.
> А чем это мотивировано? Какие ещё притянутые за уши параметры
> планируется указывать, чтобы просто собрать задание?
> 

ssh girar task run --commit --yes-do-as-i-say-motherf--er ?

Re: [devel] I: gyle --test-only by default

[Andrey Cherepanov]

19.03.2019 12:42, Paul Wolneykien пишет:
> 19.03.2019 12:22, Andrey Cherepanov пишет:
>> 18.03.2019 5:03, Dmitry V. Levin пишет:
>>> Hi,
>>>
>>> task new теперь устанавливает атрибут test-only, другими словами,
>>> сборка заданий теперь по умолчанию --test-only.
>>>
>>> Для отправления заданий в репозиторий появились
>>> build --commit и task run --commit.
>>>
>>> task run без указания ----test-only/--commit теперь оставляет неизменным
>>> значение атрибута test-only, установленное для этого задания ранее.
>>>
>>> Значение атрибута test-only для заданий, созданных до этого изменения,
>>> осталось прежним.
>> А чем это мотивировано? Какие ещё притянутые за уши параметры
>> планируется указывать, чтобы просто собрать задание?
>>
> ssh girar task run --commit --yes-do-as-i-say-motherf--er ?

ssh girar task run --commit --yes-i-am-from-obninsk-and-usually-forget-to-run-task-without-test-only

-- 
Andrey Cherepanov
cas@altlinux.org

Re: [devel] I: gyle --test-only by default

[Anton Farygin]

19.03.2019 12:51, Andrey Cherepanov пишет:
>>>> Значение атрибута test-only для заданий, созданных до этого изменения,
>>>> осталось прежним.
>>> А чем это мотивировано? Какие ещё притянутые за уши параметры
>>> планируется указывать, чтобы просто собрать задание?
>>>
>> ssh girar task run --commit --yes-do-as-i-say-motherf--er ?
> ssh girar task run --commit --yes-i-am-from-obninsk-and-usually-forget-to-run-task-without-test-only

При чём тут Обнинск ?

Re: [devel] I: gyle --test-only by default

[Grigory Ustinov]

19.03.2019 12:59, Anton Farygin пишет:
> 19.03.2019 12:51, Andrey Cherepanov пишет:
>>>>> Значение атрибута test-only для заданий, созданных до этого 
>>>>> изменения,
>>>>> осталось прежним.
>>>> А чем это мотивировано? Какие ещё притянутые за уши параметры
>>>> планируется указывать, чтобы просто собрать задание?
>>>>
>>> ssh girar task run --commit --yes-do-as-i-say-motherf--er ?
>> ssh girar task run --commit 
>> --yes-i-am-from-obninsk-and-usually-forget-to-run-task-without-test-only
>
> При чём тут Обнинск ?
Пока поблагодарили за это изменение только сотрудники из Обнинска. 
Полагаю, что остальное сообщество недоумевает, кому и зачем это нужно.

Re: [devel] I: gyle --test-only by default

[Michael Shigorin]

On Tue, Mar 19, 2019 at 01:03:24PM +0300, Grigory Ustinov wrote:
> >>>> А чем это мотивировано? Какие ещё притянутые за уши параметры
> >>>> планируется указывать, чтобы просто собрать задание?
> >>> ssh girar task run --commit --yes-do-as-i-say-motherf--er ?
> >> ssh girar task run --commit 
> >> --yes-i-am-from-obninsk-and-usually-forget-to-run-task-without-test-only
> > При чём тут Обнинск ?
> Пока поблагодарили за это изменение только сотрудники из Обнинска. 
> Полагаю, что остальное сообщество недоумевает, кому и зачем это нужно.

Да ладно, у меня такие косяки тоже бывали.
Правда, не уверен, что поможет...

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [devel] I: gyle --test-only by default

[Anton Farygin]

19.03.2019 13:03, Grigory Ustinov пишет:
> 19.03.2019 12:59, Anton Farygin пишет:
>> 19.03.2019 12:51, Andrey Cherepanov пишет:
>>>>>> Значение атрибута test-only для заданий, созданных до этого 
>>>>>> изменения,
>>>>>> осталось прежним.
>>>>> А чем это мотивировано? Какие ещё притянутые за уши параметры
>>>>> планируется указывать, чтобы просто собрать задание?
>>>>>
>>>> ssh girar task run --commit --yes-do-as-i-say-motherf--er ?
>>> ssh girar task run --commit 
>>> --yes-i-am-from-obninsk-and-usually-forget-to-run-task-without-test-only 
>>>
>>
>> При чём тут Обнинск ?
> Пока поблагодарили за это изменение только сотрудники из Обнинска. 
> Полагаю, что остальное сообщество недоумевает, кому и зачем это нужно. 

Я в момент благодарности находился в Боровске ;)

Не думаю что test-only по умолчанию как то связано с месторасположением 
людей, которым это поведение сборочницы импонирует, просьба в дальнейшем 
не применять разделение требований к функционалу по географическому, 
религиозному или национальному признаку.

Re: [devel] I: gyle --test-only by default

[Alexey V. Vissarionov]

On 2019-03-19 13:06:38 +0300, Michael Shigorin wrote:

 >>>>>> А чем это мотивировано? Какие ещё притянутые за уши
 >>>>>> параметры планируется указывать, чтобы просто собрать
 >>>>>> задание?
 >>>>> ssh girar task run --commit --yes-do-as-i-say-motherf--er ?
 >>>> ssh girar task run --commit
 >>>> --yes-i-am-from-obninsk-and-usually-forget-to-run-task-without-test-only
 >>> При чём тут Обнинск ?
 >> Пока поблагодарили за это изменение только сотрудники из
 >> Обнинска.
 >> Полагаю, что остальное сообщество недоумевает, кому и зачем
 >> это нужно.
 > Да ладно, у меня такие косяки тоже бывали. Правда, не уверен,
 > что поможет...

Не поможет. Потому что сделано через как обычно.

А если бы делали по уму, то --test-only было бы по умолчанию
включено только для build, но не для run


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

Re: [devel] I: gyle --test-only by default

[Grigory Ustinov]

19.03.2019 13:06, Michael Shigorin пишет:
> On Tue, Mar 19, 2019 at 01:03:24PM +0300, Grigory Ustinov wrote:
>>>>>> А чем это мотивировано? Какие ещё притянутые за уши параметры
>>>>>> планируется указывать, чтобы просто собрать задание?
>>>>> ssh girar task run --commit --yes-do-as-i-say-motherf--er ?
>>>> ssh girar task run --commit
>>>> --yes-i-am-from-obninsk-and-usually-forget-to-run-task-without-test-only
>>> При чём тут Обнинск ?
>> Пока поблагодарили за это изменение только сотрудники из Обнинска.
>> Полагаю, что остальное сообщество недоумевает, кому и зачем это нужно.
> Да ладно, у меня такие косяки тоже бывали.
> Правда, не уверен, что поможет...
Я просто хочу поделиться описанием того, как собираю пакеты я. Я нажимаю 
ctrl+r и пишу build и в найденной из истории последней команде меняю 
тэг. Если мне нужно собрать тестовый таск, то дописываю --test-only. 
Теперь же для сборки test-only таска надо наоборот удалять часть 
команды. Это жутко нелогично.

Re: [devel] I: gyle --test-only by default

[Andrey Cherepanov]

19.03.2019 13:15, Alexey V. Vissarionov пишет:
> On 2019-03-19 13:06:38 +0300, Michael Shigorin wrote:
>
>  >>>>>> А чем это мотивировано? Какие ещё притянутые за уши
>  >>>>>> параметры планируется указывать, чтобы просто собрать
>  >>>>>> задание?
>  >>>>> ssh girar task run --commit --yes-do-as-i-say-motherf--er ?
>  >>>> ssh girar task run --commit
>  >>>> --yes-i-am-from-obninsk-and-usually-forget-to-run-task-without-test-only
>  >>> При чём тут Обнинск ?
>  >> Пока поблагодарили за это изменение только сотрудники из
>  >> Обнинска.
>  >> Полагаю, что остальное сообщество недоумевает, кому и зачем
>  >> это нужно.
>  > Да ладно, у меня такие косяки тоже бывали. Правда, не уверен,
>  > что поможет...
>
> Не поможет. Потому что сделано через как обычно.
>
> А если бы делали по уму, то --test-only было бы по умолчанию
> включено только для build, но не для run
Полагаю, что тот, кто действительно хочет test-only, его указывает явно.
Но без предупреждения и обсуждения решили сломать наработанные workflow.
И эти люди будут говорить про Ruby Policy, которые не удосужились принять?

-- 
Andrey Cherepanov
cas@altlinux.org

Re: [devel] I: gyle --test-only by default

[Anton Farygin]

19.03.2019 13:36, Andrey Cherepanov пишет:
> 19.03.2019 13:15, Alexey V. Vissarionov пишет:
>> On 2019-03-19 13:06:38 +0300, Michael Shigorin wrote:
>>
>>   >>>>>> А чем это мотивировано? Какие ещё притянутые за уши
>>   >>>>>> параметры планируется указывать, чтобы просто собрать
>>   >>>>>> задание?
>>   >>>>> ssh girar task run --commit --yes-do-as-i-say-motherf--er ?
>>   >>>> ssh girar task run --commit
>>   >>>> --yes-i-am-from-obninsk-and-usually-forget-to-run-task-without-test-only
>>   >>> При чём тут Обнинск ?
>>   >> Пока поблагодарили за это изменение только сотрудники из
>>   >> Обнинска.
>>   >> Полагаю, что остальное сообщество недоумевает, кому и зачем
>>   >> это нужно.
>>   > Да ладно, у меня такие косяки тоже бывали. Правда, не уверен,
>>   > что поможет...
>>
>> Не поможет. Потому что сделано через как обычно.
>>
>> А если бы делали по уму, то --test-only было бы по умолчанию
>> включено только для build, но не для run
> Полагаю, что тот, кто действительно хочет test-only, его указывает явно.
> Но без предупреждения и обсуждения решили сломать наработанные workflow.
> И эти люди будут говорить про Ruby Policy, которые не удосужились принять?
>
Вообще то обсуждение было инициировано мною 26.11.2017 года.
Поищи в архивах по теме "test-only по умолчанию".

Re: [devel] I: gyle --test-only by default

[Andrey Savchenko]

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

On Tue, 19 Mar 2019 13:03:24 +0300 Grigory Ustinov wrote:
> 19.03.2019 12:59, Anton Farygin пишет:
> > 19.03.2019 12:51, Andrey Cherepanov пишет:
> >>>>> Значение атрибута test-only для заданий, созданных до этого 
> >>>>> изменения,
> >>>>> осталось прежним.
> >>>> А чем это мотивировано? Какие ещё притянутые за уши параметры
> >>>> планируется указывать, чтобы просто собрать задание?
> >>>>
> >>> ssh girar task run --commit --yes-do-as-i-say-motherf--er ?
> >> ssh girar task run --commit 
> >> --yes-i-am-from-obninsk-and-usually-forget-to-run-task-without-test-only
> >
> > При чём тут Обнинск ?
> Пока поблагодарили за это изменение только сотрудники из Обнинска. 
> Полагаю, что остальное сообщество недоумевает, кому и зачем это нужно.

Лично я пакеты перед отправкой на сборочницу тестирую локально,
поэтому --test-only нужен очень редко. Теперь одним бесполезным
аргументом по-умолчанию стало больше.

Итак "однострочник" с hsh разросся до нескольких сотен символов
и пришлось скрипты писать, теперь придётся и для build.alt делать.
Хорошо, что этого безобразия нет на e2k сборочнице :)

Best regards,
Andrew Savchenko

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

Re: [devel] I: gyle --test-only by default

[Anton Farygin]

19.03.2019 13:59, Andrey Savchenko пишет:
> On Tue, 19 Mar 2019 13:03:24 +0300 Grigory Ustinov wrote:
>> 19.03.2019 12:59, Anton Farygin пишет:
>>> 19.03.2019 12:51, Andrey Cherepanov пишет:
>>>>>>> Значение атрибута test-only для заданий, созданных до этого
>>>>>>> изменения,
>>>>>>> осталось прежним.
>>>>>> А чем это мотивировано? Какие ещё притянутые за уши параметры
>>>>>> планируется указывать, чтобы просто собрать задание?
>>>>>>
>>>>> ssh girar task run --commit --yes-do-as-i-say-motherf--er ?
>>>> ssh girar task run --commit
>>>> --yes-i-am-from-obninsk-and-usually-forget-to-run-task-without-test-only
>>> При чём тут Обнинск ?
>> Пока поблагодарили за это изменение только сотрудники из Обнинска.
>> Полагаю, что остальное сообщество недоумевает, кому и зачем это нужно.
> Лично я пакеты перед отправкой на сборочницу тестирую локально,
> поэтому --test-only нужен очень редко. Теперь одним бесполезным
> аргументом по-умолчанию стало больше.

Ты проверяешь локально на трёх архитектурах ?

Re: [devel] I: gyle --test-only by default

[Andrey Savchenko]

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

On Tue, 19 Mar 2019 14:03:34 +0300 Anton Farygin wrote:
> 19.03.2019 13:59, Andrey Savchenko пишет:
> > On Tue, 19 Mar 2019 13:03:24 +0300 Grigory Ustinov wrote:
> >> 19.03.2019 12:59, Anton Farygin пишет:
> >>> 19.03.2019 12:51, Andrey Cherepanov пишет:
> >>>>>>> Значение атрибута test-only для заданий, созданных до этого
> >>>>>>> изменения,
> >>>>>>> осталось прежним.
> >>>>>> А чем это мотивировано? Какие ещё притянутые за уши параметры
> >>>>>> планируется указывать, чтобы просто собрать задание?
> >>>>>>
> >>>>> ssh girar task run --commit --yes-do-as-i-say-motherf--er ?
> >>>> ssh girar task run --commit
> >>>> --yes-i-am-from-obninsk-and-usually-forget-to-run-task-without-test-only
> >>> При чём тут Обнинск ?
> >> Пока поблагодарили за это изменение только сотрудники из Обнинска.
> >> Полагаю, что остальное сообщество недоумевает, кому и зачем это нужно.
> > Лично я пакеты перед отправкой на сборочницу тестирую локально,
> > поэтому --test-only нужен очень редко. Теперь одним бесполезным
> > аргументом по-умолчанию стало больше.
> 
> Ты проверяешь локально на трёх архитектурах ?

Обычно, если собралось и работает на одной, то соберётся и на
остальных. --test-only нужен только при опасных изменениях,
способных разнести в хлам репозиторий, например, при обновлении
toolchain.

Best regards,
Andrew Savchenko

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

Re: [devel] I: gyle --test-only by default

[Anton Farygin]

19.03.2019 14:05, Andrey Savchenko пишет:
> On Tue, 19 Mar 2019 14:03:34 +0300 Anton Farygin wrote:
>> 19.03.2019 13:59, Andrey Savchenko пишет:
>>> On Tue, 19 Mar 2019 13:03:24 +0300 Grigory Ustinov wrote:
>>>> 19.03.2019 12:59, Anton Farygin пишет:
>>>>> 19.03.2019 12:51, Andrey Cherepanov пишет:
>>>>>>>>> Значение атрибута test-only для заданий, созданных до этого
>>>>>>>>> изменения,
>>>>>>>>> осталось прежним.
>>>>>>>> А чем это мотивировано? Какие ещё притянутые за уши параметры
>>>>>>>> планируется указывать, чтобы просто собрать задание?
>>>>>>>>
>>>>>>> ssh girar task run --commit --yes-do-as-i-say-motherf--er ?
>>>>>> ssh girar task run --commit
>>>>>> --yes-i-am-from-obninsk-and-usually-forget-to-run-task-without-test-only
>>>>> При чём тут Обнинск ?
>>>> Пока поблагодарили за это изменение только сотрудники из Обнинска.
>>>> Полагаю, что остальное сообщество недоумевает, кому и зачем это нужно.
>>> Лично я пакеты перед отправкой на сборочницу тестирую локально,
>>> поэтому --test-only нужен очень редко. Теперь одним бесполезным
>>> аргументом по-умолчанию стало больше.
>> Ты проверяешь локально на трёх архитектурах ?
> Обычно, если собралось и работает на одной, то соберётся и на
> остальных. --test-only нужен только при опасных изменениях,
> способных разнести в хлам репозиторий, например, при обновлении
> toolchain.

Ну нет, конечно если собралось на одной, то не факт что соберётся на 
остальных.
А так с test-only удобнее тем, что задачи test-only не блокируемые 
другими тасками. Т.е. - ты узнаешь о том, что твоё задание не собралось 
(или собралось не так) гораздо раньше, чем без него - тебе не надо за 
этим стоять в очереди на сборку.

Ну и нормальный workflow - задание собралось на сборочнице - поставь его 
локально, проверь и если работает - коммить.
а не ХХ в П, как принято у cas@.

Re: [devel] I: gyle --test-only by default

[Andrey Cherepanov]

19.03.2019 14:11, Anton Farygin пишет:
> 19.03.2019 14:05, Andrey Savchenko пишет:
>> On Tue, 19 Mar 2019 14:03:34 +0300 Anton Farygin wrote:
>>> 19.03.2019 13:59, Andrey Savchenko пишет:
>>>> On Tue, 19 Mar 2019 13:03:24 +0300 Grigory Ustinov wrote:
>>>>> 19.03.2019 12:59, Anton Farygin пишет:
>>>>>> 19.03.2019 12:51, Andrey Cherepanov пишет:
>>>>>>>>>> Значение атрибута test-only для заданий, созданных до этого
>>>>>>>>>> изменения,
>>>>>>>>>> осталось прежним.
>>>>>>>>> А чем это мотивировано? Какие ещё притянутые за уши параметры
>>>>>>>>> планируется указывать, чтобы просто собрать задание?
>>>>>>>>>
>>>>>>>> ssh girar task run --commit --yes-do-as-i-say-motherf--er ?
>>>>>>> ssh girar task run --commit
>>>>>>> --yes-i-am-from-obninsk-and-usually-forget-to-run-task-without-test-only
>>>>>>>
>>>>>> При чём тут Обнинск ?
>>>>> Пока поблагодарили за это изменение только сотрудники из Обнинска.
>>>>> Полагаю, что остальное сообщество недоумевает, кому и зачем это
>>>>> нужно.
>>>> Лично я пакеты перед отправкой на сборочницу тестирую локально,
>>>> поэтому --test-only нужен очень редко. Теперь одним бесполезным
>>>> аргументом по-умолчанию стало больше.
>>> Ты проверяешь локально на трёх архитектурах ?
>> Обычно, если собралось и работает на одной, то соберётся и на
>> остальных. --test-only нужен только при опасных изменениях,
>> способных разнести в хлам репозиторий, например, при обновлении
>> toolchain.
>
> Ну нет, конечно если собралось на одной, то не факт что соберётся на
> остальных.
> А так с test-only удобнее тем, что задачи test-only не блокируемые
> другими тасками. Т.е. - ты узнаешь о том, что твоё задание не
> собралось (или собралось не так) гораздо раньше, чем без него - тебе
> не надо за этим стоять в очереди на сборку.
>
> Ну и нормальный workflow - задание собралось на сборочнице - поставь
> его локально, проверь и если работает - коммить.
> а не ХХ в П, как принято у cas@.

С чего это можно назвать нормальным workflow? По мне так ненормален.
Сегодня произошли задержки в связи с навязыванием необоснованно глупого
workflow.

-- 
Andrey Cherepanov
cas@altlinux.org

Re: [devel] I: gyle --test-only by default

[Anton Farygin]

19.03.2019 14:15, Andrey Cherepanov пишет:
> 19.03.2019 14:11, Anton Farygin пишет:
>> 19.03.2019 14:05, Andrey Savchenko пишет:
>>> On Tue, 19 Mar 2019 14:03:34 +0300 Anton Farygin wrote:
>>>> 19.03.2019 13:59, Andrey Savchenko пишет:
>>>>> On Tue, 19 Mar 2019 13:03:24 +0300 Grigory Ustinov wrote:
>>>>>> 19.03.2019 12:59, Anton Farygin пишет:
>>>>>>> 19.03.2019 12:51, Andrey Cherepanov пишет:
>>>>>>>>>>> Значение атрибута test-only для заданий, созданных до этого
>>>>>>>>>>> изменения,
>>>>>>>>>>> осталось прежним.
>>>>>>>>>> А чем это мотивировано? Какие ещё притянутые за уши параметры
>>>>>>>>>> планируется указывать, чтобы просто собрать задание?
>>>>>>>>>>
>>>>>>>>> ssh girar task run --commit --yes-do-as-i-say-motherf--er ?
>>>>>>>> ssh girar task run --commit
>>>>>>>> --yes-i-am-from-obninsk-and-usually-forget-to-run-task-without-test-only
>>>>>>>>
>>>>>>> При чём тут Обнинск ?
>>>>>> Пока поблагодарили за это изменение только сотрудники из Обнинска.
>>>>>> Полагаю, что остальное сообщество недоумевает, кому и зачем это
>>>>>> нужно.
>>>>> Лично я пакеты перед отправкой на сборочницу тестирую локально,
>>>>> поэтому --test-only нужен очень редко. Теперь одним бесполезным
>>>>> аргументом по-умолчанию стало больше.
>>>> Ты проверяешь локально на трёх архитектурах ?
>>> Обычно, если собралось и работает на одной, то соберётся и на
>>> остальных. --test-only нужен только при опасных изменениях,
>>> способных разнести в хлам репозиторий, например, при обновлении
>>> toolchain.
>> Ну нет, конечно если собралось на одной, то не факт что соберётся на
>> остальных.
>> А так с test-only удобнее тем, что задачи test-only не блокируемые
>> другими тасками. Т.е. - ты узнаешь о том, что твоё задание не
>> собралось (или собралось не так) гораздо раньше, чем без него - тебе
>> не надо за этим стоять в очереди на сборку.
>>
>> Ну и нормальный workflow - задание собралось на сборочнице - поставь
>> его локально, проверь и если работает - коммить.
>> а не ХХ в П, как принято у cas@.
> С чего это можно назвать нормальным workflow? По мне так ненормален.
> Сегодня произошли задержки в связи с навязыванием необоснованно глупого
> workflow.

Нет никаких сомнений, что тебе нормальный workflow не понравится.

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

Re: [devel] I: gyle --test-only by default

[Andrey Cherepanov]

19.03.2019 14:20, Anton Farygin пишет:
> 19.03.2019 14:15, Andrey Cherepanov пишет:
>> 19.03.2019 14:11, Anton Farygin пишет:
>>> 19.03.2019 14:05, Andrey Savchenko пишет:
>>>> On Tue, 19 Mar 2019 14:03:34 +0300 Anton Farygin wrote:
>>>>> 19.03.2019 13:59, Andrey Savchenko пишет:
>>>>>> On Tue, 19 Mar 2019 13:03:24 +0300 Grigory Ustinov wrote:
>>>>>>> 19.03.2019 12:59, Anton Farygin пишет:
>>>>>>>> 19.03.2019 12:51, Andrey Cherepanov пишет:
>>>>>>>>>>>> Значение атрибута test-only для заданий, созданных до этого
>>>>>>>>>>>> изменения,
>>>>>>>>>>>> осталось прежним.
>>>>>>>>>>> А чем это мотивировано? Какие ещё притянутые за уши параметры
>>>>>>>>>>> планируется указывать, чтобы просто собрать задание?
>>>>>>>>>>>
>>>>>>>>>> ssh girar task run --commit --yes-do-as-i-say-motherf--er ?
>>>>>>>>> ssh girar task run --commit
>>>>>>>>> --yes-i-am-from-obninsk-and-usually-forget-to-run-task-without-test-only
>>>>>>>>>
>>>>>>>>>
>>>>>>>> При чём тут Обнинск ?
>>>>>>> Пока поблагодарили за это изменение только сотрудники из Обнинска.
>>>>>>> Полагаю, что остальное сообщество недоумевает, кому и зачем это
>>>>>>> нужно.
>>>>>> Лично я пакеты перед отправкой на сборочницу тестирую локально,
>>>>>> поэтому --test-only нужен очень редко. Теперь одним бесполезным
>>>>>> аргументом по-умолчанию стало больше.
>>>>> Ты проверяешь локально на трёх архитектурах ?
>>>> Обычно, если собралось и работает на одной, то соберётся и на
>>>> остальных. --test-only нужен только при опасных изменениях,
>>>> способных разнести в хлам репозиторий, например, при обновлении
>>>> toolchain.
>>> Ну нет, конечно если собралось на одной, то не факт что соберётся на
>>> остальных.
>>> А так с test-only удобнее тем, что задачи test-only не блокируемые
>>> другими тасками. Т.е. - ты узнаешь о том, что твоё задание не
>>> собралось (или собралось не так) гораздо раньше, чем без него - тебе
>>> не надо за этим стоять в очереди на сборку.
>>>
>>> Ну и нормальный workflow - задание собралось на сборочнице - поставь
>>> его локально, проверь и если работает - коммить.
>>> а не ХХ в П, как принято у cas@.
>> С чего это можно назвать нормальным workflow? По мне так ненормален.
>> Сегодня произошли задержки в связи с навязыванием необоснованно глупого
>> workflow.
>
> Нет никаких сомнений, что тебе нормальный workflow не понравится.
>
> Мне он тоже не очень нравится - надо улучших его тем, что на каждый
> собранный пакет должны запускаться автоматические тесты, которые перед
> этим квалифицированно напишет ментейнер. Но пока нам слабо это
> организовать с технической точки зрения.
>
Критерии нормальности приведите, пожалуйста. Пока я увидел в обсуждении
критерий забывчивости. Ещё что-либо есть?

-- 
Andrey Cherepanov
cas@altlinux.org

Re: [devel] I: gyle --test-only by default

[Anton V. Boyarshinov]

 
> Я просто хочу поделиться описанием того, как собираю пакеты я. Я нажимаю 
> ctrl+r и пишу build и в найденной из истории последней команде меняю 
> тэг.

А ещё можно не менять тэг, а сразу иметь в истории $(git describe) в
этом месте :-)

Re: [devel] I: gyle --test-only by default

[Anton Farygin]

19.03.2019 14:28, Andrey Cherepanov пишет:
> 19.03.2019 14:20, Anton Farygin пишет:
>> 19.03.2019 14:15, Andrey Cherepanov пишет:
>>> 19.03.2019 14:11, Anton Farygin пишет:
>>>> 19.03.2019 14:05, Andrey Savchenko пишет:
>>>>> On Tue, 19 Mar 2019 14:03:34 +0300 Anton Farygin wrote:
>>>>>> 19.03.2019 13:59, Andrey Savchenko пишет:
>>>>>>> On Tue, 19 Mar 2019 13:03:24 +0300 Grigory Ustinov wrote:
>>>>>>>> 19.03.2019 12:59, Anton Farygin пишет:
>>>>>>>>> 19.03.2019 12:51, Andrey Cherepanov пишет:
>>>>>>>>>>>>> Значение атрибута test-only для заданий, созданных до этого
>>>>>>>>>>>>> изменения,
>>>>>>>>>>>>> осталось прежним.
>>>>>>>>>>>> А чем это мотивировано? Какие ещё притянутые за уши параметры
>>>>>>>>>>>> планируется указывать, чтобы просто собрать задание?
>>>>>>>>>>>>
>>>>>>>>>>> ssh girar task run --commit --yes-do-as-i-say-motherf--er ?
>>>>>>>>>> ssh girar task run --commit
>>>>>>>>>> --yes-i-am-from-obninsk-and-usually-forget-to-run-task-without-test-only
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> При чём тут Обнинск ?
>>>>>>>> Пока поблагодарили за это изменение только сотрудники из Обнинска.
>>>>>>>> Полагаю, что остальное сообщество недоумевает, кому и зачем это
>>>>>>>> нужно.
>>>>>>> Лично я пакеты перед отправкой на сборочницу тестирую локально,
>>>>>>> поэтому --test-only нужен очень редко. Теперь одним бесполезным
>>>>>>> аргументом по-умолчанию стало больше.
>>>>>> Ты проверяешь локально на трёх архитектурах ?
>>>>> Обычно, если собралось и работает на одной, то соберётся и на
>>>>> остальных. --test-only нужен только при опасных изменениях,
>>>>> способных разнести в хлам репозиторий, например, при обновлении
>>>>> toolchain.
>>>> Ну нет, конечно если собралось на одной, то не факт что соберётся на
>>>> остальных.
>>>> А так с test-only удобнее тем, что задачи test-only не блокируемые
>>>> другими тасками. Т.е. - ты узнаешь о том, что твоё задание не
>>>> собралось (или собралось не так) гораздо раньше, чем без него - тебе
>>>> не надо за этим стоять в очереди на сборку.
>>>>
>>>> Ну и нормальный workflow - задание собралось на сборочнице - поставь
>>>> его локально, проверь и если работает - коммить.
>>>> а не ХХ в П, как принято у cas@.
>>> С чего это можно назвать нормальным workflow? По мне так ненормален.
>>> Сегодня произошли задержки в связи с навязыванием необоснованно глупого
>>> workflow.
>> Нет никаких сомнений, что тебе нормальный workflow не понравится.
>>
>> Мне он тоже не очень нравится - надо улучших его тем, что на каждый
>> собранный пакет должны запускаться автоматические тесты, которые перед
>> этим квалифицированно напишет ментейнер. Но пока нам слабо это
>> организовать с технической точки зрения.
>>
> Критерии нормальности приведите, пожалуйста. Пока я увидел в обсуждении
> критерий забывчивости. Ещё что-либо есть?
>
качество нашей работы - это критерий нормальности workflow.

Дима в последнее время много делает для его повышения, что не может не 
радовать.

Re: [devel] I: gyle --test-only by default

[Andrey Cherepanov]

19.03.2019 14:38, Anton Farygin пишет:
> 19.03.2019 14:28, Andrey Cherepanov пишет:
>> 19.03.2019 14:20, Anton Farygin пишет:
>>> 19.03.2019 14:15, Andrey Cherepanov пишет:
>>>> 19.03.2019 14:11, Anton Farygin пишет:
>>>>> 19.03.2019 14:05, Andrey Savchenko пишет:
>>>>>> On Tue, 19 Mar 2019 14:03:34 +0300 Anton Farygin wrote:
>>>>>>> 19.03.2019 13:59, Andrey Savchenko пишет:
>>>>>>>> On Tue, 19 Mar 2019 13:03:24 +0300 Grigory Ustinov wrote:
>>>>>>>>> 19.03.2019 12:59, Anton Farygin пишет:
>>>>>>>>>> 19.03.2019 12:51, Andrey Cherepanov пишет:
>>>>>>>>>>>>>> Значение атрибута test-only для заданий, созданных до этого
>>>>>>>>>>>>>> изменения,
>>>>>>>>>>>>>> осталось прежним.
>>>>>>>>>>>>> А чем это мотивировано? Какие ещё притянутые за уши параметры
>>>>>>>>>>>>> планируется указывать, чтобы просто собрать задание?
>>>>>>>>>>>>>
>>>>>>>>>>>> ssh girar task run --commit --yes-do-as-i-say-motherf--er ?
>>>>>>>>>>> ssh girar task run --commit
>>>>>>>>>>> --yes-i-am-from-obninsk-and-usually-forget-to-run-task-without-test-only
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> При чём тут Обнинск ?
>>>>>>>>> Пока поблагодарили за это изменение только сотрудники из
>>>>>>>>> Обнинска.
>>>>>>>>> Полагаю, что остальное сообщество недоумевает, кому и зачем это
>>>>>>>>> нужно.
>>>>>>>> Лично я пакеты перед отправкой на сборочницу тестирую локально,
>>>>>>>> поэтому --test-only нужен очень редко. Теперь одним бесполезным
>>>>>>>> аргументом по-умолчанию стало больше.
>>>>>>> Ты проверяешь локально на трёх архитектурах ?
>>>>>> Обычно, если собралось и работает на одной, то соберётся и на
>>>>>> остальных. --test-only нужен только при опасных изменениях,
>>>>>> способных разнести в хлам репозиторий, например, при обновлении
>>>>>> toolchain.
>>>>> Ну нет, конечно если собралось на одной, то не факт что соберётся на
>>>>> остальных.
>>>>> А так с test-only удобнее тем, что задачи test-only не блокируемые
>>>>> другими тасками. Т.е. - ты узнаешь о том, что твоё задание не
>>>>> собралось (или собралось не так) гораздо раньше, чем без него - тебе
>>>>> не надо за этим стоять в очереди на сборку.
>>>>>
>>>>> Ну и нормальный workflow - задание собралось на сборочнице - поставь
>>>>> его локально, проверь и если работает - коммить.
>>>>> а не ХХ в П, как принято у cas@.
>>>> С чего это можно назвать нормальным workflow? По мне так ненормален.
>>>> Сегодня произошли задержки в связи с навязыванием необоснованно
>>>> глупого
>>>> workflow.
>>> Нет никаких сомнений, что тебе нормальный workflow не понравится.
>>>
>>> Мне он тоже не очень нравится - надо улучших его тем, что на каждый
>>> собранный пакет должны запускаться автоматические тесты, которые перед
>>> этим квалифицированно напишет ментейнер. Но пока нам слабо это
>>> организовать с технической точки зрения.
>>>
>> Критерии нормальности приведите, пожалуйста. Пока я увидел в обсуждении
>> критерий забывчивости. Ещё что-либо есть?
>>
> качество нашей работы - это критерий нормальности workflow.
>
> Дима в последнее время много делает для его повышения, что не может не
> радовать.

А как измерили качество нашей работы? Мне напомнить про puppetserver и
вынос systemd при обновлении из p8?

-- 
Andrey Cherepanov
cas@altlinux.org

Re: [devel] I: gyle --test-only by default

[Anton Farygin]

19.03.2019 15:00, Andrey Cherepanov пишет:
>> качество нашей работы - это критерий нормальности workflow.
>>
>> Дима в последнее время много делает для его повышения, что не может не
>> радовать.
> А как измерили качество нашей работы? Мне напомнить про puppetserver и
> вынос systemd при обновлении из p8?

Про твои баги ты должен помнить сам ;)

Re: [devel] I: gyle --test-only by default

[Anton Farygin]

19.03.2019 15:01, Anton Farygin пишет:
> 19.03.2019 15:00, Andrey Cherepanov пишет:
>>> качество нашей работы - это критерий нормальности workflow.
>>>
>>> Дима в последнее время много делает для его повышения, что не может не
>>> радовать.
>> А как измерили качество нашей работы? Мне напомнить про puppetserver и
>> вынос systemd при обновлении из p8?
>
> Про твои баги ты должен помнить сам ;)

Кстати, эти как раз исправлены, за что спасибо их ментейнерам.

В отличии от вот этих:
https://packages.altlinux.org/ru/sisyphus/maintainers/cas/bugs

Re: [devel] I: gyle --test-only by default

[Grigory Ustinov]

19.03.2019 14:37, Anton V. Boyarshinov пишет:
>> Я просто хочу поделиться описанием того, как собираю пакеты я. Я нажимаю
>> ctrl+r и пишу build и в найденной из истории последней команде меняю
>> тэг.
> А ещё можно не менять тэг, а сразу иметь в истории $(git describe) в
> этом месте :-)
Спасибо! Буду приучаться=)

Re: [devel] I: gyle --test-only by default

[Ivan Zakharyaschev]

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

On Tue, 19 Mar 2019, Grigory Ustinov wrote:

> > > Полагаю, что остальное сообщество недоумевает, кому и зачем это нужно.
> > Да ладно, у меня такие косяки тоже бывали.
> > Правда, не уверен, что поможет...
> Я просто хочу поделиться описанием того, как собираю пакеты я. Я нажимаю
> ctrl+r и пишу build и в найденной из истории последней команде меняю тэг. Если
> мне нужно собрать тестовый таск, то дописываю --test-only. Теперь же для
> сборки test-only таска надо наоборот удалять часть команды. Это жутко

Удалять необязательно. Можно оставить как раньше --test-only при каждом 
запуске. (Я поначалу так и делал, пока не привык к новому.)

> нелогично.

Делать это от тебя не требуется.

-- 
Best regards,
Ivan

Re: [devel] I: gyle --test-only by default

[Alexey V. Vissarionov]

On 2019-03-19 13:36:29 +0300, Andrey Cherepanov wrote:

 >>>> Полагаю, что остальное сообщество недоумевает, кому и зачем
 >>>> это нужно.
 >>> Да ладно, у меня такие косяки тоже бывали. Правда, не уверен,
 >>> что поможет...
 >> Не поможет. Потому что сделано через как обычно.
 >> А если бы делали по уму, то --test-only было бы по умолчанию
 >> включено только для build, но не для run
 > Полагаю, что тот, кто действительно хочет test-only, его
 > указывает явно. Но без предупреждения и обсуждения решили
 > сломать наработанные workflow.

Сломать - полбеды: если бы вместо сломанного старого сделали новое
хорошо (а не через как обычно), это можно было понять.

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

Например, в данном случае достаточно было полностью разделить два
действия - build $repo $tag и commit $task - так, чтобы результатом
первого являлся набор бинарных пакетов (ну, или внятная диагностика
того, почему они не были собраны), а результатом второго появление
этих пакетов в репозитарии. Все. Неужели это так сложно?


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

Re: [devel] I: gyle --test-only by default

[Igor Vlasenko]

On Tue, Mar 19, 2019 at 10:14:37PM +0300, Alexey V. Vissarionov wrote:
> Например, в данном случае достаточно было полностью разделить два
> действия - build $repo $tag и commit $task - так, чтобы результатом
> первого являлся набор бинарных пакетов (ну, или внятная диагностика
> того, почему они не были собраны), а результатом второго появление
> этих пакетов в репозитарии. Все. Неужели это так сложно?

Более того, за счет разделения build и commit
можно было бы существенно ускорить сборочницу.
Ведь build можно делать параллельно, 
а commit приходится делать последовательно.

Но если build и commit отдельно,
и очереди на build и commit отдельно.
то commit можно делать крупными кусками.
залил таски 300001 ... 300010 в очередь на build,
собрались таски.

И забросил в очередь на commit 
не 10 команд COMMIT 300001, ... COMMIT 300010
а команду COMMIT 300001, ..., 300010 -
выполнится в 10 раз быстрее.

А в идеале умная сборчница сама будет это делать.

-- 

I V

Re: [devel] I: gyle --test-only by default

[Anton Farygin]

20.03.2019 0:05, Igor Vlasenko пишет:
> On Tue, Mar 19, 2019 at 10:14:37PM +0300, Alexey V. Vissarionov wrote:
>> Например, в данном случае достаточно было полностью разделить два
>> действия - build $repo $tag и commit $task - так, чтобы результатом
>> первого являлся набор бинарных пакетов (ну, или внятная диагностика
>> того, почему они не были собраны), а результатом второго появление
>> этих пакетов в репозитарии. Все. Неужели это так сложно?
> Более того, за счет разделения build и commit
> можно было бы существенно ускорить сборочницу.
> Ведь build можно делать параллельно,
> а commit приходится делать последовательно.
>
> Но если build и commit отдельно,
> и очереди на build и commit отдельно.
> то commit можно делать крупными кусками.
> залил таски 300001 ... 300010 в очередь на build,
> собрались таски.
>
> И забросил в очередь на commit
> не 10 команд COMMIT 300001, ... COMMIT 300010
> а команду COMMIT 300001, ..., 300010 -
> выполнится в 10 раз быстрее.
>
> А в идеале умная сборчница сама будет это делать.
>
Вы забываете, что некоторые build требуют rebuild других тасков при commit.

Re: [devel] I: gyle --test-only by default

[Alexey V. Vissarionov]

On 2019-03-20 00:25:51 +0300, Anton Farygin wrote:

 >>> Например, в данном случае достаточно было полностью разделить
 >>> два действия - build [...] и commit
 >> Более того, за счет разделения build и commit можно было бы
 >> существенно ускорить сборочницу. Ведь build можно делать
 >> параллельно, а commit приходится делать последовательно.
 >> Но если build и commit отдельно, и очереди на build и commit
 >> отдельно. то commit можно делать крупными кусками. [...]
 >> И забросил в очередь на commit не 10 команд COMMIT 300001,
 >> ... COMMIT 300010 а команду COMMIT 300001, ..., 300010 -
 >> выполнится в 10 раз быстрее.

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

 >> А в идеале умная сборчница сама будет это делать.
 > Вы забываете, что некоторые build требуют rebuild других
		     ^^^^^^^^^
 > тасков при commit.

- Господин поручик, но ведь за такое можно и по морде получить!
- Можно-с... Но обычно все же позволяют-с.

Фсмысле, если commit потребует пересборки, то и хрен бы с ним -
пересоберем.


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

Re: [devel] I: gyle --test-only by default

[Dmitry V. Levin]

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

On Tue, Mar 19, 2019 at 10:14:37PM +0300, Alexey V. Vissarionov wrote:
[...]
> Например, в данном случае достаточно было полностью разделить два
> действия - build $repo $tag и commit $task - так, чтобы результатом
> первого являлся набор бинарных пакетов (ну, или внятная диагностика
> того, почему они не были собраны), а результатом второго появление
> этих пакетов в репозитарии. Все. Неужели это так сложно?

В реализации они так и разделены, но в пользовательском интерфейсе
такое разделение неудобно, а удобно другое:
собрать задание, но не коммитить vs собрать задание и закоммитить.

On Tue, Mar 19, 2019 at 11:05:44PM +0200, Igor Vlasenko wrote:
[...]
> Более того, за счет разделения build и commit

В реализации они так и разделены.

> можно было бы существенно ускорить сборочницу.
> Ведь build можно делать параллельно, 
> а commit приходится делать последовательно.

С ускорением есть некоторые сложности, потому что проверки в build
довольно дорогие (их можно удешевить, но это не реализовано) и не
распараллелены (их можно распараллелить, но это не реализовано).


-- 
ldv

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [devel] I: gyle --test-only by default

[Igor Vlasenko]

On Wed, Mar 20, 2019 at 12:25:51AM +0300, Anton Farygin wrote:
> 20.03.2019 0:05, Igor Vlasenko пишет:
> > On Tue, Mar 19, 2019 at 10:14:37PM +0300, Alexey V. Vissarionov wrote:
> > > Например, в данном случае достаточно было полностью разделить два
> > > действия - build $repo $tag и commit $task - так, чтобы результатом
> > > первого являлся набор бинарных пакетов (ну, или внятная диагностика
> > > того, почему они не были собраны), а результатом второго появление
> > > этих пакетов в репозитарии. Все. Неужели это так сложно?
> > Более того, за счет разделения build и commit
> > можно было бы существенно ускорить сборочницу.
> > Ведь build можно делать параллельно,
> > а commit приходится делать последовательно.
> > 
> > Но если build и commit отдельно,
> > и очереди на build и commit отдельно.
> > то commit можно делать крупными кусками.
> > залил таски 300001 ... 300010 в очередь на build,
> > собрались таски.
> > 
> > И забросил в очередь на commit
> > не 10 команд COMMIT 300001, ... COMMIT 300010
> > а команду COMMIT 300001, ..., 300010 -
> > выполнится в 10 раз быстрее.
> > 
> > А в идеале умная сборчница сама будет это делать.
> > 
> Вы забываете, что некоторые build требуют rebuild других тасков при commit.

Так некорректно говорить,
"некоторые build требуют rebuild других тасков"
имеет смысл только в контексте конкретной реализации.

Если в сборочнице будут две очереди, на build и на commit,
то реализация будет другой и
такой случай будет называться по другому:
"собранный task такой-то устарел".
Он в таком случае опять переедет в очередь на сборку,
соберется, и опять вернется в очередь на коммит.

Проверку на устаревание и последующий уход
на повторную пересборку можно запускать 
параллельно и независимо от commit.

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

-- 

I V

Re: [devel] I: gyle --test-only by default

[Anton Farygin]

20.03.2019 0:43, Igor Vlasenko пишет:
> On Wed, Mar 20, 2019 at 12:25:51AM +0300, Anton Farygin wrote:
>> 20.03.2019 0:05, Igor Vlasenko пишет:
>>> On Tue, Mar 19, 2019 at 10:14:37PM +0300, Alexey V. Vissarionov wrote:
>>>> Например, в данном случае достаточно было полностью разделить два
>>>> действия - build $repo $tag и commit $task - так, чтобы результатом
>>>> первого являлся набор бинарных пакетов (ну, или внятная диагностика
>>>> того, почему они не были собраны), а результатом второго появление
>>>> этих пакетов в репозитарии. Все. Неужели это так сложно?
>>> Более того, за счет разделения build и commit
>>> можно было бы существенно ускорить сборочницу.
>>> Ведь build можно делать параллельно,
>>> а commit приходится делать последовательно.
>>>
>>> Но если build и commit отдельно,
>>> и очереди на build и commit отдельно.
>>> то commit можно делать крупными кусками.
>>> залил таски 300001 ... 300010 в очередь на build,
>>> собрались таски.
>>>
>>> И забросил в очередь на commit
>>> не 10 команд COMMIT 300001, ... COMMIT 300010
>>> а команду COMMIT 300001, ..., 300010 -
>>> выполнится в 10 раз быстрее.
>>>
>>> А в идеале умная сборчница сама будет это делать.
>>>
>> Вы забываете, что некоторые build требуют rebuild других тасков при commit.
> Так некорректно говорить,
> "некоторые build требуют rebuild других тасков"
> имеет смысл только в контексте конкретной реализации.
>
> Если в сборочнице будут две очереди, на build и на commit,
> то реализация будет другой и
> такой случай будет называться по другому:
> "собранный task такой-то устарел".
> Он в таком случае опять переедет в очередь на сборку,
> соберется, и опять вернется в очередь на коммит.
>
Это практически то, что реализовано сейчас. Только дополнительной 
непрерывной пересборки не ведётся (что, в общем-то, правильно).

Re: [devel] I: gyle --test-only by default

[Sergey V Turchin]

On Wednesday, 20 March 2019 00:36:37 MSK Alexey V wrote:

[...]
> если commit потребует пересборки, то и хрен бы с ним -
> пересоберем.
Тогда зачем было делать build?

[...]

-- 
Regards, Sergey.

Re: [devel] I: gyle --test-only by default

[Sergey V Turchin]

On Wednesday, 20 March 2019 10:22:27 MSK Sergey V wrote:
> On Wednesday, 20 March 2019 00:36:37 MSK Alexey V wrote:
> 
> [...]
> 
> > если commit потребует пересборки, то и хрен бы с ним -
> > пересоберем.
> Тогда зачем было делать build?
И это тебе с helloworld "хрен с ним", а мне несколько дней потерянного 
времени.

-- 
Regards, Sergey.

Re: [devel] I: gyle --test-only by default

[Alexey V. Vissarionov]

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

On 2019-03-20 00:42:25 +0300, Dmitry V. Levin wrote:
 >> Например, в данном случае достаточно было полностью разделить
 >> два действия - build $repo $tag и commit $task - так, чтобы
 >> результатом первого являлся набор бинарных пакетов (ну, или
 >> внятная диагностика того, почему они не были собраны), а
 >> результатом второго появление этих пакетов в репозитарии.
 >> Все. Неужели это так сложно?
 > В реализации они так и разделены, но в пользовательском
 > интерфейсе такое разделение неудобно, а удобно другое: собрать
 > задание, но не коммитить vs собрать задание и закоммитить.

Неправильно. Удобно немного по-другому - когда есть возможность:
1. Собрать (build --test-only).
2. Отправить в репу собранное (сейчас для этого используется task
run, а лучше было бы сделать команду commit).
3. Собрать и попробовать отправить в репу (хорошо бы назвать это
действие build --commit).

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

Еще было бы очень полезно, чтобы команда build выдавала номер
задания точно так же, как task new - в stdout. А все остальное -
соответственно, в stderr.

В общем, оптимальный по эргономике вариант видится мне примерно так:

set task=`ssh build.alt build $repo $tag`
тестируем - лопухнулись, исправляем
set task=`ssh build.alt build $repo $tag`
опять тестируем - порядок
ssh build.alt commit $task

Или, в самых простых случаях:

ssh build.alt build --commit $repo $tag


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [devel] I: gyle --test-only by default

[Anton Farygin]

20.03.2019 12:18, Alexey V. Vissarionov пишет:
> On 2019-03-20 00:42:25 +0300, Dmitry V. Levin wrote:
>   >> Например, в данном случае достаточно было полностью разделить
>   >> два действия - build $repo $tag и commit $task - так, чтобы
>   >> результатом первого являлся набор бинарных пакетов (ну, или
>   >> внятная диагностика того, почему они не были собраны), а
>   >> результатом второго появление этих пакетов в репозитарии.
>   >> Все. Неужели это так сложно?
>   > В реализации они так и разделены, но в пользовательском
>   > интерфейсе такое разделение неудобно, а удобно другое: собрать
>   > задание, но не коммитить vs собрать задание и закоммитить.
>
> Неправильно. Удобно немного по-другому - когда есть возможность:
> 1. Собрать (build --test-only).
> 2. Отправить в репу собранное (сейчас для этого используется task
> run, а лучше было бы сделать команду commit).
> 3. Собрать и попробовать отправить в репу (хорошо бы назвать это
> действие build --commit).
>
> Меня в свое время учили проектированию интерфейсов (пусть даже на
> примере органов управления), ага:-)  Кстати, единственный реально
> существующий орган управления, выполняющий одновременно две функции -
> это ручка "шаг-газ" в вертолете (да и то на ней есть корректор газа,
> который делает эту связку не такой жесткой).
>
> Еще было бы очень полезно, чтобы команда build выдавала номер
> задания точно так же, как task new - в stdout. А все остальное -
> соответственно, в stderr.
>
> В общем, оптимальный по эргономике вариант видится мне примерно так:
>
> set task=`ssh build.alt build $repo $tag`
> тестируем - лопухнулись, исправляем
> set task=`ssh build.alt build $repo $tag`
> опять тестируем - порядок
> ssh build.alt commit $task
>
> Или, в самых простых случаях:
>
> ssh build.alt build --commit $repo $tag

мне нравится.

Re: [devel] I: gyle --test-only by default

[Anton Farygin]

20.03.2019 12:42, Anton Farygin пишет:
> 20.03.2019 12:18, Alexey V. Vissarionov пишет:
>> On 2019-03-20 00:42:25 +0300, Dmitry V. Levin wrote:
>>   >> Например, в данном случае достаточно было полностью разделить
>>   >> два действия - build $repo $tag и commit $task - так, чтобы
>>   >> результатом первого являлся набор бинарных пакетов (ну, или
>>   >> внятная диагностика того, почему они не были собраны), а
>>   >> результатом второго появление этих пакетов в репозитарии.
>>   >> Все. Неужели это так сложно?
>>   > В реализации они так и разделены, но в пользовательском
>>   > интерфейсе такое разделение неудобно, а удобно другое: собрать
>>   > задание, но не коммитить vs собрать задание и закоммитить.
>>
>> Неправильно. Удобно немного по-другому - когда есть возможность:
>> 1. Собрать (build --test-only).
>> 2. Отправить в репу собранное (сейчас для этого используется task
>> run, а лучше было бы сделать команду commit).
>> 3. Собрать и попробовать отправить в репу (хорошо бы назвать это
>> действие build --commit).
>>
>> Меня в свое время учили проектированию интерфейсов (пусть даже на
>> примере органов управления), ага:-)  Кстати, единственный реально
>> существующий орган управления, выполняющий одновременно две функции -
>> это ручка "шаг-газ" в вертолете (да и то на ней есть корректор газа,
>> который делает эту связку не такой жесткой).
>>
>> Еще было бы очень полезно, чтобы команда build выдавала номер
>> задания точно так же, как task new - в stdout. А все остальное -
>> соответственно, в stderr.
>>
>> В общем, оптимальный по эргономике вариант видится мне примерно так:
>>
>> set task=`ssh build.alt build $repo $tag`
>> тестируем - лопухнулись, исправляем
>> set task=`ssh build.alt build $repo $tag`
>> опять тестируем - порядок
>> ssh build.alt commit $task
>>
>> Или, в самых простых случаях:
>>
>> ssh build.alt build --commit $repo $tag
>
> мне нравится.
Т.е. - run заменить на build и добавить commit.

Re: [devel] I: gyle --test-only by default

[Sergey V Turchin]

On Wednesday, 20 March 2019 12:18:15 MSK Alexey V wrote:

[...]
> Или, в самых простых случаях:
> ssh build.alt build --commit $repo $tag
Сейчас так и есть. :-)

-- 
Regards, Sergey.

Re: [devel] I: gyle --test-only by default

[Igor Vlasenko]

On Wed, Mar 20, 2019 at 10:32:11AM +0300, Sergey V Turchin wrote:
> > > если commit потребует пересборки, то и хрен бы с ним -
> > > пересоберем.
> > Тогда зачем было делать build?
> И это тебе с helloworld "хрен с ним", а мне несколько дней потерянного 
> времени.

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

#225014 BUILDING #4.4 [locked] sisyphus/zerg qt5-base.git=5.12.2-alt1 ...
.4 в 4.4 - что это?

-- 

I V

Re: [devel] I: gyle --test-only by default

[Igor Vlasenko]

On Wed, Mar 20, 2019 at 07:22:46AM +0300, Anton Farygin wrote:
> > Если в сборочнице будут две очереди, на build и на commit,
> > то реализация будет другой и
> > такой случай будет называться по другому:
> > "собранный task такой-то устарел".
> > Он в таком случае опять переедет в очередь на сборку,
> > соберется, и опять вернется в очередь на коммит.
> > 
> Это практически то, что реализовано сейчас. Только дополнительной
> непрерывной пересборки не ведётся (что, в общем-то, правильно).

Прошу прощения, наверное неудачно выразился.
Наоборот, именно сейчас в текущей реализации
наша сборочница и занимается непрерывной пересборкой,
причем даже не параллельной, а последовательной.
см.
#225014 BUILDING #4.4 [locked] sisyphus/zerg qt5-base.git=5.12.2-alt1 ...
где .4 в 4.4 - и есть указанная пересборка.

Я отдельное письмо развернутое напишу.
На тему что сейчас персборка идет по изменению chroot,
а надо бы только при появлении unmets.

-- 

I V

Re: [devel] I: gyle --test-only by default

[Sergey V Turchin]

On Wednesday, 20 March 2019 13:07:37 MSK Igor Vlasenko wrote:
> On Wed, Mar 20, 2019 at 10:32:11AM +0300, Sergey V Turchin wrote:
> > > > если commit потребует пересборки, то и хрен бы с ним -
> > > > пересоберем.
> > > 
> > > Тогда зачем было делать build?
> > 
> > И это тебе с helloworld "хрен с ним", а мне несколько дней потерянного
> > времени.
> 
> Сергей,
> вы возмущаетесь не по адресу.
> "пересоберем еще раз и несколько дней потерянного
> времени" уже давно с нами в нашей сборочнице.
Нет. Это сейчас "и", а предлагают "и", а потом ещё раз "и".

> #225014 BUILDING #4.4 [locked] sisyphus/zerg qt5-base.git=5.12.2-alt1 ...
> .4 в 4.4 - что это?


-- 
Regards, Sergey.

Re: [devel] I: gyle --test-only by default

[Sergey V Turchin]

On Wednesday, 20 March 2019 13:09:20 MSK Igor Vlasenko wrote:
> On Wed, Mar 20, 2019 at 07:22:46AM +0300, Anton Farygin wrote:
> > > Если в сборочнице будут две очереди, на build и на commit,
> > > то реализация будет другой и
> > > такой случай будет называться по другому:
> > > "собранный task такой-то устарел".
> > > Он в таком случае опять переедет в очередь на сборку,
> > > соберется, и опять вернется в очередь на коммит.
> > 
> > Это практически то, что реализовано сейчас. Только дополнительной
> > непрерывной пересборки не ведётся (что, в общем-то, правильно).
> 
> Прошу прощения, наверное неудачно выразился.
> Наоборот, именно сейчас в текущей реализации
> наша сборочница и занимается непрерывной пересборкой,
> причем даже не параллельной, а последовательной.
Если сократится общее время сборки толстых заданий, я за любые изменения.

> см.
> #225014 BUILDING #4.4 [locked] sisyphus/zerg qt5-base.git=5.12.2-alt1 ...
> где .4 в 4.4 - и есть указанная пересборка.
> 
> Я отдельное письмо развернутое напишу.
> На тему что сейчас персборка идет по изменению chroot,
> а надо бы только при появлении unmets.


-- 
Regards, Sergey.

Re: [devel] I: gyle --test-only by default

[Sergey Afonin]

On Wednesday 20 March 2019, Igor Vlasenko wrote:

> #225014 BUILDING #4.4 [locked] sisyphus/zerg qt5-base.git=5.12.2-alt1 ...
> .4 в 4.4 - что это?
 
Это когда между предыдущей и следующей итерацией начинает собираться
другой пакет этого же мантейнера, либо который сам влияет на сборку
этого пакета, либо задерживает её на столько, что успевает проскочить
чей-то ещё влияющий. Я уже предлагал пакеты одного мантейнера собирать
линейно, без обгона одного другим в любых условиях, кроме как если
FAILED.

-- 
С уважением, Сергей Афонин.

Re: [devel] I: gyle --test-only by default

[Ivan Zakharyaschev]

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

Hello!

On Wed, 20 Mar 2019, Alexey V. Vissarionov wrote:

> В общем, оптимальный по эргономике вариант видится мне примерно так:
> 
> set task=`ssh build.alt build $repo $tag`
> тестируем - лопухнулись, исправляем
> set task=`ssh build.alt build $repo $tag`
> опять тестируем - порядок
> ssh build.alt commit $task

Сейчас это ssh build.alt task run --commit $task

Если состояние репозитория и задания позволяют, оно сразу же делает commit 
сейчас, без пересборки.

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

При такой спецификации не соединять commit с автоматическим build многими 
итерациями сделало бы работу практически невозможной.

> Или, в самых простых случаях:
> 
> ssh build.alt build --commit $repo $tag


-- 
Best regards,
Ivan

Re: [devel] I: gyle --test-only by default

[Igor Vlasenko]

On Wed, Mar 20, 2019 at 02:34:21PM +0400, Sergey Afonin wrote:
> On Wednesday 20 March 2019, Igor Vlasenko wrote:
> 
> > #225014 BUILDING #4.4 [locked] sisyphus/zerg qt5-base.git=5.12.2-alt1 ...
> > .4 в 4.4 - что это?

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

"влияет на сборку этого пакета" - ключевое слово.

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

А "влияние" ?
Сколько я видел ненужных и бесполезных AVAITING 1.12, AVAITING 1.18 ...

> Я уже предлагал пакеты одного мантейнера собирать
> линейно, без обгона одного другим в любых условиях, кроме как если
> FAILED.

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

-- 

I V

Re: [devel] I: gyle --test-only by default

[Igor Vlasenko]

On Wed, Mar 20, 2019 at 01:38:57PM +0300, Ivan Zakharyaschev wrote:
> Если состояние репозитория и задания позволяют, оно сразу же делает commit 
> сейчас, без пересборки.
> 
> Просто тут дело не только в интерфейсе, но и в алгоритме работы (и его 
> спецификации) сборочницы: задание может быть закоммичено, только если оно 
> было собрано исходя из текущего состояния репозитория, поэтому желание 
> сделать commit вызывает необходимость пересобирать его несколькими 
> итерациями (от 0 и выше), пока это условие не будет выполнено, т.е. не 
> удастся-таки догнать текущее состояние репозитория (которое тоже бежит 
> вперёд из-за других заданий).
> 
> При такой спецификации не соединять commit с автоматическим build многими 
> итерациями сделало бы работу практически невозможной.

Вот. Спасибо, очень хорошее замечание.

Действительно, неудачно составленная текущая спецификация
на сборочницу не позволяет в ней внутри оторвать commit от build
и превращает сборочницу в последовательную,
которая имеет узкое бутылочное горло в пропускной способности
и тем давит развитие Сизифа (сутки на kde, неделю на perl,
месяц на python, о резанном texlive даже вспоминать страшно).

Но это тема для отдельного письма.

-- 

I V

Re: [devel] I: gyle --test-only by default

[Alexey V. Vissarionov]

On 2019-03-20 13:38:57 +0300, Ivan Zakharyaschev wrote:

 >> ssh build.alt commit $task
 > Сейчас это ssh build.alt task run --commit $task

Идиотизм.

В том, чтобы сделать build по умолчанию test-only, какую-то
логику усмотреть еще можно. В том, чтобы указывать команде
"продолжить выполнение уже собранного задания", что с ним
делать дальше - никакого смысла нет.

К.О. спешит на помощь: уже собранное задание нужно проверить
и в зависимости от результатов проверки либо отправить в репу,
либо удалить нахрен.

 > Если состояние репозитория и задания позволяют, оно сразу
 > же делает commit сейчас, без пересборки.

Это понятно.

По сути, осталось сделать самую малость: добавить команду commit
как понятный алиас для дурацкого синтаксиса task run --commit

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

Это вполне нормально: если я говорю commit - мне следует быть готовым
к тому, что задание будет пересобрано.


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

Re: [devel] I: gyle --test-only by default

[Andrey Savchenko]

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

Привет!

On Wed, 20 Mar 2019 13:38:57 +0300 (MSK) Ivan Zakharyaschev wrote:
> On Wed, 20 Mar 2019, Alexey V. Vissarionov wrote:
> > В общем, оптимальный по эргономике вариант видится мне примерно так:
> > 
> > set task=`ssh build.alt build $repo $tag`
> > тестируем - лопухнулись, исправляем
> > set task=`ssh build.alt build $repo $tag`
> > опять тестируем - порядок
> > ssh build.alt commit $task
> 
> Сейчас это ssh build.alt task run --commit $task
> 
> Если состояние репозитория и задания позволяют, оно сразу же делает commit 
> сейчас, без пересборки.
> 
> Просто тут дело не только в интерфейсе, но и в алгоритме работы (и его 
> спецификации) сборочницы: задание может быть закоммичено, только если оно 
> было собрано исходя из текущего состояния репозитория,

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

По сути, это классическая задача поиска путей в графе и @viy уже
много раз писал на эту тему и то, как её алгоритмизировать.

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

Best regards,
Andrew Savchenko

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

Re: [devel] I: gyle --test-only by default

[Aleksey Novodvorsky]

ср, 20 мар. 2019 г. в 14:52, Andrey Savchenko <bircoph@altlinux.org>:
>
> Привет!
>
> On Wed, 20 Mar 2019 13:38:57 +0300 (MSK) Ivan Zakharyaschev wrote:
> > On Wed, 20 Mar 2019, Alexey V. Vissarionov wrote:
> > > В общем, оптимальный по эргономике вариант видится мне примерно так:
> > >
> > > set task=`ssh build.alt build $repo $tag`
> > > тестируем - лопухнулись, исправляем
> > > set task=`ssh build.alt build $repo $tag`
> > > опять тестируем - порядок
> > > ssh build.alt commit $task
> >
> > Сейчас это ssh build.alt task run --commit $task
> >
> > Если состояние репозитория и задания позволяют, оно сразу же делает commit
> > сейчас, без пересборки.
> >
> > Просто тут дело не только в интерфейсе, но и в алгоритме работы (и его
> > спецификации) сборочницы: задание может быть закоммичено, только если оно
> > было собрано исходя из текущего состояния репозитория,
>
> Но ведь это избыточное условие для обеспечения пересобираемости
> пакетов и транзакционности сборки. Если пакет A не входит
> в сборочное окружение пакета B (в т.ч. и по сборочным зависимостям
> пакетов и сборочного окружения B, которые могут быть в свою
> очередь рекурсивными), то пакет B можно пересобирать вне
> зависимости от изменений пакета A.
>
> По сути, это классическая задача поиска путей в графе и @viy уже
> много раз писал на эту тему и то, как её алгоритмизировать.
>
> К сожалению, наша сборочница очень плохо проработана в этом
> направлении

Вы в этом уверены?

Rgrds, Алексей

Re: [devel] I: gyle --test-only by default

[Sergey Afonin]

On Wednesday 20 March 2019, Igor Vlasenko wrote:

> А "влияние" ?
> Сколько я видел ненужных и бесполезных AVAITING 1.12, AVAITING 1.18 ...
 
Тут момент такой, что если задание не будет задержано другим заданием
_этого_же_ мантейнера, вероятность того, что кто-то успеет повлиять
очень сильно уменьшается. Я только об этом. В качестве примера, цепочка
из POSTPONED даже сейчас, если ничего больше не делать, соберётся заметно
быстрее.

-- 
С уважением, Сергей Афонин.

Re: [devel] I: gyle --test-only by default

[Dmitry V. Levin]

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

On Wed, Mar 20, 2019 at 12:09:20PM +0200, Igor Vlasenko wrote:
[...]
> а надо бы только при появлении unmets.

Почему?


-- 
ldv

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [devel] I: gyle --test-only by default

[Andrey Savchenko]

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

On Wed, 20 Mar 2019 15:03:32 +0300 Aleksey Novodvorsky wrote:
> ср, 20 мар. 2019 г. в 14:52, Andrey Savchenko <bircoph@altlinux.org>:
> >
> > Привет!
> >
> > On Wed, 20 Mar 2019 13:38:57 +0300 (MSK) Ivan Zakharyaschev wrote:
> > > On Wed, 20 Mar 2019, Alexey V. Vissarionov wrote:
> > > > В общем, оптимальный по эргономике вариант видится мне примерно так:
> > > >
> > > > set task=`ssh build.alt build $repo $tag`
> > > > тестируем - лопухнулись, исправляем
> > > > set task=`ssh build.alt build $repo $tag`
> > > > опять тестируем - порядок
> > > > ssh build.alt commit $task
> > >
> > > Сейчас это ssh build.alt task run --commit $task
> > >
> > > Если состояние репозитория и задания позволяют, оно сразу же делает commit
> > > сейчас, без пересборки.
> > >
> > > Просто тут дело не только в интерфейсе, но и в алгоритме работы (и его
> > > спецификации) сборочницы: задание может быть закоммичено, только если оно
> > > было собрано исходя из текущего состояния репозитория,
> >
> > Но ведь это избыточное условие для обеспечения пересобираемости
> > пакетов и транзакционности сборки. Если пакет A не входит
> > в сборочное окружение пакета B (в т.ч. и по сборочным зависимостям
> > пакетов и сборочного окружения B, которые могут быть в свою
> > очередь рекурсивными), то пакет B можно пересобирать вне
> > зависимости от изменений пакета A.
> >
> > По сути, это классическая задача поиска путей в графе и @viy уже
> > много раз писал на эту тему и то, как её алгоритмизировать.
> >
> > К сожалению, наша сборочница очень плохо проработана в этом
> > направлении
> 
> Вы в этом уверены?

Да, я в этом уверен. Эпопея с пересборкой зависимостей libstdc++ на
e2k показала полную неготовность нашей сборочницы к задачам
построения графа зависимостей переданных ей пакетов и операций над
этим графом.

В итоге проблема построения графа зависимостей libstdc++
и порядка пересборки решалась с помощью утилит viy, за что ему
огромное спасибо. И за счёт ручной работы mike по разрыву колец (за
что ему тоже большое спасибо), т.к. сейчас у нас rpm флаги не
привязаны к механизму поиска путей на графе.

Замечу, что в мире эти задачи уже много лет как решены.

Best regards,
Andrew Savchenko

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

Re: [devel] I: gyle --test-only by default

[Alexey V. Vissarionov]

On 2019-03-20 15:03:32 +0300, Aleksey Novodvorsky wrote:

 >> К сожалению, наша сборочница очень плохо проработана в этом
 >> направлении
 > Вы в этом уверены?

В кои-то восемь я могу выразиться менее категорично, чем bircoph@ -
"существуют более эффективные решения".

Я их видел :-)


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

Re: [devel] I: gyle --test-only by default

[Ivan Zakharyaschev]

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

On Wed, 20 Mar 2019, Andrey Savchenko wrote:

> On Wed, 20 Mar 2019 13:38:57 +0300 (MSK) Ivan Zakharyaschev wrote:
> > On Wed, 20 Mar 2019, Alexey V. Vissarionov wrote:
> > > В общем, оптимальный по эргономике вариант видится мне примерно так:
> > > 
> > > set task=`ssh build.alt build $repo $tag`
> > > тестируем - лопухнулись, исправляем
> > > set task=`ssh build.alt build $repo $tag`
> > > опять тестируем - порядок
> > > ssh build.alt commit $task
> > 
> > Сейчас это ssh build.alt task run --commit $task
> > 
> > Если состояние репозитория и задания позволяют, оно сразу же делает commit 
> > сейчас, без пересборки.
> > 
> > Просто тут дело не только в интерфейсе, но и в алгоритме работы (и его 
> > спецификации) сборочницы: задание может быть закоммичено, только если оно 
> > было собрано исходя из текущего состояния репозитория,
> 
> Но ведь это избыточное условие для обеспечения пересобираемости
> пакетов и транзакционности сборки. Если пакет A не входит
> в сборочное окружение пакета B (в т.ч. и по сборочным зависимостям
> пакетов и сборочного окружения B, которые могут быть в свою
> очередь рекурсивными), то пакет B можно пересобирать вне
> зависимости от изменений пакета A.

Это учтено насколько удалось при использовании apt.

Просто используется пакет или нет, определяет apt исходя из нового 
состояния репозитория.

Если изменение репозитория не привело к изменению сборочного окружения 
подзадания, то у нас этот путь и так сокращается: "no need to rebuild".

Время тратится только на ответ на этот вопрос.

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

-- 
Best regards,
Ivan

Re: [devel] I: gyle --test-only by default

[Dmitry V. Levin]

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

On Wed, Mar 20, 2019 at 02:51:39PM +0300, Andrey Savchenko wrote:
> On Wed, 20 Mar 2019 13:38:57 +0300 (MSK) Ivan Zakharyaschev wrote:
> > On Wed, 20 Mar 2019, Alexey V. Vissarionov wrote:
> > > В общем, оптимальный по эргономике вариант видится мне примерно так:
> > > 
> > > set task=`ssh build.alt build $repo $tag`
> > > тестируем - лопухнулись, исправляем
> > > set task=`ssh build.alt build $repo $tag`
> > > опять тестируем - порядок
> > > ssh build.alt commit $task
> > 
> > Сейчас это ssh build.alt task run --commit $task
> > 
> > Если состояние репозитория и задания позволяют, оно сразу же делает commit 
> > сейчас, без пересборки.
> > 
> > Просто тут дело не только в интерфейсе, но и в алгоритме работы (и его 
> > спецификации) сборочницы: задание может быть закоммичено, только если оно 
> > было собрано исходя из текущего состояния репозитория,
> 
> Но ведь это избыточное условие для обеспечения пересобираемости
> пакетов и транзакционности сборки. Если пакет A не входит
> в сборочное окружение пакета B (в т.ч. и по сборочным зависимостям
> пакетов и сборочного окружения B, которые могут быть в свою
> очередь рекурсивными), то пакет B можно пересобирать вне
> зависимости от изменений пакета A.

У нас очень дорогая проверка того, входит ли пакет A в сборочное окружение
пакета B.

> По сути, это классическая задача поиска путей в графе и @viy уже
> много раз писал на эту тему и то, как её алгоритмизировать.

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


-- 
ldv

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [devel] I: gyle --test-only by default

[Andrey Savchenko]

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

On Wed, 20 Mar 2019 15:39:55 +0300 Dmitry V. Levin wrote:
> On Wed, Mar 20, 2019 at 02:51:39PM +0300, Andrey Savchenko wrote:
> > On Wed, 20 Mar 2019 13:38:57 +0300 (MSK) Ivan Zakharyaschev wrote:
> > > On Wed, 20 Mar 2019, Alexey V. Vissarionov wrote:
> > > > В общем, оптимальный по эргономике вариант видится мне примерно так:
> > > > 
> > > > set task=`ssh build.alt build $repo $tag`
> > > > тестируем - лопухнулись, исправляем
> > > > set task=`ssh build.alt build $repo $tag`
> > > > опять тестируем - порядок
> > > > ssh build.alt commit $task
> > > 
> > > Сейчас это ssh build.alt task run --commit $task
> > > 
> > > Если состояние репозитория и задания позволяют, оно сразу же делает commit 
> > > сейчас, без пересборки.
> > > 
> > > Просто тут дело не только в интерфейсе, но и в алгоритме работы (и его 
> > > спецификации) сборочницы: задание может быть закоммичено, только если оно 
> > > было собрано исходя из текущего состояния репозитория,
> > 
> > Но ведь это избыточное условие для обеспечения пересобираемости
> > пакетов и транзакционности сборки. Если пакет A не входит
> > в сборочное окружение пакета B (в т.ч. и по сборочным зависимостям
> > пакетов и сборочного окружения B, которые могут быть в свою
> > очередь рекурсивными), то пакет B можно пересобирать вне
> > зависимости от изменений пакета A.
> 
> У нас очень дорогая проверка того, входит ли пакет A в сборочное окружение
> пакета B.

Возможно, следует подумать над тем, как её удешевить.
 
> > По сути, это классическая задача поиска путей в графе и @viy уже
> > много раз писал на эту тему и то, как её алгоритмизировать.
> 
> Для того, чтобы эту задачу решать быстро, насколько я понимаю,
> надо упростить зависимости и отказаться от apt в пользу инструментов,
> заточенных на решение этой задачи.

Смею заверить, что эта задача за разумное время решается на гораздо
более сложном графе зависимостей — где кроме зависимостей на пакеты,
есть зависимости на свойства сборки этих пакетов, которые в свою
очередь могут быть условными или опциональными, т.е. да, я про USE
флаги в Gentoo.

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

Best regards,
Andrew Savchenko

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

Re: [devel] I: gyle --test-only by default

[Dmitry V. Levin]

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

On Wed, Mar 20, 2019 at 03:33:01PM +0300, Andrey Savchenko wrote:
[...]
> Да, я в этом уверен. Эпопея с пересборкой зависимостей libstdc++ на
> e2k показала полную неготовность нашей сборочницы к задачам
> построения графа зависимостей переданных ей пакетов и операций над
> этим графом.

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

Я не вижу смысла вешать эту задачу на сборочницу-сервер, если
вы уже умеете эту задачу решать на клиентской стороне.


-- 
ldv

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [devel] I: gyle --test-only by default

[Dmitry V. Levin]

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

On Wed, Mar 20, 2019 at 03:47:13PM +0300, Andrey Savchenko wrote:
[...]
> Наша система зависимостей на порядок проще, поэтому при надлежащей
> реализации проблем с временем быть не должно.

У меня есть основания полагать, что это, к сожалению, не так.


-- 
ldv

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [devel] I: gyle --test-only by default

[Andrey Savchenko]

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

On Wed, 20 Mar 2019 15:51:00 +0300 Dmitry V. Levin wrote:
> On Wed, Mar 20, 2019 at 03:47:13PM +0300, Andrey Savchenko wrote:
> [...]
> > Наша система зависимостей на порядок проще, поэтому при надлежащей
> > реализации проблем с временем быть не должно.
> 
> У меня есть основания полагать, что это, к сожалению, не так.

Прошу озвучить эти основания. У нас есть только BuildRequires
и Requires. С точки зрения обсуждаемой задачи BuildPreReq можно
приравнять к BuildRequires.

Best regards,
Andrew Savchenko

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

Re: [devel] I: gyle --test-only by default

[Dmitry V. Levin]

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

On Wed, Mar 20, 2019 at 12:18:15PM +0300, Alexey V. Vissarionov wrote:
> On 2019-03-20 00:42:25 +0300, Dmitry V. Levin wrote:
>  >> Например, в данном случае достаточно было полностью разделить
>  >> два действия - build $repo $tag и commit $task - так, чтобы
>  >> результатом первого являлся набор бинарных пакетов (ну, или
>  >> внятная диагностика того, почему они не были собраны), а
>  >> результатом второго появление этих пакетов в репозитарии.
>  >> Все. Неужели это так сложно?
>  > В реализации они так и разделены, но в пользовательском
>  > интерфейсе такое разделение неудобно, а удобно другое: собрать
>  > задание, но не коммитить vs собрать задание и закоммитить.
> 
> Неправильно. Удобно немного по-другому - когда есть возможность:
> 1. Собрать (build --test-only).
> 2. Отправить в репу собранное (сейчас для этого используется task
> run, а лучше было бы сделать команду commit).
> 3. Собрать и попробовать отправить в репу (хорошо бы назвать это
> действие build --commit).
> 
> Меня в свое время учили проектированию интерфейсов (пусть даже на
> примере органов управления), ага :-) Кстати, единственный реально
> существующий орган управления, выполняющий одновременно две функции -
> это ручка "шаг-газ" в вертолете (да и то на ней есть корректор газа,
> который делает эту связку не такой жесткой).
> 
> Еще было бы очень полезно, чтобы команда build выдавала номер
> задания точно так же, как task new - в stdout. А все остальное -
> соответственно, в stderr.
> 
> В общем, оптимальный по эргономике вариант видится мне примерно так:
> 
> set task=`ssh build.alt build $repo $tag`
> тестируем - лопухнулись, исправляем
> set task=`ssh build.alt build $repo $tag`
> опять тестируем - порядок
> ssh build.alt commit $task
> 
> Или, в самых простых случаях:
> 
> ssh build.alt build --commit $repo $tag

Что касается UI, то у нас есть более высокоуровневая операция build
и пачка менее высокоуровневых операций task cmd, где cmd это new, add,
run, и т.д., причём build реализована поверх task.

С точки зрения UI несложно завести операцию commit, которая будет
реализована как task run --commit, если на это есть спрос.


-- 
ldv

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [devel] I: gyle --test-only by default

[Andrey Savchenko]

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

On Wed, 20 Mar 2019 15:48:07 +0300 Dmitry V. Levin wrote:
> On Wed, Mar 20, 2019 at 03:33:01PM +0300, Andrey Savchenko wrote:
> [...]
> > Да, я в этом уверен. Эпопея с пересборкой зависимостей libstdc++ на
> > e2k показала полную неготовность нашей сборочницы к задачам
> > построения графа зависимостей переданных ей пакетов и операций над
> > этим графом.
> 
> Ничего не знаю про вашу сборочницу на e2k, но наша сборочница не
> занимается упорядочиванием сборки ваших пакетов по их зависимостям,
> мантейнеры определяют порядок сборки пакетов самостоятельно.

И очень плохо, что она этим не занимается. На e2k всё аналогично.

> Я не вижу смысла вешать эту задачу на сборочницу-сервер, если
> вы уже умеете эту задачу решать на клиентской стороне.

На клиентской стороне у нас это не автоматизировано, к сожалению,
нужна ручная работа для того же разрыва колец.

И смысл я вижу (и не один я!), потому что есть задачи, где программа
может делать работу лучше, чем человек и нечего заставлять человека
каждый раз выполнять автоматизируемую задачу. Он может потратить
своё время (в т.ч. оплачиваемое) более продуктивно.

Да, я хочу, чтоб сборочнице можно было:

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

2) Сказать: пересобери мне пакет X и всё, что от него зависит прямо
или косвенно.

Best regards,
Andrew Savchenko

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

Re: [devel] I: gyle --test-only by default

[Igor Vlasenko]

On Wed, Mar 20, 2019 at 03:28:16PM +0300, Dmitry V. Levin wrote:
> On Wed, Mar 20, 2019 at 12:09:20PM +0200, Igor Vlasenko wrote:
> [...]
> > а надо бы только при появлении unmets.
> 
> Почему?

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

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

Предлагаю обсудить после того, как выложу
текст в рассылку.

-- 

I V

Re: [devel] I: gyle --test-only by default

[Dmitry V. Levin]

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

On Wed, Mar 20, 2019 at 03:56:23PM +0300, Andrey Savchenko wrote:
> On Wed, 20 Mar 2019 15:51:00 +0300 Dmitry V. Levin wrote:
> > On Wed, Mar 20, 2019 at 03:47:13PM +0300, Andrey Savchenko wrote:
> > [...]
> > > Наша система зависимостей на порядок проще, поэтому при надлежащей
> > > реализации проблем с временем быть не должно.
> > 
> > У меня есть основания полагать, что это, к сожалению, не так.
> 
> Прошу озвучить эти основания. У нас есть только BuildRequires
> и Requires. С точки зрения обсуждаемой задачи BuildPreReq можно
> приравнять к BuildRequires.

У нас есть Provides, Requires, Conflicts, BuildRequires.

(ещё существует BuildConflicts, но для вычисления сборочной среды
BuildConflicts не участвует и про него можно забыть).

Все эти 4 вида зависимостей бывают версионированными с диапазоном версий.
У виртуальных пакетов (тех сущностей, которые фигурируют в Provides)
бывают альтернативные провайдеры, и выбор провайдера из множества
не является произвольным.


-- 
ldv

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [devel] I: gyle --test-only by default

[Dmitry V. Levin]

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

On Wed, Mar 20, 2019 at 03:01:53PM +0200, Igor Vlasenko wrote:
> On Wed, Mar 20, 2019 at 03:28:16PM +0300, Dmitry V. Levin wrote:
> > On Wed, Mar 20, 2019 at 12:09:20PM +0200, Igor Vlasenko wrote:
> > [...]
> > > а надо бы только при появлении unmets.
> > 
> > Почему?
> 
> Как бы мне и так очевидно, что
> пересборка по критерию, входит ли пакет A в сборочное окружение
> пакета B изначально была ошибочным допущением.

Я считаю иначе.

[...]
> Предлагаю обсудить после того, как выложу
> текст в рассылку.

OK


-- 
ldv

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [devel] I: gyle --test-only by default

[Dmitry V. Levin]

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

On Wed, Mar 20, 2019 at 04:01:33PM +0300, Andrey Savchenko wrote:
> On Wed, 20 Mar 2019 15:48:07 +0300 Dmitry V. Levin wrote:
> > On Wed, Mar 20, 2019 at 03:33:01PM +0300, Andrey Savchenko wrote:
> > [...]
> > > Да, я в этом уверен. Эпопея с пересборкой зависимостей libstdc++ на
> > > e2k показала полную неготовность нашей сборочницы к задачам
> > > построения графа зависимостей переданных ей пакетов и операций над
> > > этим графом.
> > 
> > Ничего не знаю про вашу сборочницу на e2k, но наша сборочница не
> > занимается упорядочиванием сборки ваших пакетов по их зависимостям,
> > мантейнеры определяют порядок сборки пакетов самостоятельно.
> 
> И очень плохо, что она этим не занимается. На e2k всё аналогично.
> 
> > Я не вижу смысла вешать эту задачу на сборочницу-сервер, если
> > вы уже умеете эту задачу решать на клиентской стороне.
> 
> На клиентской стороне у нас это не автоматизировано, к сожалению,
> нужна ручная работа для того же разрыва колец.
> 
> И смысл я вижу (и не один я!), потому что есть задачи, где программа
> может делать работу лучше, чем человек и нечего заставлять человека
> каждый раз выполнять автоматизируемую задачу. Он может потратить
> своё время (в т.ч. оплачиваемое) более продуктивно.
> 
> Да, я хочу, чтоб сборочнице можно было:
> 
> 1) Дать список пакетов и она сама выстроила нужную
> последовательность их сборки, распараллелив её там, где это
> возможно по сборочным зависимостям.
> 
> 2) Сказать: пересобери мне пакет X и всё, что от него зависит прямо
> или косвенно.

Я не против автоматизации, но почему эта автоматизация должна быть на
серверной стороне, а не на клиентской?  У вас ведь уже есть все данные
для решения этой задачи.


-- 
ldv

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [devel] I: gyle --test-only by default

[Andrey Savchenko]

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

On Wed, 20 Mar 2019 16:04:22 +0300 Dmitry V. Levin wrote:
> On Wed, Mar 20, 2019 at 03:56:23PM +0300, Andrey Savchenko wrote:
> > On Wed, 20 Mar 2019 15:51:00 +0300 Dmitry V. Levin wrote:
> > > On Wed, Mar 20, 2019 at 03:47:13PM +0300, Andrey Savchenko wrote:
> > > [...]
> > > > Наша система зависимостей на порядок проще, поэтому при надлежащей
> > > > реализации проблем с временем быть не должно.
> > > 
> > > У меня есть основания полагать, что это, к сожалению, не так.
> >  
> > Прошу озвучить эти основания. У нас есть только BuildRequires
> > и Requires. С точки зрения обсуждаемой задачи BuildPreReq можно
> > приравнять к BuildRequires.
> 
> У нас есть Provides, Requires, Conflicts, BuildRequires.
> 
> (ещё существует BuildConflicts, но для вычисления сборочной среды
> BuildConflicts не участвует и про него можно забыть).
> 
> Все эти 4 вида зависимостей бывают версионированными с диапазоном версий.
> У виртуальных пакетов (тех сущностей, которые фигурируют в Provides)
> бывают альтернативные провайдеры, и выбор провайдера из множества
> не является произвольным.

Все эти виды зависимостей есть и в portage, все они могут быть
версионированными, вирутальными, с диапазонами значений, вида A или
B или C. Но кроме этого есть зависимости по флагам, со своими
пересечениями, объединениями и условными зависимостями. И всё это
работает за разумное время.

Поэтому вполне возможна реализация решения подобной задачи за
разумное время и в Альте.

Best regards,
Andrew Savchenko

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

Re: [devel] I: gyle --test-only by default

[Alexey V. Vissarionov]

On 2019-03-20 15:39:55 +0300, Dmitry V. Levin wrote:

 > У нас очень дорогая проверка того, входит ли пакет A в сборочное
 > окружение пакета B.
 >> По сути, это классическая задача поиска путей в графе и @viy
 >> уже много раз писал на эту тему и то, как её алгоритмизировать.
 > Для того, чтобы эту задачу решать быстро, насколько я понимаю,
 > надо упростить зависимости

Ну наконец-то...
Жареный петух - птица мудрости.

 > и отказаться от apt в пользу инструментов, заточенных на решение
 > этой задачи.

1. Или.
2. Пока эти инструменты не определены, есть смысл начать именно с
упрощения зависимостей.


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

Re: [devel] I: gyle --test-only by default

[Igor Vlasenko]

On Wed, Mar 20, 2019 at 04:08:07PM +0400, Sergey Afonin wrote:
> On Wednesday 20 March 2019, Igor Vlasenko wrote:
> 
> > А "влияние" ?
> > Сколько я видел ненужных и бесполезных AVAITING 1.12, AVAITING 1.18 ...
>  
> Тут момент такой, что если задание не будет задержано другим заданием
> _этого_же_ мантейнера, вероятность того, что кто-то успеет повлиять
> очень сильно уменьшается. Я только об этом. В качестве примера, цепочка
> из POSTPONED даже сейчас, если ничего больше не делать, соберётся заметно
> быстрее.

Это вы альтернатив не распробовали.
Я вот разбалован хорошим, и для меня это "быстрее"
звучит как 700 лет пройдет быстрее, чем 1000.
Для сравнения, я сегодня обновлял autoimports/cpanbuilder.

обшее время выполнения составило
./bin/perl-maintain-parallel.sh 2>&1
51230,75s user 6461,19s system 1615% cpu 59:31,39 total
из них:
bin/parallel_update.sh --dest
752.66user 788.18system 3:25.23elapsed 750%CPU (0avgtext+0avgdata 475604maxresident)k
затем циклы пересборка -> logoved-report -> logoved-batchfix
(числа внизу - число пакетов на каждом шаге)
182
33
16
3
bin/parallel_missing.sh --origin-mtime-less 3500 --dest
1262,89s user 1638,38s system 932% cpu 5:11,15 total
1095
145
56
8
1
к сожалению, logoved запускался без time, можно оценить в 9 итераций -
меньше 1 мин на итерацию, плюс минута на rsync с autoimports
и на выкачку кеша distrodb. Чистое время на пересборку - около 45 мин.

Итого скорость пересборки составила
1500*60/45 = 2000 пакетов в час,
пол пакета в секунду.

пол пакета в секунду - это быстро.

-- 

I V

Re: [devel] I: gyle --test-only by default

[Andrey Savchenko]

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

On Wed, 20 Mar 2019 16:09:14 +0300 Dmitry V. Levin wrote:
> On Wed, Mar 20, 2019 at 04:01:33PM +0300, Andrey Savchenko wrote:
> > On Wed, 20 Mar 2019 15:48:07 +0300 Dmitry V. Levin wrote:
> > > On Wed, Mar 20, 2019 at 03:33:01PM +0300, Andrey Savchenko wrote:
> > > [...]
> > > > Да, я в этом уверен. Эпопея с пересборкой зависимостей libstdc++ на
> > > > e2k показала полную неготовность нашей сборочницы к задачам
> > > > построения графа зависимостей переданных ей пакетов и операций над
> > > > этим графом.
> > > 
> > > Ничего не знаю про вашу сборочницу на e2k, но наша сборочница не
> > > занимается упорядочиванием сборки ваших пакетов по их зависимостям,
> > > мантейнеры определяют порядок сборки пакетов самостоятельно.
> > 
> > И очень плохо, что она этим не занимается. На e2k всё аналогично.
> > 
> > > Я не вижу смысла вешать эту задачу на сборочницу-сервер, если
> > > вы уже умеете эту задачу решать на клиентской стороне.
> > 
> > На клиентской стороне у нас это не автоматизировано, к сожалению,
> > нужна ручная работа для того же разрыва колец.
> > 
> > И смысл я вижу (и не один я!), потому что есть задачи, где программа
> > может делать работу лучше, чем человек и нечего заставлять человека
> > каждый раз выполнять автоматизируемую задачу. Он может потратить
> > своё время (в т.ч. оплачиваемое) более продуктивно.
> > 
> > Да, я хочу, чтоб сборочнице можно было:
> > 
> > 1) Дать список пакетов и она сама выстроила нужную
> > последовательность их сборки, распараллелив её там, где это
> > возможно по сборочным зависимостям.
> > 
> > 2) Сказать: пересобери мне пакет X и всё, что от него зависит прямо
> > или косвенно.
> 
> Я не против автоматизации, но почему эта автоматизация должна быть на
> серверной стороне, а не на клиентской?  У вас ведь уже есть все данные
> для решения этой задачи.

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

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

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

Best regards,
Andrew Savchenko

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

Re: [devel] I: gyle --test-only by default

[Anton Farygin]

20.03.2019 16:09, Andrey Savchenko пишет:
> On Wed, 20 Mar 2019 16:04:22 +0300 Dmitry V. Levin wrote:
>> On Wed, Mar 20, 2019 at 03:56:23PM +0300, Andrey Savchenko wrote:
>>> On Wed, 20 Mar 2019 15:51:00 +0300 Dmitry V. Levin wrote:
>>>> On Wed, Mar 20, 2019 at 03:47:13PM +0300, Andrey Savchenko wrote:
>>>> [...]
>>>>> Наша система зависимостей на порядок проще, поэтому при надлежащей
>>>>> реализации проблем с временем быть не должно.
>>>> У меня есть основания полагать, что это, к сожалению, не так.
>>>   
>>> Прошу озвучить эти основания. У нас есть только BuildRequires
>>> и Requires. С точки зрения обсуждаемой задачи BuildPreReq можно
>>> приравнять к BuildRequires.
>> У нас есть Provides, Requires, Conflicts, BuildRequires.
>>
>> (ещё существует BuildConflicts, но для вычисления сборочной среды
>> BuildConflicts не участвует и про него можно забыть).
>>
>> Все эти 4 вида зависимостей бывают версионированными с диапазоном версий.
>> У виртуальных пакетов (тех сущностей, которые фигурируют в Provides)
>> бывают альтернативные провайдеры, и выбор провайдера из множества
>> не является произвольным.
> Все эти виды зависимостей есть и в portage, все они могут быть
> версионированными, вирутальными, с диапазонами значений, вида A или
> B или C. Но кроме этого есть зависимости по флагам, со своими
> пересечениями, объединениями и условными зависимостями. И всё это
> работает за разумное время.
>
> Поэтому вполне возможна реализация решения подобной задачи за
> разумное время и в Альте.

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

В debian есть ещё возможность подключать внешние солверы к apt'у 
(например - apt-cudf)
на знаю, работает ли эта фича у нас и насколько это было бы удобно для 
решения озвученных проблем.

[devel] предлагаю продолжить летом (was: I: gyle --test-only by default)

[Michael Shigorin]

On Wed, Mar 20, 2019 at 04:16:27PM +0300, Andrey Savchenko wrote:
> По сути, мы имеем целый ворох разнообразных проблем и задач,
> которые упираются в граф зависимостей между пакетами.

Андрей, Игорь, предлагаю усилия на подобную постановку задач
всё-таки тратить не _перед_ судом бранча, а где-нить летом уже.

Потому что сейчас сборочницу переворачивать вверх дном никто,
наверное, не будет -- а вот в относительно спокойное (надеюсь)
время для вдумчивого чтения, обсуждения, прототипирования момент
будет более удачный.

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [devel] предлагаю продолжить летом (was: I: gyle --test-only by default)

[Andrey Savchenko]

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

On Wed, 20 Mar 2019 16:24:01 +0300 Michael Shigorin wrote:
> On Wed, Mar 20, 2019 at 04:16:27PM +0300, Andrey Savchenko wrote:
> > По сути, мы имеем целый ворох разнообразных проблем и задач,
> > которые упираются в граф зависимостей между пакетами.
> 
> Андрей, Игорь, предлагаю усилия на подобную постановку задач
> всё-таки тратить не _перед_ судом бранча, а где-нить летом уже.
> 
> Потому что сейчас сборочницу переворачивать вверх дном никто,
> наверное, не будет -- а вот в относительно спокойное (надеюсь)
> время для вдумчивого чтения, обсуждения, прототипирования момент
> будет более удачный.

Я согласен. Но риторический вопрос: а стоило ли перед бранчеванием
вносить столь противоречивые изменения в сборочницу, как gyle
--test-only by default?


Best regards,
Andrew Savchenko

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

Re: [devel] предлагаю продолжить летом (was: I: gyle --test-only by default)

[Igor Vlasenko]

On Wed, Mar 20, 2019 at 04:24:01PM +0300, Michael Shigorin wrote:
> On Wed, Mar 20, 2019 at 04:16:27PM +0300, Andrey Savchenko wrote:
> > По сути, мы имеем целый ворох разнообразных проблем и задач,
> > которые упираются в граф зависимостей между пакетами.
> 
> Андрей, Игорь, предлагаю усилия на подобную постановку задач
> всё-таки тратить не _перед_ судом бранча, а где-нить летом уже.
> 
> Потому что сейчас сборочницу переворачивать вверх дном никто,
> наверное, не будет -- а вот в относительно спокойное (надеюсь)
> время для вдумчивого чтения, обсуждения, прототипирования момент
> будет более удачный.

Да, конечно.
Это, кстати, хорошая идея - написать к лету что-нибудь
для более конкретного обсуждения.

-- 

I V

Re: [devel] I: gyle --test-only by default

[Alexey V. Vissarionov]

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

On 2019-03-20 15:57:24 +0300, Dmitry V. Levin wrote:

 >> Неправильно. Удобно немного по-другому - когда есть
 >> возможность:
 >> 1. Собрать (build --test-only).
 >> 2. Отправить в репу собранное (сейчас для этого используется task
 >> run, а лучше было бы сделать команду commit).
 >> 3. Собрать и попробовать отправить в репу (хорошо бы назвать это
 >> действие build --commit).
 >> [...]
 >> В общем, оптимальный по эргономике вариант видится мне
 >> примерно так:
 >> set task=`ssh build.alt build $repo $tag`
 >> тестируем - лопухнулись, исправляем
 >> set task=`ssh build.alt build $repo $tag`
 >> опять тестируем - порядок
 >> ssh build.alt commit $task
 >> Или, в самых простых случаях:
 >> ssh build.alt build --commit $repo $tag
 > Что касается UI, то у нас есть более высокоуровневая операция
 > build и пачка менее высокоуровневых операций task cmd, где cmd
 > это new, add, run, и т.д., причём build реализована поверх task.

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

 > С точки зрения UI несложно завести операцию commit, которая будет
 > реализована как task run --commit, если на это есть спрос.

Дык и сделай - думаю, это многим упростит работу.

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

user command: commit 12345
parsed command: task run --commit 12345

или

user command: kill 12345
parsed command: task fail 12345; task abort 12345; task rm 12345

(да, команда fail тоже будет очень полезной - особенно если она
будет гарантировать, что задание ни при каких условиях не попадет
в репу, даже в случае build --commit).


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [devel] I: gyle --test-only by default

[Alexey V. Vissarionov]

On 2019-03-20 16:09:14 +0300, Dmitry V. Levin wrote:

 > Я не против автоматизации, но почему эта автоматизация должна
 > быть на серверной стороне, а не на клиентской? У вас ведь уже
 > есть все данные для решения этой задачи.

Для унификации.


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

Re: [devel] I: gyle --test-only by default

[Sergey V Turchin]

On Wednesday, 20 March 2019 16:33:10 MSK Alexey V wrote:

[...]
> (да, команда fail тоже будет очень полезной - особенно если она
> будет гарантировать, что задание ни при каких условиях не попадет
> в репу, даже в случае build --commit).
Команда rm уже есть.

-- 
Regards, Sergey.

Re: [devel] I: gyle --test-only by default

[Sergey V Turchin]

On Wednesday, 20 March 2019 15:56:23 MSK Andrey Savchenko wrote:

[...]
> Прошу озвучить эти основания. У нас есть только BuildRequires
> и Requires. С точки зрения обсуждаемой задачи BuildPreReq можно
> приравнять к BuildRequires.
Нет. У меня некоторые BuildRequires меняются в зависимости от того, что имеено 
получилось в результате BuildPreReq.

-- 
Regards, Sergey.

Re: [devel] I: gyle --test-only by default

[Dmitry V. Levin]

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

On Wed, Mar 20, 2019 at 04:09:44PM +0300, Andrey Savchenko wrote:
> On Wed, 20 Mar 2019 16:04:22 +0300 Dmitry V. Levin wrote:
> > On Wed, Mar 20, 2019 at 03:56:23PM +0300, Andrey Savchenko wrote:
> > > On Wed, 20 Mar 2019 15:51:00 +0300 Dmitry V. Levin wrote:
> > > > On Wed, Mar 20, 2019 at 03:47:13PM +0300, Andrey Savchenko wrote:
> > > > [...]
> > > > > Наша система зависимостей на порядок проще, поэтому при надлежащей
> > > > > реализации проблем с временем быть не должно.
> > > > 
> > > > У меня есть основания полагать, что это, к сожалению, не так.
> > >  
> > > Прошу озвучить эти основания. У нас есть только BuildRequires
> > > и Requires. С точки зрения обсуждаемой задачи BuildPreReq можно
> > > приравнять к BuildRequires.
> > 
> > У нас есть Provides, Requires, Conflicts, BuildRequires.
> > 
> > (ещё существует BuildConflicts, но для вычисления сборочной среды
> > BuildConflicts не участвует и про него можно забыть).
> > 
> > Все эти 4 вида зависимостей бывают версионированными с диапазоном версий.
> > У виртуальных пакетов (тех сущностей, которые фигурируют в Provides)
> > бывают альтернативные провайдеры, и выбор провайдера из множества
> > не является произвольным.
> 
> Все эти виды зависимостей есть и в portage, все они могут быть
> версионированными, вирутальными, с диапазонами значений, вида A или
> B или C. Но кроме этого есть зависимости по флагам, со своими
> пересечениями, объединениями и условными зависимостями. И всё это
> работает за разумное время.

Ну я же сильно упростил. BuildRequires являются некоей функцией исходного
кода и сборочной среды, они вычисляются путём выполнения произвольного
кода внутри hasher chroot.

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

> Поэтому вполне возможна реализация решения подобной задачи за
> разумное время и в Альте.

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


-- 
ldv

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [devel] I: gyle --test-only by default

[Andrey Savchenko]

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

On Wed, 20 Mar 2019 18:39:37 +0300 Dmitry V. Levin wrote:
> On Wed, Mar 20, 2019 at 04:09:44PM +0300, Andrey Savchenko wrote:
> > On Wed, 20 Mar 2019 16:04:22 +0300 Dmitry V. Levin wrote:
> > > On Wed, Mar 20, 2019 at 03:56:23PM +0300, Andrey Savchenko wrote:
> > > > On Wed, 20 Mar 2019 15:51:00 +0300 Dmitry V. Levin wrote:
> > > > > On Wed, Mar 20, 2019 at 03:47:13PM +0300, Andrey Savchenko wrote:
> > > > > [...]
> > > > > > Наша система зависимостей на порядок проще, поэтому при надлежащей
> > > > > > реализации проблем с временем быть не должно.
> > > > > 
> > > > > У меня есть основания полагать, что это, к сожалению, не так.
> > > >  
> > > > Прошу озвучить эти основания. У нас есть только BuildRequires
> > > > и Requires. С точки зрения обсуждаемой задачи BuildPreReq можно
> > > > приравнять к BuildRequires.
> > > 
> > > У нас есть Provides, Requires, Conflicts, BuildRequires.
> > > 
> > > (ещё существует BuildConflicts, но для вычисления сборочной среды
> > > BuildConflicts не участвует и про него можно забыть).
> > > 
> > > Все эти 4 вида зависимостей бывают версионированными с диапазоном версий.
> > > У виртуальных пакетов (тех сущностей, которые фигурируют в Provides)
> > > бывают альтернативные провайдеры, и выбор провайдера из множества
> > > не является произвольным.
> > 
> > Все эти виды зависимостей есть и в portage, все они могут быть
> > версионированными, вирутальными, с диапазонами значений, вида A или
> > B или C. Но кроме этого есть зависимости по флагам, со своими
> > пересечениями, объединениями и условными зависимостями. И всё это
> > работает за разумное время.
> 
> Ну я же сильно упростил.

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

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

> BuildRequires являются некоей функцией исходного
> кода и сборочной среды, они вычисляются путём выполнения произвольного
> кода внутри hasher chroot.

Замечательно. Но ведь наша сборочница гарантирует
воспроизводимость; значит, это не произвольный код, а вполне
детерминированное состояние по входным параметрам; значит, это всё
выстраивается в виде графа зависимостей между атомарными элементами
и задача вполне разрешима.

> Т.е. у нас зависимости гораздо более гибкие, но за эту гибкость приходится
> платить.
> 
> > Поэтому вполне возможна реализация решения подобной задачи за
> > разумное время и в Альте.
> 
> Для того, чтобы эта задача имела решение за разумное время, нам нужно
> отказаться от избыточной гибкости и перейти на декларативные сборочные
> зависимости.

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

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

Best regards,
Andrew Savchenko

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

Re: [devel] I: gyle --test-only by default

[Dmitry V. Levin]

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

On Thu, Mar 21, 2019 at 02:50:47AM +0300, Andrey Savchenko wrote:
> On Wed, 20 Mar 2019 18:39:37 +0300 Dmitry V. Levin wrote:
> > On Wed, Mar 20, 2019 at 04:09:44PM +0300, Andrey Savchenko wrote:
> > > On Wed, 20 Mar 2019 16:04:22 +0300 Dmitry V. Levin wrote:
> > > > On Wed, Mar 20, 2019 at 03:56:23PM +0300, Andrey Savchenko wrote:
> > > > > On Wed, 20 Mar 2019 15:51:00 +0300 Dmitry V. Levin wrote:
> > > > > > On Wed, Mar 20, 2019 at 03:47:13PM +0300, Andrey Savchenko wrote:
> > > > > > [...]
> > > > > > > Наша система зависимостей на порядок проще, поэтому при надлежащей
> > > > > > > реализации проблем с временем быть не должно.
> > > > > > 
> > > > > > У меня есть основания полагать, что это, к сожалению, не так.
> > > > >  
> > > > > Прошу озвучить эти основания. У нас есть только BuildRequires
> > > > > и Requires. С точки зрения обсуждаемой задачи BuildPreReq можно
> > > > > приравнять к BuildRequires.
> > > > 
> > > > У нас есть Provides, Requires, Conflicts, BuildRequires.
> > > > 
> > > > (ещё существует BuildConflicts, но для вычисления сборочной среды
> > > > BuildConflicts не участвует и про него можно забыть).
> > > > 
> > > > Все эти 4 вида зависимостей бывают версионированными с диапазоном версий.
> > > > У виртуальных пакетов (тех сущностей, которые фигурируют в Provides)
> > > > бывают альтернативные провайдеры, и выбор провайдера из множества
> > > > не является произвольным.
> > > 
> > > Все эти виды зависимостей есть и в portage, все они могут быть
> > > версионированными, вирутальными, с диапазонами значений, вида A или
> > > B или C. Но кроме этого есть зависимости по флагам, со своими
> > > пересечениями, объединениями и условными зависимостями. И всё это
> > > работает за разумное время.
> > 
> > Ну я же сильно упростил.
> 
> Я тоже сильно упростил, умолчав про слоты, профили, попакетную
> настройку USE-флагов, сильные и слабые зависимости, сборочные хост
> зависимости для кросс-компилирования, логические ограничения на
> комбинации флагов и многое другое.
> 
> И со всей этой неимоверной сложностью обсуждаемая задача решена
> и работает за разумное время (да, бывают баги, да, не всегда
> идеально, но работает), поэтому у меня волосы встают дыбом, когда
> мне говорят, что в Альте, на существенно более простой системе
> зависимостей, это якобы невозможно.

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

> > BuildRequires являются некоей функцией исходного
> > кода и сборочной среды, они вычисляются путём выполнения произвольного
> > кода внутри hasher chroot.
> 
> Замечательно. Но ведь наша сборочница гарантирует
> воспроизводимость; значит, это не произвольный код, а вполне
> детерминированное состояние по входным параметрам; значит, это всё
> выстраивается в виде графа зависимостей между атомарными элементами
> и задача вполне разрешима.

К сожалению, именно произвольный код, выполняющийся внутри hasher chroot.
Это часть наследия, которое нам досталось вместе с rpm.
Максимум, что мы можем себе позволить, не отказываясь от этого наследия,
это постулировать, что сборочная среда определяется только репозиторием и
сборочницей, и на этом основании использовать кэшированный результат,
если исходный код и репозиторий не поменялись.
> 
> > Т.е. у нас зависимости гораздо более гибкие, но за эту гибкость приходится
> > платить.
> > 
> > > Поэтому вполне возможна реализация решения подобной задачи за
> > > разумное время и в Альте.
> > 
> > Для того, чтобы эта задача имела решение за разумное время, нам нужно
> > отказаться от избыточной гибкости и перейти на декларативные сборочные
> > зависимости.
> 
> Не вижу такой необходимости. Любой гибкой зависимости в конечном
> счёте отвечает конкретный пакет, поэтому можно выстроить
> отображение гибких зависимостей на конкретные пакеты, их
> предоставляющие, поэтому задача сводится к задаче поиска на
> попакетных зависимостях с операторами AND, OR, NOT.

Из-за этой гибкости сведение к логической задаче имеет гораздо большую
вычислительную сложность, чем решение этой логической задачи.

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

> Разумеется, решение этой задачи не пишется на коленке за полчаса
> и для её выполнения за разумное время наверняка понадобится более
> производительный язык, чем шелл.

Шелл - это прокладка между вызываемыми программами.


-- 
ldv

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [devel] I: gyle --test-only by default

[Dmitry V. Levin]

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

On Wed, Mar 20, 2019 at 04:05:55PM +0300, Dmitry V. Levin wrote:
> On Wed, Mar 20, 2019 at 03:01:53PM +0200, Igor Vlasenko wrote:
> > On Wed, Mar 20, 2019 at 03:28:16PM +0300, Dmitry V. Levin wrote:
> > > On Wed, Mar 20, 2019 at 12:09:20PM +0200, Igor Vlasenko wrote:
> > > [...]
> > > > а надо бы только при появлении unmets.
> > > 
> > > Почему?
> > 
> > Как бы мне и так очевидно, что
> > пересборка по критерию, входит ли пакет A в сборочное окружение
> > пакета B изначально была ошибочным допущением.
> 
> Я считаю иначе.

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

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


-- 
ldv

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [devel] I: gyle --test-only by default

[Alexey Tourbin]

On Wed, Mar 20, 2019 at 1:56 PM Igor Vlasenko <vlasenko@imath.kiev.ua> wrote:
> > > #225014 BUILDING #4.4 [locked] sisyphus/zerg qt5-base.git=5.12.2-alt1 ...
> > > .4 в 4.4 - что это?
>
> > Это когда между предыдущей и следующей итерацией начинает собираться
> > другой пакет этого же мантейнера, либо который сам влияет на сборку
> > этого пакета, либо задерживает её на столько, что успевает проскочить
> > чей-то ещё влияющий.
>
> "влияет на сборку этого пакета" - ключевое слово.
>
> Я уже писал в цикле писем, посвященным внедрению параллельных
> алгоритмов для сборочницы,
> такие пересборки, призванные бороться с абстрактным "влиянием",
> бессмысленны и вредны. Есть конкретные показания к
> пересборке, например, unmet.
>
> А "влияние" ?
> Сколько я видел ненужных и бесполезных AVAITING 1.12, AVAITING 1.18 ...

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

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

Re: [devel] I: gyle --test-only by default

[Alexey Tourbin]

On Wed, Mar 20, 2019 at 3:40 PM Dmitry V. Levin <ldv@altlinux.org> wrote:
> On Wed, Mar 20, 2019 at 02:51:39PM +0300, Andrey Savchenko wrote:
> > On Wed, 20 Mar 2019 13:38:57 +0300 (MSK) Ivan Zakharyaschev wrote:
> > > On Wed, 20 Mar 2019, Alexey V. Vissarionov wrote:
> > > > В общем, оптимальный по эргономике вариант видится мне примерно так:
> > > >
> > > > set task=`ssh build.alt build $repo $tag`
> > > > тестируем - лопухнулись, исправляем
> > > > set task=`ssh build.alt build $repo $tag`
> > > > опять тестируем - порядок
> > > > ssh build.alt commit $task
> > >
> > > Сейчас это ssh build.alt task run --commit $task
> > >
> > > Если состояние репозитория и задания позволяют, оно сразу же делает commit
> > > сейчас, без пересборки.
> > >
> > > Просто тут дело не только в интерфейсе, но и в алгоритме работы (и его
> > > спецификации) сборочницы: задание может быть закоммичено, только если оно
> > > было собрано исходя из текущего состояния репозитория,
> >
> > Но ведь это избыточное условие для обеспечения пересобираемости
> > пакетов и транзакционности сборки. Если пакет A не входит
> > в сборочное окружение пакета B (в т.ч. и по сборочным зависимостям
> > пакетов и сборочного окружения B, которые могут быть в свою
> > очередь рекурсивными), то пакет B можно пересобирать вне
> > зависимости от изменений пакета A.
>
> У нас очень дорогая проверка того, входит ли пакет A в сборочное окружение
> пакета B.

Она не очень дорогая. При генерации /var/cache/apt/pkgcache.bin 2
секунды уходит на распаковку pkglist.classic.xz, но это не подавляюще
много. По-моему, проверку нельзя легко и сильно удешевить.

> > По сути, это классическая задача поиска путей в графе и @viy уже
> > много раз писал на эту тему и то, как её алгоритмизировать.
>
> Для того, чтобы эту задачу решать быстро, насколько я понимаю,
> надо упростить зависимости и отказаться от apt в пользу инструментов,
> заточенных на решение этой задачи.

Если совсем извести двусмысленные зависимости, то тогда отпадает
потребность в логике выбора, и такой инструмент становится более
реальным. Но ведь двусмысленные зависимости, вроде autoconf_2.13 и
autoconf_2.60, существуют специально. Чтобы эта специальная логика
выбора отрабатывала когда надо и немножко облегчала жизнь.

Ну и потом специальный инструмент всё равно не сможет работать чисто
на pkglist'ах, есть же еще RPMS.hasher, который надо сканировать, и
генерировать общее состояние, где RPMS.hasher перекрывает основной
репозиторий; и значит всё равно появляется выбор. Получается
подозрительно похоже на apt.

Re: [devel] I: gyle --test-only by default

[Alexey V. Vissarionov]

On 2019-03-21 06:58:09 +0300, Alexey Tourbin wrote:

 >>> По сути, это классическая задача поиска путей в графе и @viy
 >>> уже много раз писал на эту тему и то, как её алгоритмизировать.
 >> Для того, чтобы эту задачу решать быстро, насколько я понимаю,
 >> надо упростить зависимости и отказаться от apt в пользу
 >> инструментов, заточенных на решение этой задачи.
 > Если совсем извести двусмысленные зависимости, то тогда
 > отпадает потребность в логике выбора, и такой инструмент
 > становится более реальным. Но ведь двусмысленные зависимости,
 > вроде autoconf_2.13 и autoconf_2.60, существуют специально.
 > Чтобы эта специальная логика выбора отрабатывала когда надо и
 > немножко облегчала жизнь.
 > Ну и потом специальный инструмент всё равно не сможет работать
 > чисто на pkglist'ах, есть же еще RPMS.hasher, который надо
 > сканировать, и генерировать общее состояние, где RPMS.hasher
 > перекрывает основной репозиторий; и значит всё равно появляется
 > выбор. Получается подозрительно похоже на apt.

2 ldv: ну что, откапываем deepsolver? :-)


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

Re: [devel] железо на сборочнице

[Anton Farygin]

21.03.2019 3:31, Dmitry V. Levin пишет:
> On Wed, Mar 20, 2019 at 04:05:55PM +0300, Dmitry V. Levin wrote:
>> On Wed, Mar 20, 2019 at 03:01:53PM +0200, Igor Vlasenko wrote:
>>> On Wed, Mar 20, 2019 at 03:28:16PM +0300, Dmitry V. Levin wrote:
>>>> On Wed, Mar 20, 2019 at 12:09:20PM +0200, Igor Vlasenko wrote:
>>>> [...]
>>>>> а надо бы только при появлении unmets.
>>>> Почему?
>>> Как бы мне и так очевидно, что
>>> пересборка по критерию, входит ли пакет A в сборочное окружение
>>> пакета B изначально была ошибочным допущением.
>> Я считаю иначе.
> Уточню: я считаю очевидным, что если сборочная среда пакета в задании
> изменилась, то этот пакет подлежит пересборке.  Если пакет в результате
> пересборки изменился, то все касающиеся его тесты подлежат перепроверке.
>
> Более того, я считаю очевидным, что если свежесобранный пакет входит в
> сборочную среду других пакетов, то все они должны быть незамедлительно
> пересобраны и перепроверены.  К сожалению, это у нас ещё не реализовано.
Мне кажется, что надо идти по самому простому пути - и сейчас 
распараллеливание install check даст очень много свободного времени 
сборочницы заданиям, в которых эта проверка занимает несущественное время.

Ну и при всей критике нашей сегодняшней сборочницы - не стоит забывать, 
что реально она сейчас работает на оборудовании десятилетней давности и 
узкое место при этом не x86, а aarch64.

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

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

Re: [devel] I: gyle --test-only by default

[Anton Farygin]

20.03.2019 16:14, Igor Vlasenko пишет:
> On Wed, Mar 20, 2019 at 04:08:07PM +0400, Sergey Afonin wrote:
>> On Wednesday 20 March 2019, Igor Vlasenko wrote:
>>
>>> А "влияние" ?
>>> Сколько я видел ненужных и бесполезных AVAITING 1.12, AVAITING 1.18 ...
>>   
>> Тут момент такой, что если задание не будет задержано другим заданием
>> _этого_же_  мантейнера, вероятность того, что кто-то успеет повлиять
>> очень сильно уменьшается. Я только об этом. В качестве примера, цепочка
>> из POSTPONED даже сейчас, если ничего больше не делать, соберётся заметно
>> быстрее.
> Это вы альтернатив не распробовали.
> Я вот разбалован хорошим, и для меня это "быстрее"
> звучит как 700 лет пройдет быстрее, чем 1000.
> Для сравнения, я сегодня обновлял autoimports/cpanbuilder.

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


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

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

Для примера - можно посмотреть схему принятия изменений в такие проекты 
как LibreOffice или FreeIPA.

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

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

Re: [devel] железо на сборочнице

[Sergey Afonin]

On Thursday 21 March 2019, Anton Farygin wrote:

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

-- 
С уважением, Сергей Афонин.

Re: [devel] I: gyle --test-only by default

[Andrey Savchenko]

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

On Thu, 21 Mar 2019 07:50:43 +0300 Anton Farygin wrote:
> 20.03.2019 16:14, Igor Vlasenko пишет:
> > On Wed, Mar 20, 2019 at 04:08:07PM +0400, Sergey Afonin wrote:
> >> On Wednesday 20 March 2019, Igor Vlasenko wrote:
> >>
> >>> А "влияние" ?
> >>> Сколько я видел ненужных и бесполезных AVAITING 1.12, AVAITING 1.18 ...
> >>   
> >> Тут момент такой, что если задание не будет задержано другим заданием
> >> _этого_же_  мантейнера, вероятность того, что кто-то успеет повлиять
> >> очень сильно уменьшается. Я только об этом. В качестве примера, цепочка
> >> из POSTPONED даже сейчас, если ничего больше не делать, соберётся заметно
> >> быстрее.
> > Это вы альтернатив не распробовали.
> > Я вот разбалован хорошим, и для меня это "быстрее"
> > звучит как 700 лет пройдет быстрее, чем 1000.
> > Для сравнения, я сегодня обновлял autoimports/cpanbuilder.
> 
> Игорь, проблема автоматических пакетов в том, что неизвестно, какие 
> изменения в них идут с апстримов и неизвестно, какое влияние они окажут 
> на систему в целом.
> Неизвестно это ровно до того момента, пока данный пакет не будет 
> установлен в живую систему пользователя и проверен в интеграции с 
> окружением.
> 
> 
> Нам от такой автоматизации как у нас надо уходить к системе, в которой 
> после сборки каждого пакета запускаются интеграционные и функциональные 
> тесты, не дающие сборочнице выполнить коммит до того момента, пока 
> ошибки выполнения этих тестов не будут исправлены ментейнером (или его 
> скриптами).
> 
> Да, это заметно снизит скорость прохождения автоматически собранных 
> пакетов в репозиторий, но при этом так же заметно повысит качество 
> результата.
> 
> Для примера - можно посмотреть схему принятия изменений в такие проекты 
> как LibreOffice или FreeIPA.
> 
> Да, часто можно уповать на разработанные апстримом тесты, но во многих 
> случаях такого тестирования недостаточно и требуется проверка на 
> функционирование пакета в составе более серьёзного стенда.
> 
> Грубо говоря - цена ошибки, пойманной на стороне сборочницы намного ниже 
> цены ошибки, пойманной ручным тестированием дистрибутива у нас или, что 
> ещё хуже - на стороне пользователя.

Это можно реализовать лишь точечно для наиболее важных пакетов.
Если проводить такую политику для всех пакетов в репозитории, то
или разработка встанет (что будет ещё хуже для пользователей —
у них просто не будет новых версий), или количество пакетов
в репозитории сократится до 300.

Best regards,
Andrew Savchenko

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

Re: [devel] I: gyle --test-only by default

[Anton Farygin]

21.03.2019 10:59, Andrey Savchenko пишет:
> On Thu, 21 Mar 2019 07:50:43 +0300 Anton Farygin wrote:
>> 20.03.2019 16:14, Igor Vlasenko пишет:
>>> On Wed, Mar 20, 2019 at 04:08:07PM +0400, Sergey Afonin wrote:
>>>> On Wednesday 20 March 2019, Igor Vlasenko wrote:
>>>>
>>>>> А "влияние" ?
>>>>> Сколько я видел ненужных и бесполезных AVAITING 1.12, AVAITING 1.18 ...
>>>>    
>>>> Тут момент такой, что если задание не будет задержано другим заданием
>>>> _этого_же_  мантейнера, вероятность того, что кто-то успеет повлиять
>>>> очень сильно уменьшается. Я только об этом. В качестве примера, цепочка
>>>> из POSTPONED даже сейчас, если ничего больше не делать, соберётся заметно
>>>> быстрее.
>>> Это вы альтернатив не распробовали.
>>> Я вот разбалован хорошим, и для меня это "быстрее"
>>> звучит как 700 лет пройдет быстрее, чем 1000.
>>> Для сравнения, я сегодня обновлял autoimports/cpanbuilder.
>> Игорь, проблема автоматических пакетов в том, что неизвестно, какие
>> изменения в них идут с апстримов и неизвестно, какое влияние они окажут
>> на систему в целом.
>> Неизвестно это ровно до того момента, пока данный пакет не будет
>> установлен в живую систему пользователя и проверен в интеграции с
>> окружением.
>>
>>
>> Нам от такой автоматизации как у нас надо уходить к системе, в которой
>> после сборки каждого пакета запускаются интеграционные и функциональные
>> тесты, не дающие сборочнице выполнить коммит до того момента, пока
>> ошибки выполнения этих тестов не будут исправлены ментейнером (или его
>> скриптами).
>>
>> Да, это заметно снизит скорость прохождения автоматически собранных
>> пакетов в репозиторий, но при этом так же заметно повысит качество
>> результата.
>>
>> Для примера - можно посмотреть схему принятия изменений в такие проекты
>> как LibreOffice или FreeIPA.
>>
>> Да, часто можно уповать на разработанные апстримом тесты, но во многих
>> случаях такого тестирования недостаточно и требуется проверка на
>> функционирование пакета в составе более серьёзного стенда.
>>
>> Грубо говоря - цена ошибки, пойманной на стороне сборочницы намного ниже
>> цены ошибки, пойманной ручным тестированием дистрибутива у нас или, что
>> ещё хуже - на стороне пользователя.
> Это можно реализовать лишь точечно для наиболее важных пакетов.
> Если проводить такую политику для всех пакетов в репозитории, то
> или разработка встанет (что будет ещё хуже для пользователей —
> у них просто не будет новых версий), или количество пакетов
> в репозитории сократится до 300.

Базовые проверки можно делать для всех.

Например, так можно было бы поймать проблему с сегодняшним dist-upgrade.

Re: [devel] I: gyle --test-only by default

[Dmitry V. Levin]

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

On Thu, Mar 21, 2019 at 06:58:09AM +0300, Alexey Tourbin wrote:
> On Wed, Mar 20, 2019 at 3:40 PM Dmitry V. Levin wrote:
[...]
> > У нас очень дорогая проверка того, входит ли пакет A в сборочное окружение
> > пакета B.
> 
> Она не очень дорогая. При генерации /var/cache/apt/pkgcache.bin 2
> секунды уходит на распаковку pkglist.classic.xz, но это не подавляюще
> много. По-моему, проверку нельзя легко и сильно удешевить.

Для того, чтобы выяснить, входит ли пакет A в сборочное окружение пакета B,
нам в общем случае нужно вычислить это сборочное окружение пакета B.
Сейчас для этого надо
- создать базовый чрут;
- распаковать спек-файл пакета B, извлечь из него BuildRequires(pre),
  установить по ним пакеты;
- распаковать исходный код, вычислить BuildRequires, вычислить по ним
  пакеты.

В общем случае это довольно долго, особенно если речь идёт обо всех
исходных пакетах.

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

> > > По сути, это классическая задача поиска путей в графе и @viy уже
> > > много раз писал на эту тему и то, как её алгоритмизировать.
> >
> > Для того, чтобы эту задачу решать быстро, насколько я понимаю,
> > надо упростить зависимости и отказаться от apt в пользу инструментов,
> > заточенных на решение этой задачи.
> 
> Если совсем извести двусмысленные зависимости, то тогда отпадает
> потребность в логике выбора, и такой инструмент становится более
> реальным. Но ведь двусмысленные зависимости, вроде autoconf_2.13 и
> autoconf_2.60, существуют специально. Чтобы эта специальная логика
> выбора отрабатывала когда надо и немножко облегчала жизнь.

С одной стороны да.  С другой стороны, на практике пакету с зависимостью
на autoconf вряд ли подойдёт любой autoconf.  В конечном итоге мы
отказались от альтернатив для autoconf, automake, libtool и gcc,
поскольку множественность вариантов для этих зависимостей не нужна.

> Ну и потом специальный инструмент всё равно не сможет работать чисто
> на pkglist'ах, есть же еще RPMS.hasher, который надо сканировать, и
> генерировать общее состояние, где RPMS.hasher перекрывает основной
> репозиторий; и значит всё равно появляется выбор. Получается
> подозрительно похоже на apt.

В таком варианте да.  А если обновлять pkglist'ы после каждого сабтаска
и не сканировать RPMS.hasher?  Если не генерить pkglist'ы с нуля, а патчить,
это не должно быть долго.


-- 
ldv

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]