Упоминание про O(n) и radix sort имеет "так себе" смысл, потому что как в поразрядной, так и в распределяющей сортировке это log N присутствует косвенно, в виде количества битов. Если у вас элементы с ключом в 10 бит, вы сделаете до 10 проходов, а если 20 бит - до 20 проходов, рекурсивно или в цикле - не суть важно. Поэтому у неё тоже O(n log n), а утверждение по O(n) - чисто трюк.
Доказательство теоремы 1 выглядит слишком вольно написанным и не соответствующим математической строгости. Есть ссылка на более формальный вид?
Финальный проход sort() в GCC библиотеке - тут я бы подчеркнул, что эта сортировка вставками никогда не будет перемещать элементы за пределами каждого того отрезка, за которым мы бросили рекурсию из-за малости длины отрезка. Поэтому она не становится квадратичной. Но что мне не совсем нравится в этой реализации, это то, что она будет финально проходиться и по тем участкам, на которых было переключение в heapsort из-за исчерпания бюджета рекурсии - а они уже отсортированы. Цена того скана, конечно, мала, но не ноль. Надеюсь, тут было применено и не один раз сравнение на каких-то больших тестовых данных.
Можете ли вы откатить изменения на страрую версию не вставая с кресла?
Зависит от конкретной миграции. Обычно привязка к биллингу, а он сильно сложнее самого свича, и вот там бывает много тонкостей. Я в нём не разбираюсь, но по тому, что читаю вскользь, саппортеры обычно в состоянии перевести назад.
Есть ли у вас договор с заказчиком c SLA? Если у вас риалтайм метрики , мониторинг и логи?
Всё это обычно есть. Можно выключить:)
Испраление бага в телефонной станции звучит дорого. Особенно если она не одна.
Ну так как работает, по факту, код, то это обычные процедуры наката и рестарта, с поправкой на параллельную работу нескольких дублирующих серверов и инструкции балансеру.
Некоторые баги могут быть не замечены неделями.
Некоторые и годами жили. Но это уж очень тонкие случаи.
Басфактор падает только до единицы, дальше автобусу не за что зацепиться.
Это не так. Представим себе, что некоторый компонент известен Пете полностью вдоль и поперёк, поскольку он его пять лет дополнял; Вите - так себе, потому что только ревью читал и что-то в памяти отложилось; Денису - читал тикеты и знает основные грабли; Коле - знает, что такое есть и зачем, но чтобы даже понять, как стартовать, ему нужно час читать доку. Такое знание, в большинстве случаев, очень дробно квантуемое.
На одной из работ был такой "многостаночник", который умел типа всё что есть в работе. По факту он про пару десятков подсистем только знал, где и зачем они работают и как найти документацию по ним. Если бы надо было что-то срочно сделать, он ничего бы не смог, только выделить кого-то другого и дать ему вкопаться уже надолго.
Локальные ветки как раз могут называться как левой пятке угодно, лишь бы автору было понятно. На общем сервере стандартов побольше, но у одних может быть bugfix/TT123456, а у других bugfix/too-slow-closing, и это тоже нормально, пока достаточно информации для понимания, о чём вообще речь. А вот сообщение коммита, которое фиксируется в истории, чётко структурируется и формализуется.
А ваш "вопрос", мало того что неверен в предпосылках, так ещё и представляет собой классическое Imago с элементами Jubilare. Не надо так, вы в приличное место пришли.
Вашим коллегам повезло, что вы можете тратить так много времени на это и можете удержать в голове так много информации за раз.
"Так много" это аж никак не конкретное значение. И я не уверен, что ваша оценка его сколь-нибудь адекватно коррелирует с тем, сколько мы реально тратим.
Я хочу получить ревью от эксперта в области на критические части фичи, где экспертиза принесёт пользу. Остальной код я могу распределить на других членов команды.
В команде таки должна быть какая-то взаимозаменяемость, не? А в этом случае хотя бы прочитать происходящее должны 2-3 других человека. А то у вас bus factor начнёт падать до нуля.
Я не занимаюсь ядерными реакторами, в основном внутренние инструменты.
Ну у меня никогда не было ядерных реакторов, и даже самое серьёзное до него не дотягивало, но вот, грубо говоря, телефонная станция это насколько по-вашему серьёзно?
Тут каждый пункт можно мерджить до выкатывания на ревью следующего.
Нет, пункты 2 и 3 имеют смысл только если целью верхнего уровня является пункт 4. Без него они просто не нужны, и, более того, как именно делается рефакторинг, что именно добавляется - определяется целью и зависит от неё. Другие детали цели (целевой фичи) и может потребоваться другой рефакторинг, может быть нужна другая библиотечная функция или с другим стилем аргументов, и так далее.
Поэтому ревьюер должен видеть полную картину: он должен иметь возможность оценить уже очищенную от зависимостей реализацию целевой фичи, он должен оценить каждое добавление среди зависимостей, и должен оценить их согласование (например, чтобы не было излишних преобразований данных). Ну или он просто вынужден поверить на слово, что автор всё правильно сделал:(
Когда я рассматриваю сложные цепочки, выставленные в Gerrit, я раза два прохожусь туда-обратно, понимая общую картину и под неё уже рассматривая детали. И я не хочу, чтобы я должен был тупо верить тому, что какая-то странность нужна, потому что не могу увидеть, для чего она нужна...
Почему никто не пишет, что у коммита нужно указывать префиксом название ветки.
Потому что "ветка" это артефакт рабочего процесса, а не целевой. Целевой - в первую очередь идентификатор тикета. А ветка при этом может быть какой угодно: например, для тикета ABC-123, который задача "добавить кнопку „прыгать“", может быть ABC-123, может быть devel/ABC-123, может быть devel/jump_button, может быть feature/jump_button_attempt15, может быть local/I_want_to_jump, может быть ещё миллион вариантов. И речь не только про стиль: я могу, например, сделать три несовместимых варианта решения в разных ветках, сравнить их, а на финальные ревью и сабмит подать то, которое больше понравилось.
Идея форсировать наличие названия ветки в [мета]данных коммита, как сделано в Mercurial, тут зажимает разработчика в том, в чём его зажимать совсем не надо.
Так можно сразу найти всё коммиты которые были сделаны по данной ветке
Вот по id тикета и надо искать. Есть стандартная автоматизация для этого.
merge сам по себе очень широкое понятие. Вы уверенны что ревью которые отпочкованы от старой ветки Gerrit именно мерджит, а не ребейзит?
Если вы говорите о самом Gerrit, а не действиях коммиттера: у Gerrit достаточно гибкие настройки. На процесс ревью можно допускать одиночные коммиты, а можно целые ветки. Обычно таки строят допуск одиночными коммитами. Можно допускать мерж-коммиты, а можно - только простые. Можно требовать обязательного merge (тут и далее - в понятиях Git) для сабмита, можно его запрещать.
Обычно говорят о режиме, когда ревью - один коммит; мерж при сабмите необязателен, и делается только если были приняты другие коммиты с момента форка; и разрешается, естественно (это уже не настраивается) при отсутствии текстуальных конфликтов. Так у нас (в том месте, где Gerrit) работает большинство отделов. Все ревью, покоммитно, сами по себе проходят общий CI, это не исключает разных кросс-эффектов, которые могут сломать при отсутствии текстуального конфликта, но на это есть ежедневный прогон через CI автоматом (по крону).
Но есть один отдел, в котором всё наоборот: сабмит разрешён только без мержа (в смысле, что коммит-кандидат проходит фаст-форвардом), но на проверку подаётся ветка, которая может включать в себя мерж. У них своя атмосфера (ц), редкие, но очень крупные изменения. Причём часто они делают это по принципу, когда, например, баг фиксится в версии 52 и затем вся 52-я ветка мержится в 53-ю, и дальше вверх. Я пользу этого метода не понимаю, но лезть к ним не могу.
Если же о действиях коммиттера, то:
1) При типовом описанном выше режиме - правленые версии коммитов должны перепосылаться командой Git из рабочей копии (push с тем же назначением, что при первой высылке). При отправке, чтобы получить иное содержимое при том же Change-Id, они, естественно, должны пройти какой-то ребейз.
2) С относительно недавних пор (лет 5?) веб-интерфейс допускает правку отдельного ревью через веб, в этом случае это ревью и все что за ними по цепочке - получают следующую ревизию коммита. Также можно потребовать там ребейза цепочки на новое состояние целевой ветки; если он не детектит конфликт, разрешает это, иначе надо решать через рабочую копию.
3) Черипики делаются через рабочие копии, и это основной инструмент переноса изменений между ветками. При одинаковом Change-Id можно легко контролировать их перенос между ветками (ну а где приходится делать разные - можно трекать по тикету в сообщении коммита, это ловит цепочки целиком). Я видел также в вебе варианты делать черипик через него, но это было в бете и не знаю, как его можно включить сейчас. Мы так не делаем, потому что в 99% случаев надо вначале прогнать собственные тесты (нужное подмножество) локально, и только по их успеху выставлять в Gerrit, где CI напустит полную проверку - поэтому черипики делаются в рабочих копиях и уже готовыми выставляются в Gerrit.
Поэтому ответ на ваш вопрос - вопрос просто некорректен (недоопределён?), но я попытался максимально широко описать, чтобы включило и ответ на ваш реальный вопрос.
cherry-pick насколько я знаю в UI не используется в обоих системах.
Как уже говорил, я видел кнопки делать его между ветками. Насколько это доступно и рабочее сейчас - у меня нет времени ставить и настраивать свою установку, чтобы проверить это. Но см. выше - есть некоторая поддержка для сделанного извне.
В Геррит я скорее попрошу добавить исправление в первый change.
И я ровно это и описал.
В Gerrit вы просто пушните и создадите новые patchset для каждого ревью. В GitHub вы форспушнете в ту же ветку, чтобы обновить ревью.
Именно это я и написал. А дальше написал, в чём разница в том, как они представляют, что изменилось при обновлении, что и как они позволяют в этом видеть.
Да ГитХаб чудовищно неудобен в плане разбивания ревью на связаные части.
О! Спасибо наконец за подтверждение того, что я пытался объяснить эти несколько последних комментариев.
Но это только первая часть моего тезиса. Вторая - что он, а также как минимум Bitbucket, наверняка специально лишены функциональности для того, чтобы не дезориентировать тех, кто не желает освоить Git, а хочет CVS с плюшками.
К счастью большинство задач можно нарезать вполне нормально на разумные куски и мерджить их не связанными коммитами
Вот тут начинаю сильно сомневаться: в моей практике как раз большинство задач было бы удобно резать в цепочки коммитов, которые имеет смысл читать и понимать (а до сабмита ещё и подправлять) именно цепочками, а не отдельными коммитами. Возможно, влияет целевой домен: у меня это телекоммуникации и системное программирование.
Всё же ваши аргументы, не пользуйтесь сквашем а переходите в Геррит вообще нет такой проблемы, не для всех случаев подходят.
Верно. Для большинства обычных программистов на сейчас, увы, Gerrit слишком сложный как средство. И в команде вынужден ориентироваться на них, а когда начинают работать по принципу "ну сейчас мы ещё в (условном) Бангалоре доберём 20 человек и уложимся в сроки", так суши вёсла, рыбы не будет.
Это понятно. Проблема в том, что новичкам достаточно часто это тупо блокирует понимание, причём чем более потенциально способный новичок, тем вероятнее заклин. По крайней мере я видел такую тенденцию. И вот им надо объяснять, а для этого нужен живой учитель и/или хотя бы хороший доступ в Интернет - всё, чего автор статьи пытается нас лишить.
Мне это напомнило, как ещё в 2000-м году или около того в одной из ещё фидошных эхообластей народ из разных ISP мерялся аптаймом их систем - 100 дней, 200, 300, 400, ура!, а потом пришёл кто-то из Зенона и сказал "а мы сервера по крону перезагружаем, чтобы не накапливалось проблем, и на меряния аптаймом смотрим как на детские игры" :) И как-то все сразу попустились.
9 лет не апгрейдить ОС... ну если это совсем внутренняя система за тремя файрволлами - верю. Но всё равно даже просто проверка, что оно встанет в случае чего - это перезагрузка. А то, что вы можете залить на файлуху новую версию приложения и сказать "прыгай!" и что это проще на бэйрметале чем в контейнере - кто бы спорил, я не буду:)
Чего мне лично катастрофически не хватает в контейнерах — возможности раскатки обновлений без необходимости перезапускать приложение, или, в терминологии эрланга, — hot code upgrade.
Делается. В контейнер можно замапить overlay FS из того, что в постоянной FS контейнера, и примонтированного снаружи файлового дерева. Я это не настраивал, но использовал: у нас таким образом база данных хранилась - если есть файлы текущего состояния, они берутся из внешнего дерева, если нет - нижний слой оверлея хранит стартовое состояние.
Если у вас текущая версия приложения foo-1.8, а надо докатить до foo-1.9, вы в FS (заранее таким образом собранную из слоёв, вот тут надо подготовиться) подкладываете foo-1.9, и внутри контейнера оно мгновенно становится видно. Аналогично relup-конфиг. Дальше отдаёте известным вам образом команду апгрейда. Ну а понравился результат - готовите на следующий старт новую версию контейнера, чтобы 1.9 было по умолчанию.
но я не уловил куда этот стейт сохраняется. Выгружается в другую ноду кластера на другом хосте?
1. Есть понятие "Erlang node". Это один процесс ОС. Внутри него энное количество тредов ОС (для начала считаем, что один на ядро процессора плюс несколько на асинхронные действия), которые гоняют несчётное количество процессов Erlang (не путать с процессами ОС). Именно о переносе процессов Erlang идёт речь.
2. Эрланг-нода может быть: совсем самостоятельной; включённой в родные для эрланга сетевые взаимодействия с обменом данными не через UDP/TCP/etc. персональными связями доверия между двумя нодами; наконец, включённой в кластер, где все друг другу доверяют. Несколько нод на одном экземпляре TCP/IP стека живут под руководством epmd, который умеет указывать, куда приходить за коннектом к конкретной ноде (заданной по имени); epmd нормально держится один на стек, независимо от количества нод. Обсуждаемый вопрос в первую очередь относится к режиму кластера, где тотальное взаимное доверие.
В кластере есть механизм назначения процессам Erlang уникальных в пределах кластера идентификаторов, то есть такой сетевой межнодовый pid у каждого процесса. (Чуть упрощаю детали, тут и раньше, не важно для начального понимания.)
3. Кто и как распределяет эрланг-ноды по экземплярам TCP/IP стека, то есть физическим узлам или контейнерам уровня докера, кубера и прочих - вопрос за пределами обсуждаемого. Считаем, что кто-то есть и он умеет сделать, чтобы (универсально говорим) контейнер мог запустить erl с нужными модулями в FS, командной строкой и параметрами для вхождения в кластер - имя головных нод (epmd ищет по имени), IP (если отличается от отвечаемого в netdb) и кукой (общий пароль) для включения. Дальше нужен полный доступ всех нод со всеми (full mesh). Нормально - одна нода на контейнер, хотя ничто не мешает запустить хоть все в одном контейнере. Зачем? Например, для теста, или когда есть проблема, что какая-то часть процессов должна жить, когда остальные парализованы (бывало у нас, что нода раздувалась до сотен гигабайт и её сносило OOM killerʼом - а другая, выделенная для управления и контроля, оставалась за счёт этого жива).
И вот тут начинаем говорить про то, что процесс иногда можно переместить на другую ноду (считаем без извращений - в другой контейнер). Теперь можно смотреть в статью:)
Зачем перемещать - вопрос интересный. В большинстве случаев таки перенос на ходу не делают. Просто запускается новая версия вместо старой, новая регистрируется в каком-то глобальном справочнике (модуль global или своя замена) и начинает участвовать во взаимодействии, а текущие данные берутся из mnesia (база данных с состоянием на диске) или набираются по ходу. Есть штатные средства миграции (но обычно не один процесс, а "приложение"). Но у них всех специфики и ограничения.
В общем и целом, всё Erlang+OTP интересная и в чём-то очень вкусная разработка. Но и недостатков вагон.
Теперь про это:
Например, для любых приложений можно сделать rolling update версий, или service discovery, или балансировку запросов в приложения, или обновление конфигурации.
Да, собственные механизмы Erlang с механизмом Kubernetes и аналогов плохо совместимы. Они решают сходные задачи, но совсем иначе. С приходом сначала докера, потом кубера оказалось, что подавляющему большинству девопов проще работать в стиле кубера, и собственные механизмы Erlang не нужны. Например, Erlang позволяет обновлять версию почти всего на ходу, без рестарта ноды. Но это мало кем сейчас используется. Можно подсунуть FS с новым кодом в запущенный контейнер, но обычно делают именно на rolling update версии контейнеров. Аналогично с миграцией, проще сделать, что клиент переконнектился, а состояние в БД в отдельном пуле контейнеров, чем переносить один процесс кастомными механизмами.
И второй вопрос: является ли истинно случайным число-функция от нескольких псч? Например, возведём псч1 в степень псч2.
Естественно, подобная функция от нескольких _п_сч будет неслучайной. Вопрос в том, насколько это можно детектировать и вычислить закономерность. Рядом я вкратце расписал основные проблемы. Есть современные генераторы псевдослучайных чисел, которые неотличимы от истинно случайных, и на уровне ОС в основном они используются и предоставляются; например, Fortuna.
Ваш пример с возведением в степень для такого генератора не покажет никаких неожиданных закономерностей, но, что точно изменится - это характер распределения. Обычно такие генераторы на нижнем уровне выдают равномерное распределение, а остальные делаются уже из такого генератора. Возведение в степень не даст равномерное распределение.
Травы не было. (Точнее, была только последние несколько миллионов лет. В терминах Еськова, кайнофит начался раньше кайнозоя примерно на 15 миллионов лет.)
Но формально, можем, да, говорить, что она была самой зелёной, какой только могла быть :)
Упоминание про O(n) и radix sort имеет "так себе" смысл, потому что как в поразрядной, так и в распределяющей сортировке это log N присутствует косвенно, в виде количества битов. Если у вас элементы с ключом в 10 бит, вы сделаете до 10 проходов, а если 20 бит - до 20 проходов, рекурсивно или в цикле - не суть важно. Поэтому у неё тоже O(n log n), а утверждение по O(n) - чисто трюк.
Доказательство теоремы 1 выглядит слишком вольно написанным и не соответствующим математической строгости. Есть ссылка на более формальный вид?
Финальный проход sort() в GCC библиотеке - тут я бы подчеркнул, что эта сортировка вставками никогда не будет перемещать элементы за пределами каждого того отрезка, за которым мы бросили рекурсию из-за малости длины отрезка. Поэтому она не становится квадратичной. Но что мне не совсем нравится в этой реализации, это то, что она будет финально проходиться и по тем участкам, на которых было переключение в heapsort из-за исчерпания бюджета рекурсии - а они уже отсортированы. Цена того скана, конечно, мала, но не ноль. Надеюсь, тут было применено и не один раз сравнение на каких-то больших тестовых данных.
Я честно испугался такое описывать :)
Зависит от конкретной миграции. Обычно привязка к биллингу, а он сильно сложнее самого свича, и вот там бывает много тонкостей. Я в нём не разбираюсь, но по тому, что читаю вскользь, саппортеры обычно в состоянии перевести назад.
Всё это обычно есть. Можно выключить:)
Ну так как работает, по факту, код, то это обычные процедуры наката и рестарта, с поправкой на параллельную работу нескольких дублирующих серверов и инструкции балансеру.
Некоторые и годами жили. Но это уж очень тонкие случаи.
Это не так. Представим себе, что некоторый компонент известен Пете полностью вдоль и поперёк, поскольку он его пять лет дополнял; Вите - так себе, потому что только ревью читал и что-то в памяти отложилось; Денису - читал тикеты и знает основные грабли; Коле - знает, что такое есть и зачем, но чтобы даже понять, как стартовать, ему нужно час читать доку. Такое знание, в большинстве случаев, очень дробно квантуемое.
На одной из работ был такой "многостаночник", который умел типа всё что есть в работе. По факту он про пару десятков подсистем только знал, где и зачем они работают и как найти документацию по ним. Если бы надо было что-то срочно сделать, он ничего бы не смог, только выделить кого-то другого и дать ему вкопаться уже надолго.
Локальные ветки как раз могут называться как левой пятке угодно, лишь бы автору было понятно. На общем сервере стандартов побольше, но у одних может быть bugfix/TT123456, а у других bugfix/too-slow-closing, и это тоже нормально, пока достаточно информации для понимания, о чём вообще речь. А вот сообщение коммита, которое фиксируется в истории, чётко структурируется и формализуется.
А ваш "вопрос", мало того что неверен в предпосылках, так ещё и представляет собой классическое Imago с элементами Jubilare. Не надо так, вы в приличное место пришли.
"Так много" это аж никак не конкретное значение. И я не уверен, что ваша оценка его сколь-нибудь адекватно коррелирует с тем, сколько мы реально тратим.
В команде таки должна быть какая-то взаимозаменяемость, не? А в этом случае хотя бы прочитать происходящее должны 2-3 других человека. А то у вас bus factor начнёт падать до нуля.
Ну у меня никогда не было ядерных реакторов, и даже самое серьёзное до него не дотягивало, но вот, грубо говоря, телефонная станция это насколько по-вашему серьёзно?
Нет, пункты 2 и 3 имеют смысл только если целью верхнего уровня является пункт 4. Без него они просто не нужны, и, более того, как именно делается рефакторинг, что именно добавляется - определяется целью и зависит от неё. Другие детали цели (целевой фичи) и может потребоваться другой рефакторинг, может быть нужна другая библиотечная функция или с другим стилем аргументов, и так далее.
Поэтому ревьюер должен видеть полную картину: он должен иметь возможность оценить уже очищенную от зависимостей реализацию целевой фичи, он должен оценить каждое добавление среди зависимостей, и должен оценить их согласование (например, чтобы не было излишних преобразований данных). Ну или он просто вынужден поверить на слово, что автор всё правильно сделал:(
Когда я рассматриваю сложные цепочки, выставленные в Gerrit, я раза два прохожусь туда-обратно, понимая общую картину и под неё уже рассматривая детали. И я не хочу, чтобы я должен был тупо верить тому, что какая-то странность нужна, потому что не могу увидеть, для чего она нужна...
Потому что "ветка" это артефакт рабочего процесса, а не целевой. Целевой - в первую очередь идентификатор тикета. А ветка при этом может быть какой угодно: например, для тикета ABC-123, который задача "добавить кнопку „прыгать“", может быть ABC-123, может быть devel/ABC-123, может быть devel/jump_button, может быть feature/jump_button_attempt15, может быть local/I_want_to_jump, может быть ещё миллион вариантов. И речь не только про стиль: я могу, например, сделать три несовместимых варианта решения в разных ветках, сравнить их, а на финальные ревью и сабмит подать то, которое больше понравилось.
Идея форсировать наличие названия ветки в [мета]данных коммита, как сделано в Mercurial, тут зажимает разработчика в том, в чём его зажимать совсем не надо.
Вот по id тикета и надо искать. Есть стандартная автоматизация для этого.
Если вы говорите о самом Gerrit, а не действиях коммиттера: у Gerrit достаточно гибкие настройки. На процесс ревью можно допускать одиночные коммиты, а можно целые ветки. Обычно таки строят допуск одиночными коммитами. Можно допускать мерж-коммиты, а можно - только простые. Можно требовать обязательного merge (тут и далее - в понятиях Git) для сабмита, можно его запрещать.
Обычно говорят о режиме, когда ревью - один коммит; мерж при сабмите необязателен, и делается только если были приняты другие коммиты с момента форка; и разрешается, естественно (это уже не настраивается) при отсутствии текстуальных конфликтов. Так у нас (в том месте, где Gerrit) работает большинство отделов. Все ревью, покоммитно, сами по себе проходят общий CI, это не исключает разных кросс-эффектов, которые могут сломать при отсутствии текстуального конфликта, но на это есть ежедневный прогон через CI автоматом (по крону).
Но есть один отдел, в котором всё наоборот: сабмит разрешён только без мержа (в смысле, что коммит-кандидат проходит фаст-форвардом), но на проверку подаётся ветка, которая может включать в себя мерж. У них своя атмосфера (ц), редкие, но очень крупные изменения. Причём часто они делают это по принципу, когда, например, баг фиксится в версии 52 и затем вся 52-я ветка мержится в 53-ю, и дальше вверх. Я пользу этого метода не понимаю, но лезть к ним не могу.
Если же о действиях коммиттера, то:
1) При типовом описанном выше режиме - правленые версии коммитов должны перепосылаться командой Git из рабочей копии (push с тем же назначением, что при первой высылке). При отправке, чтобы получить иное содержимое при том же Change-Id, они, естественно, должны пройти какой-то ребейз.
2) С относительно недавних пор (лет 5?) веб-интерфейс допускает правку отдельного ревью через веб, в этом случае это ревью и все что за ними по цепочке - получают следующую ревизию коммита. Также можно потребовать там ребейза цепочки на новое состояние целевой ветки; если он не детектит конфликт, разрешает это, иначе надо решать через рабочую копию.
3) Черипики делаются через рабочие копии, и это основной инструмент переноса изменений между ветками. При одинаковом Change-Id можно легко контролировать их перенос между ветками (ну а где приходится делать разные - можно трекать по тикету в сообщении коммита, это ловит цепочки целиком). Я видел также в вебе варианты делать черипик через него, но это было в бете и не знаю, как его можно включить сейчас. Мы так не делаем, потому что в 99% случаев надо вначале прогнать собственные тесты (нужное подмножество) локально, и только по их успеху выставлять в Gerrit, где CI напустит полную проверку - поэтому черипики делаются в рабочих копиях и уже готовыми выставляются в Gerrit.
Поэтому ответ на ваш вопрос - вопрос просто некорректен (недоопределён?), но я попытался максимально широко описать, чтобы включило и ответ на ваш реальный вопрос.
Как уже говорил, я видел кнопки делать его между ветками. Насколько это доступно и рабочее сейчас - у меня нет времени ставить и настраивать свою установку, чтобы проверить это. Но см. выше - есть некоторая поддержка для сделанного извне.
И я ровно это и описал.
Именно это я и написал. А дальше написал, в чём разница в том, как они представляют, что изменилось при обновлении, что и как они позволяют в этом видеть.
О! Спасибо наконец за подтверждение того, что я пытался объяснить эти несколько последних комментариев.
Но это только первая часть моего тезиса. Вторая - что он, а также как минимум Bitbucket, наверняка специально лишены функциональности для того, чтобы не дезориентировать тех, кто не желает освоить Git, а хочет CVS с плюшками.
Вот тут начинаю сильно сомневаться: в моей практике как раз большинство задач было бы удобно резать в цепочки коммитов, которые имеет смысл читать и понимать (а до сабмита ещё и подправлять) именно цепочками, а не отдельными коммитами. Возможно, влияет целевой домен: у меня это телекоммуникации и системное программирование.
Верно. Для большинства обычных программистов на сейчас, увы, Gerrit слишком сложный как средство. И в команде вынужден ориентироваться на них, а когда начинают работать по принципу "ну сейчас мы ещё в (условном) Бангалоре доберём 20 человек и уложимся в сроки", так суши вёсла, рыбы не будет.
Весьма вероятно, да. Вы тут чему-то возразили?
А там точно "улучшается"? Может, просто утяжеляется?
Это понятно. Проблема в том, что новичкам достаточно часто это тупо блокирует понимание, причём чем более потенциально способный новичок, тем вероятнее заклин. По крайней мере я видел такую тенденцию. И вот им надо объяснять, а для этого нужен живой учитель и/или хотя бы хороший доступ в Интернет - всё, чего автор статьи пытается нас лишить.
Мне это напомнило, как ещё в 2000-м году или около того в одной из ещё фидошных эхообластей народ из разных ISP мерялся аптаймом их систем - 100 дней, 200, 300, 400, ура!, а потом пришёл кто-то из Зенона и сказал "а мы сервера по крону перезагружаем, чтобы не накапливалось проблем, и на меряния аптаймом смотрим как на детские игры" :) И как-то все сразу попустились.
9 лет не апгрейдить ОС... ну если это совсем внутренняя система за тремя файрволлами - верю. Но всё равно даже просто проверка, что оно встанет в случае чего - это перезагрузка. А то, что вы можете залить на файлуху новую версию приложения и сказать "прыгай!" и что это проще на бэйрметале чем в контейнере - кто бы спорил, я не буду:)
Делается. В контейнер можно замапить overlay FS из того, что в постоянной FS контейнера, и примонтированного снаружи файлового дерева. Я это не настраивал, но использовал: у нас таким образом база данных хранилась - если есть файлы текущего состояния, они берутся из внешнего дерева, если нет - нижний слой оверлея хранит стартовое состояние.
Если у вас текущая версия приложения foo-1.8, а надо докатить до foo-1.9, вы в FS (заранее таким образом собранную из слоёв, вот тут надо подготовиться) подкладываете foo-1.9, и внутри контейнера оно мгновенно становится видно. Аналогично relup-конфиг. Дальше отдаёте известным вам образом команду апгрейда. Ну а понравился результат - готовите на следующий старт новую версию контейнера, чтобы 1.9 было по умолчанию.
1. Есть понятие "Erlang node". Это один процесс ОС. Внутри него энное количество тредов ОС (для начала считаем, что один на ядро процессора плюс несколько на асинхронные действия), которые гоняют несчётное количество процессов Erlang (не путать с процессами ОС). Именно о переносе процессов Erlang идёт речь.
2. Эрланг-нода может быть: совсем самостоятельной; включённой в родные для эрланга сетевые взаимодействия с обменом данными не через UDP/TCP/etc. персональными связями доверия между двумя нодами; наконец, включённой в кластер, где все друг другу доверяют. Несколько нод на одном экземпляре TCP/IP стека живут под руководством epmd, который умеет указывать, куда приходить за коннектом к конкретной ноде (заданной по имени); epmd нормально держится один на стек, независимо от количества нод. Обсуждаемый вопрос в первую очередь относится к режиму кластера, где тотальное взаимное доверие.
В кластере есть механизм назначения процессам Erlang уникальных в пределах кластера идентификаторов, то есть такой сетевой межнодовый pid у каждого процесса. (Чуть упрощаю детали, тут и раньше, не важно для начального понимания.)
3. Кто и как распределяет эрланг-ноды по экземплярам TCP/IP стека, то есть физическим узлам или контейнерам уровня докера, кубера и прочих - вопрос за пределами обсуждаемого. Считаем, что кто-то есть и он умеет сделать, чтобы (универсально говорим) контейнер мог запустить erl с нужными модулями в FS, командной строкой и параметрами для вхождения в кластер - имя головных нод (epmd ищет по имени), IP (если отличается от отвечаемого в netdb) и кукой (общий пароль) для включения. Дальше нужен полный доступ всех нод со всеми (full mesh). Нормально - одна нода на контейнер, хотя ничто не мешает запустить хоть все в одном контейнере. Зачем? Например, для теста, или когда есть проблема, что какая-то часть процессов должна жить, когда остальные парализованы (бывало у нас, что нода раздувалась до сотен гигабайт и её сносило OOM killerʼом - а другая, выделенная для управления и контроля, оставалась за счёт этого жива).
И вот тут начинаем говорить про то, что процесс иногда можно переместить на другую ноду (считаем без извращений - в другой контейнер). Теперь можно смотреть в статью:)
Зачем перемещать - вопрос интересный. В большинстве случаев таки перенос на ходу не делают. Просто запускается новая версия вместо старой, новая регистрируется в каком-то глобальном справочнике (модуль global или своя замена) и начинает участвовать во взаимодействии, а текущие данные берутся из mnesia (база данных с состоянием на диске) или набираются по ходу. Есть штатные средства миграции (но обычно не один процесс, а "приложение"). Но у них всех специфики и ограничения.
В общем и целом, всё Erlang+OTP интересная и в чём-то очень вкусная разработка. Но и недостатков вагон.
Теперь про это:
Да, собственные механизмы Erlang с механизмом Kubernetes и аналогов плохо совместимы. Они решают сходные задачи, но совсем иначе. С приходом сначала докера, потом кубера оказалось, что подавляющему большинству девопов проще работать в стиле кубера, и собственные механизмы Erlang не нужны. Например, Erlang позволяет обновлять версию почти всего на ходу, без рестарта ноды. Но это мало кем сейчас используется. Можно подсунуть FS с новым кодом в запущенный контейнер, но обычно делают именно на rolling update версии контейнеров. Аналогично с миграцией, проще сделать, что клиент переконнектился, а состояние в БД в отдельном пуле контейнеров, чем переносить один процесс кастомными механизмами.
Естественно, подобная функция от нескольких _п_сч будет неслучайной. Вопрос в том, насколько это можно детектировать и вычислить закономерность. Рядом я вкратце расписал основные проблемы. Есть современные генераторы псевдослучайных чисел, которые неотличимы от истинно случайных, и на уровне ОС в основном они используются и предоставляются; например, Fortuna.
Ваш пример с возведением в степень для такого генератора не покажет никаких неожиданных закономерностей, но, что точно изменится - это характер распределения. Обычно такие генераторы на нижнем уровне выдают равномерное распределение, а остальные делаются уже из такого генератора. Возведение в степень не даст равномерное распределение.
Убедительно, спасибо.
Сложно понять применение Венеры. Что можно складывать и принимать при таких давлении и температуре?
Травы не было. (Точнее, была только последние несколько миллионов лет. В терминах Еськова, кайнофит начался раньше кайнозоя примерно на 15 миллионов лет.)
Но формально, можем, да, говорить, что она была самой зелёной, какой только могла быть :)
Но к понятиям merge и cherry-pick эта разница не относится.