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=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,RP_MATCHES_RCVD,SUBJ_ALL_CAPS autolearn=ham autolearn_force=no version=3.4.1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=imath.kiev.ua; s=hydra; t=1518888456; bh=7s9cPbcZxSGgcO0nW7pXD+Dxi4PVUnC9mMT0cGOlwAc=; h=Date:From:To:Subject; b=nLJzpT/IIYxOfRjwG097eM0Vdl9KDnGUJ41gHpE21/tBRJ9pp5g3eWX/ev2EQXxff etu+vBmC/M0QUNN+J9wR5IM0MpdLNdRq9iVuG6poBlcVYsWex8i9PyQiuqVAOvvKqH 7q4Wu7JW2mzq3Ga9q3mXqWfE57hfrHf0HcdPgodA= Date: Sat, 17 Feb 2018 19:27:35 +0200 From: Igor Vlasenko To: devel@lists.altlinux.org Message-ID: <20180217172735.GA30426@dad.imath.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.9.1 (2017-09-22) Subject: [devel] =?utf-8?b?0KHQsdC+0YDQvtGH0L3QuNGG0LAgKElJSSk6INCX0LA=?= =?utf-8?b?0YfQtdC8INGD0YHQutC+0YDRj9GC0Yw/?= 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: Sat, 17 Feb 2018 17:27:41 -0000 Archived-At: List-Archive: List-Post: Уважаемые господа, в предыдущих письмах я писал о том, что сборочница медленная, и о том, как ее можно существенно ускорить, без покупки нового железа, только за счет внесения изменений в алгоритм ее работы. В этом письме хочу рассмотреть вопрос, зачем ее надо ускорять. Моими уважаемыми оппонентами в этом вопросе выступили Алексей и Дмитрий, которые привели аргументы 2-х классов. 1) примеры перегрузки сборочницы некорректные, так как представляют собой неправильные практики майнтайнерства. 2) не надо гнаться за производительностью, превышающей средний трафик. зачем сборочнице простаивать? Начну разбор с 1-го класса возражений. Более обще, > Сборка пакета имеет смысл, если она меняет что-то у пользователя. Если > на стороне пользователя ничего не меняется, то вы создаете > бессмысленный шум. Но есть большая индустрия "очистки спеков" и т.п., > которая, за неимением лучшего, выдается за "разработку". Вы выступаете > апологетом порочных практик, исходя из примитивно понятых базовых > показателей. Возможно даже вы делаете это добросовестно. и более конкретно, > Очевидно, что публиковать якобы новые сборки пакетов, в которых > ничего не меняется, не просто не нужно, но и вредно. [...] > Слепо пересобирать чужие сборки из-за записи в %changelog'е вида > - Rebuilt for https://fedoraproject.org/wiki/Fedora_NN_Mass_Rebuild > не просто не нужно, но и вредно. По поводу импорта, я уже много писал, не хочу повторяться. Однако, неужели в других дистрибутивах ни багов не чинят, ни пакетов не обновляют и не улучшают? В импорт только Mass_Rebuild и попадает? Да, есть недостаток индивидуального подхода к каждому кусту. Это как копать картошку трактором, по сравнению с ротой стройбата с лопатами. Проблема в том, что нас мало, не тянем мы на роту, максимум на два взвода. Поэтому, tractor it is. Другой критикуемый пример -- пересборка python-* без BR: python-modules-setuptools-tests. Кто-то предлагал, зачем рубить шашкой все пакеты, проще сделать хак и забыть. Вот пример, когда-то сделал хак и забыл, а оно зажило своей жизнью и начало разрастаться по Сизифу. https://bugzilla.altlinux.org/show_bug.cgi?id=34535 Когда увидел, был в шоке! Когда понял, что это такое и зачем, облегченно вздохнул. /Да, это ужас, но не Ужас-Ужас./ Но шашкой или топором, в будущем вырубить это надо. Кто-то предлагал, давайте изменения накапливать в git-ах, а в сборочницу не отправлять. Так в этом случае крайним окажется giter - там места не хватит. Отправлять в Сизиф, а не копить у себя - это сейчас хорошая, годная стратегия. Это как "Вы скорбите по тем временам, когда мужчины были настоящими мужчинами и сами писали драйверы устройств?" Мужики перевелись? Нет. Раньше железо было дорого, а сейчас дешево. Раньше писать драйвер было осмысленно, сейчас проще выбросить и купить подходящее -- редкое, очень редкое железо дорого настолько, чтобы писать к нему драйвер было осмысленно. Раньше пакетов было мало, и майнтайнеры могли позволить себе держать их в голове. А сейчас пакетов много, и между ними надо постоянно переключаться. Отсюда и новый ритм - сделал, отправил, забыл. Что делать, такие времена, такие нравы. Продолжу разбор по 2-му классу возражений. 2а) > Понимаете, в чем дело. Время всё равно уходит, а сборочица всё равно > простаивает. И показатель несколько тысяч транзакций в сутки всё равно > не нужен. То есть вы занимаетесь неправильной задачей оптимизации. "Уже сейчас сборочница иногда простаивает. А если мы сборочницу оптимизируем, то она начнет простаивать гораздо чаще. А простаивать неправильно." Будет простаивать --- хорошо, освободившиеся мощности можно занять под тот же супербихайв: пересборка + полное сборочностное тестирование пакетов из Сизифа. Роботы можно подключить, майнтайнеры потянутся, если сборка там будет быстрее, чем локально. 2b) > Вряд ли мы хотим решать задачу принимать в Сизиф 60*60*24/2==43200 > транзакций в сутки (в среднем по 2 секунды на транзакцию), это число > более чем в 2 раза превышает число исходных пакетов в нынешнем Сизифе. > Такая задача сама по себе не выглядит осмысленной. Как раз очень даже осмысленная задача. 43200 транзакций в сутки -- это не ожидаемый трафик, а желаемая пиковая мощность, следствием которой является повышение "отзывчивости" сборочницы, что приводит к повышению производительности труда ее пользователей. На эту тему есть хорошая притча. Приходит сисадмин к директору с предложением расширить канал доступа в интернет. Директор посмотрел обоснование и сказал: с таким трафиком, как у нас, мы не расширять, а еще в 100 раз ужать канал можем, чтобы приблизить ширину канала к реальному трафику, заодно и деньги сэкономим. Сисадмин сказал: смешивать трафик и ширину канала (пиковую мощность) некорректно. Рассмотрим к примеру унитаз. Трафик у него относительно небольшой, однако ширину канала у него стараются делать как можно больше. Да. большую часть времени он простаивает. Но если в нем появляется трафик, то его нужно как можно быстрее пропустить через устройство, для чего к нему и подводят такой широкий канал. Если же канал сузить, то трафик будет проходить за время, неприемлемое для пользователя. Если в офисе веб-страница загружается за 10 мин, то, формально, в офисе есть интернет. Если в туалете унитаз сливается за 10 мин, то, формально, в офисе есть туалет. Если в сборочнице легкая транзакция обрабатывается 3 суток, то, формально, сборочница в порядке. При этом сотрудник был на 3 суток лишен обратной связи и был вынужден переключиться на другие задачи. И я понимаю сотрудников, которые в такой ситуации призывают * тяжелые сайты не посещать * по большому не ходить * пакеты в сборочницу лишний раз не заливать. Но лучше все-таки прислушаться к тревожному звонку и обратиться к админу/сантехнику/разработчику. Заранее. -- I V