При локальном ребейзе обычно автор ребейзит свои патчи. С реальным кодом, такие засады бывают редко, обычно все же возникают конфликты, которые пользователь должен разрулить руками. Частично эта проблема ловится на ревью, частично ее ловят тесты.
PS: на моей памяти подобная штука происходила при накладывании OpenVZ патча, когда там sysctl-ли неуправляемо переезжали в другие подсистемы.
>> Ревью делается для конечного результата, а не для диффов в каждом коммите.
Я описываю случай, когда этот метод не приемлем. Ревью одного логического изменения проще и как результат качественнее. Когда вы работаете над ядром операционной системы, хочется как можно меньше багов пропускать в основной репозиторий. При этом сложность кода достаточно высокая.
У вас в команде принято ревьювить каждый патч или только конечный результат?
Сколько времени может пройти с момента первого показа фичи на ревью, до ее попадания в репозиторий?
Как часто вы смотрите в историю репозитория, чтобы понять зачем были сделаны те или иные изменения?
Кто у вас имеет право мержить фичи в репозиторий и если это делает сам разработчик, то ревьювит ли кто-то изменения которые были сделаны при мерже?
Да, я немного слукавил. Конечно я стараюсь делать микрокомиты, конечно я стараюсь разбивать патчи сразу по идеям, но иногда все равно возникают коммиты, которые приходится сплитить.
Произошла путаница. Разницы между патчем и веткой нет никакой. В ветки патчи должны быть относительно свежего хеда, чтоб не пришлось разруливать конфликты.
Патч ему милее потому что он его просматривает в своем любимом почтовике и если он ему нравится то сразу его заносит в git просто хоткем, а если нет то сразу отписывает свои замечания предложения. А с веткой ему что делать? Просматривать изменения в браузере или себе клонировать? У него сотни, а у некоторых тысячи разработчиков и у каждого свои репозитории, а в них десятки, сотни веток. Мрак…
Да, мейнтейнер хочет получать патчи относительно свежего хеда, чтоб мержить ничего в большинстве случаев не надо было, т е вы перед посылкой должны сделать rebase в своей ветке.
Ну, оно так и происходит. Именно это и описано в статье. Только ревью проходят изменения в виде патчей, но это сути не меняет. А вот если во время ревью находят баг, то любому придется делать ребейз и править патч.
Ребейз нужен вам, держвать патчи которые не прошли ревью поверх всех изменений, который уже попали в основной репозиторий. В основном репозитории никаких ребейзов, никто не делает. Мне кажется я начинаю понимать, о чем вы пытаетесь сказать. Не забудте, что у нас еще есть условие, что в основной репозиторий коммитят только избранные и у них нет времени мержить каждое изменение в отдельности.
По вашему мнению как правильно? Давайте говорить в рамках разработки ядра, когда все разработчики раскиданы по миру. Собрать и что-то обсудить, есть возможность несколько раз в год на конференциях. У людей есть потребность просматривать сотни изменений в день.
В ядре есть люди, кто посылает pull request-ы, но разбивают свои изменения таким же образом. Потому что ревьювить много разных изменений одним куском, очень трудно. А когда они правильно оформлены, разбиты по идеям, отсортированы, то смотреть на них приятнее, понимать быстрее, проверять проще.
Есть разные подходы. В описанном здесь, главная проблема найти мейнтейнера. Если такой энтузиаст нашелся, то подход работает очень эффективно. Коммиты редактируют только разработчики в своих репозиториях. В центральном репозитории ничего не меняется, только добавляется. Мне этот подход нравится тем, что не приходится тратить лишних усилий во время ревью. Меньше трудозатрат, больше вероятность, что ваши патчи посмотрит кто-то еще.
Пока никакой логики по этому поводу у нас нет, но есть общее правило: Если что-то не получается сделать так же как было, то мы требуем разрешение от пользователя сделать как-то по другому. Если вариантов решения (обхода) проблемы несколько, то пользователь может выбрать, какой использовать в конкретном случае.
Процесс дампа и миграции не является деструктивным. Если что-то пойдет не так, то crtools выходит с ошибкой, а процессы продолжают свою работу.
Можете сформулировать проблему более конкретно. Количество потоков приложения может быть больше, чем количество ядер на машине, это достаточно обычное дело. Если посмотреть глубже, то сейчас количество ядер на машине, может меняться во время работы. На пример следующая команда выключает один из «процессоров».
echo 0 > /sys/devices/system/cpu/cpu1/online
Бывают ситуации, когда приложения привязываются к конкретным процессорам из соображения оптимизации. Таких приложения не много и если их отвязать от процессора, то они продолжат работать.
Не врете. Принял и продолжает принимать. К слову большую часть интерфейсов удается сделать универсальными, т е не специфичными для CRIU и их не оборачивают в макрос про который говорил Линус.
Вот тут можно ознакомиться с изменениями в ядре от CRIU команды: criu.org/Commits
Прав в чем? В том, что мы сумасшедшие? Так все мы тут не без греха. Какой нормальный человек будет отвечать вам в третьем часу ночи. А вот в том, что это когда-то заработает, я думаю, уже никто не сомневается, оно уже работает!
Что касается Plesk-а, поверьте мне, команда разработчиков CRIU не написала в нем ни одной строчки кода и он абсолютно чист от наших сумасшедших идей;). Я бы не судил о компании по одному продукту. Да и тот же плеск в последнее время идет на поправку.
Да, мы думаем об этом, но сейчас все ресурсы брошены на «серверные» нужды. Если у вас есть желание, вы можете поресерчить, как дампить иксовые приложения.
На затравку у нас есть небольшое видео, где дампится видеоплеер youtu.be/j4wlYY7lTDw. Правда тут он был запущен в vncserver-е. Таким же образом мы проверяли, что CRIU может дампить Open Office, Gimp. Вот тут есть небольшая инструкция, как это все делать criu.org/VNC
PS: на моей памяти подобная штука происходила при накладывании OpenVZ патча, когда там sysctl-ли неуправляемо переезжали в другие подсистемы.
Я описываю случай, когда этот метод не приемлем. Ревью одного логического изменения проще и как результат качественнее. Когда вы работаете над ядром операционной системы, хочется как можно меньше багов пропускать в основной репозиторий. При этом сложность кода достаточно высокая.
Сколько времени может пройти с момента первого показа фичи на ревью, до ее попадания в репозиторий?
Как часто вы смотрите в историю репозитория, чтобы понять зачем были сделаны те или иные изменения?
Кто у вас имеет право мержить фичи в репозиторий и если это делает сам разработчик, то ревьювит ли кто-то изменения которые были сделаны при мерже?
Патч ему милее потому что он его просматривает в своем любимом почтовике и если он ему нравится то сразу его заносит в git просто хоткем, а если нет то сразу отписывает свои замечания предложения. А с веткой ему что делать? Просматривать изменения в браузере или себе клонировать? У него сотни, а у некоторых тысячи разработчиков и у каждого свои репозитории, а в них десятки, сотни веток. Мрак…
Процесс дампа и миграции не является деструктивным. Если что-то пойдет не так, то crtools выходит с ошибкой, а процессы продолжают свою работу.
echo 0 > /sys/devices/system/cpu/cpu1/online
Бывают ситуации, когда приложения привязываются к конкретным процессорам из соображения оптимизации. Таких приложения не много и если их отвязать от процессора, то они продолжат работать.
Вот тут можно ознакомиться с изменениями в ядре от CRIU команды: criu.org/Commits
Что касается Plesk-а, поверьте мне, команда разработчиков CRIU не написала в нем ни одной строчки кода и он абсолютно чист от наших сумасшедших идей;). Я бы не судил о компании по одному продукту. Да и тот же плеск в последнее время идет на поправку.
На затравку у нас есть небольшое видео, где дампится видеоплеер youtu.be/j4wlYY7lTDw. Правда тут он был запущен в vncserver-е. Таким же образом мы проверяли, что CRIU может дампить Open Office, Gimp. Вот тут есть небольшая инструкция, как это все делать criu.org/VNC