From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on sa.local.altlinux.org X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=lCjxnhgdadtr8QnjYAsIYsWy1AJYXFdPR5Jqn3jsTvc=; b=AZY/hutMjtvosrU8HItb+7YJP3L4nsZ5NJjHFJl7MXjR8kXffsI9UN4pXO04c6Xj7E QgrzvQ/LXhVNGXuKx9knH10vYmkvxsfTLjHzss9ssBEUhk0pIQbiHYOYpC5OcOxBNFVN cR1uvDiTNDvjQYAPpanfcRubHrKJg2g2s3aGI3fXqq7uBmnGDVYzB/RdxqL35UtL0d91 w5UaH+0XW6LKD0wo35xCPDUWlzGKyMNLQAmei62OK1rMFRKI7Va+bY55kqlcNaGivYCU 1GKmsjJYPWC8opE5EpDxAaJ6is7Voz3JcruwT+yKqrHeeoUcHR7hUtjpDP34HR+XRy84 pNLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=lCjxnhgdadtr8QnjYAsIYsWy1AJYXFdPR5Jqn3jsTvc=; b=gVkOYGiHhxfucwYsiGLXWZOSj6UKCdB12Hm+vLgde4ST0B5C07v8Whwr4moI6s90i2 4jy8g7G/3Sjp8fEHqoYBAaxSxw7aXXaFnqLiXKJhASnI3mZAcMhubtRrtX5cCzz1udQY x+9rWCOndqOEZdK3dcsq/oZ9PSvNC3R2jlTJOFUU1SP6AMHdIfklKEFij+/KvxuFDOWZ Dpz+qiW/tb9dw+KqWW52oGO0NvfwA6AvyUjFEUNggZEgywFiLfm2FnLaFlq3ZrFoecSJ LF++QSGX5Wx0JhasBDHyeyxdRvWF+6hhzNG+Af5+FshgcCotDRrdKAg5Yia/GdOiDa+n HVAA== X-Gm-Message-State: APf1xPAQaL7EjFHH+krufk+zYH8vUoLNJaVq4PXR2AyAktDCPhbJsfID xHTN3Z4cEzTzJ5XNPD6ID9DuNw== X-Google-Smtp-Source: AH8x225+G2s+t8ko5m/bqxVx4yO8cRX8dy63Kne26OvzU2w6J7q7l9Vj0NFjapXyAOhelyCoWzubwA== X-Received: by 10.46.42.66 with SMTP id q63mr11040747ljq.133.1519085037040; Mon, 19 Feb 2018 16:03:57 -0800 (PST) From: Leonid Krivoshein To: ALT Linux Team development discussions References: <20180215223320.GA14086@dad.imath.kiev.ua> <20180216013323.GA10681@altlinux.org> Message-ID: Date: Tue, 20 Feb 2018 03:03:55 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <20180216013323.GA10681@altlinux.org> Content-Type: text/plain; charset=koi8-r; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [devel] =?utf-8?b?0JfQsNC00LDRh9C4INC00LvRjyDRgdCx0L7RgNC+0Yc=?= =?utf-8?b?0L3QuNGG0Ysg0YHQu9C10LTRg9GO0YnQtdCz0L4g0L/QvtC60L7Qu9C10L0=?= =?utf-8?b?0LjRjw==?= X-BeenThere: devel@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ALT Linux Team development discussions List-Id: ALT Linux Team development discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Feb 2018 00:04:00 -0000 Archived-At: List-Archive: List-Post: Можно тут рядышком постоять? Иначе для чего ещё эта рассылка... 16.02.2018 04:33, Dmitry V. Levin пишет: > Предлагаю начинать разговор не с алгоритмов оптимизации сборочницы, > а с задач, которые мы хотим решать с помощью сборочной системы > следующего поколения. > > ... > > Одна из задач, которую мы хотели решать ещё 9 лет назад - оперативно > выявлять регрессии собираемости/устанавливаемости пакетов репозитория > и на этом основании (полу)автоматически принимать решения об окончательном > коммите транзакций. Правильно понимаю, что полуавтоматическое принятие решения позволяет, в числе прочего, условно модератору репозитория откатывать мержи вручную? Если да, то какова (обычно) судьба всех последующих мержей, следующих за выкинутым(и)? > Мы хотим не только автоматически выявлять анметы, порождаемые транзакцией, > но и... > Наша традиционная сборочная система обладает следующим полезным свойством: > каждое следующее состояние репозитория получается в результате применения > транзакции к предыдущему состоянию. > > Такой детерминизм позволяет воспроизводимо получать новое состояние > репозитория из старого путём последовательного применения транзакций. > Для разработчиков, госадминов и регуляторов большой интерес представляет репозиторий с исходниками (git, .src.rpm). Для большинства конечных пользователей куда важнее работоспособность производного -- бинарного репозитория. Очень хорошо, что сборочница позволяет автоматически выявлять и пресекать многие проблемы "на подлёте". Но мы же понимаем, что выявить все проблемы автоматически нельзя. И со всеми успешно прошедшими тестами, случается, возникают регрессии, больше проявляющиеся даже не в части сборки/установки, а уже в процессе эксплуатации. Конечно важно мерило, определяющее качество исходного репозитория, в целом, полученного в результате очередной (мега) транзакции. Но также важно иметь возможность отката отдельных изменений с автоматическим применением последующих изменений. Тогда фаза тестирования может отставать (то бишь не быть тормозящим фактором), но при необходимости, бить по мержу вдогонку. А все последующие (мега) транзакции в случае такого фейла могут быть объединены в ещё более крупную супер-(мега) транзакцию. > К чему привело бы применение нескольких транзакций одновременно? В общем > случае к тому, что результат применения отличался бы от результата > последовательного применения. Не лучше ли вместо этого (спекулятивно) > объединять множество транзакций, готовых к применению, в полноценные > мега-транзакции, обрабатываемые как обычные транзакции? Если одна обычная транзакция -- изменения репозитория в результате одобрения задания из одного и более исходных пакетов, то мега-транзакция -- это, если не весь репозиторий, то, по крайней мере, оба графа зависимостей с каждым из пакетов накопившихся к текущему моменту заданий (сборочными и установочными), верно? Мне кажется, если преодолеть зависимость мержа от предыдущего мержа не в ущерб воспроизводимой сборке, мы как раз-таки получим параллельную сборочницу нового поколения. Очерёдность безусловно важна. Но ведь если кому-то в очереди становится плохо, очередь от этого не аннулируется. Можно гонять сборочницу несколько раз в сутки по всем необходимым пакетам по мере их поступления, но публиковать только те состояния репозитория, при которых мерило показывает приемлемый результат. То есть мега-транзакция может допускать фейлы отдельных пакетов. Но такое состояние не публикуется, а учитывается на следующих кругах. -- Best regards, Leonid Krivoshein.