Место встречи: Freenode | OFTC | Slack | Irc2P | Mattermost #monero-dev Время встречи: Используйте этот конвертер часового пояса, чтобы преобразовать UTC в ваш часовой пояс. Предлагаемые пункты встречи: Приветствия Краткий обзор того, что было сделано со времени предыдущей встречи Предметы текущих исследований для обсуждения Замечания от разработчиков для обсуждения D++ и/или CLSAG Обсуждение v0.15.1.0 Узлы начальной загрузки Дополнительные пункты встречи Подтвердите дату / время следующей встречи Журнал встречи: <rehrar> 1. Приветствия <binaryFate> привет! <rbrunner> Hi <rehrar> https://github.com/monero-project/meta/issues/449 <rehrar> повестка текущей встречи ^ <sgp_> Привет <ErCiccione> Hi <vtnerd> hi <dEBRUYNE> я здесь <rehrar> 2. Краткий обзор того, что было сделано со времени предыдущей встречи <kinghat[m]> Эй, самое сексуальное сообщество, хэй <rehrar> этот пункт только для обновлений, дискуссия в ключе исследований и пунктов разработки будет дальше <vtnerd> я могу начать? <rehrar> vtnerd, да, конечно <yugyug> Привет всем! Это моя первая встреча разработчиков <vtnerd> в чем разница между обновлениями и текущими разработками? <sgp_> Повестка? <vtnerd> ладно, я начну, и если что, вы можете остановить меня <rehrar> vtnerd: этот пункт предназначен, для завершенной работы. Мы можем обсудить проблемы или вопросы чуть позже. <vtnerd> Я опубликовал проблему на github, которая объясняет мои попытки улучшить сериализацию zmq, в частности, для perf и нескольких других форматов. Это можно отнести к epee, что ускорит прохождение p2p-трафика (синхронизация и т. д.) <vtnerd> там очень много макросов и кода на c++, и я боюсь, что мне придется прибегнуть к помощи других участников <vtnerd> я также доделал код, который заставляет fastjson писать прямо в `byte_slice`, чтобы исключить последнее оставшееся копирование на выходе zmq-json <vtnerd> и теперь жду его рассмотрения и отзывов, но я, скорее всего, просто опубликую его в ближайшее время, хоть там и есть какие-то блокировки * hyc большой фанат zero-copy <vtnerd> это можно использовать для замены std::stringstream при двоичном выходе из epee, а также при выводе json (что определенно быстрее). <vtnerd> и еще — работа над zmq-pub закончена и требует проведения модульных тестов. Теперь поддерживаются такие события, как txpool и block <vtnerd> https://www.github.com/vtnerd/monero/tree/feature/zmq-pub <vtnerd> https://github.com/vtnerd/monero/tree/feature/zmq_pub <vtnerd> и еще… Нет, точно, теперь все… Я не беру в расчет работу по сериализации других второстепенных вещей <vtnerd> конец <vtnerd> https://github.com/monero-project/monero/compare/master...vtnerd:feature/zmq_pub?expand=1 это так, вдруг кто-то заинтересуется zmq <rehrar> отлично! спасибо, vtnerd! у кого-нибудь еще есть обновление? <rehrar> хорошо, давайте перейдем к пункту 3. Предметы текущих исследований для обсуждения <rehrar> sarang: Есть ли что-то, что вы хотели обсудить или, как вариант, получить обратную связь в ключе какой-то работы? <sarang> только работа над CLSAG, который, как я вижу, имеет отдельный пункт в повестки дня <rehrar> да, вероятно, что пункты 5 и 6, будут объединены <sarang> Triptych и Triptych-2 обзавелись своими препринтами <sarang> в настоящее время я работаю над математикой для Multisig и join-type <sarang> было обсуждение смягчения последствий атаки Януса, данное смягчение может незначительно увеличить размер транзакций, и я поддерживаю эту идею, но она, кажется, не набирает обороты <sarang> одно из предположений смягчения должно обеспечить лучшую однородность для субадресов <sarang> в этой реализации каждый выход имеет свой собственный публичный ключ транзакции и «глобальный» публичный ключ <selsta> насколько увеличится размер транзакций? <sarang> порядка 32-64 байт на транзакцию <sarang> но стоит учитывать, что CLSAG предварительно уменьшит этот размер на 600 байт <rehrar> что вы подразумеваете под однородностью? <sarang> и даст возможность отслеживания попыток данного вида атаки <sarang> обратите внимание, что это не подразумевает дополнительного времени проверки для *всей* сети (только анализ определенного ряда значений) <sgp_> Я думаю, что преимущества однородности для субадреса очень недооценены <sarang> только получатель средств может инициировать атаку Януса - Shizlet9 вышел (Причина: Бездействие в течение 256 секунд) <selsta> это подразумевает, что субадреса будут так же безопасны, как отдельные кошельки? <sarang> а попытка вычисления возможности атаки весьма тривиальна <sarang> с точки зрения атаки Януса, да <sarang> получатели смогут обнаружить попытки данной атаки <rehrar> в какой конкретно момент...? <sarang> кошельки смогут получить / потратить средства либо отметить транзакцию как «не предназначенная для меня» <sarang> (последний вариант безопаснее) <binaryFate> "было обсуждение смягчения последствий атаки Януса"<-- где можно прочитать эти дискуссии? <sarang> разговор состоялся в канале Исследовательской лаборатории, а также есть соответствующий вопросов в нашем репозитории <sarang> можно ещё раз поднять этот вопрос на предстоящей встрече Исследовательской лаборатории <rehrar> Возможно, стоит сделать какую-то выжимку? По типу: описание, плюсы / минусы, за / против и т.д. <rehrar> это было бы очень полезно. Но я не прошу делать вас это, возможно, вы можете поручить это кому-то <sarang> Можно посмотреть здесь: https://github.com/monero-project/research-lab/issues/71 и здесь https://github.com/monero-project/research-lab/issues/62 <rehrar> Хорошо, что-нибудь еще на эту тему? Если вопросов или предложений нет, двигаемся дальше <sarang> мне было бы интересно узнать, поддерживают ли люди такое увеличение размера транзакций <sarang> если нет, мы можем отказаться от этой меры противодействия и обеспечить лучшее понимание у пользователей возможных ограничений подадресов <sarang> сделать целую компанию по повышению грамотности пользователей <rehrar> никогда не переводите на пользователей то, что можно сделать с помощью программного обеспечения <sarang> когда впервые поднимался этот вопрос, у нас не хватало поддержки со стороны разработчиков <rbrunner> я бы выбрал вариант на 64 байта <rehrar> Я говорю да только из-за UX 101 <sarang> я тоже думаю, что это лучшая альтернатива из предложенных <sarang> Обратите внимание, что это не должно быть консенсусом <UkoeHB_> думаю, что должно быть какое-то предупреждение со стороны кошелька. А вообще, мне интересно посмотреть на эту реализацию <sgp_> Я тоже думаю, что нужно добавить такую функцию, зачастую люди обращают внимание на предупреждения их кошелька <sarang> UkoeHB_: злоумышленник может легко создать такую транзакцию <UkoeHB_> но, скорее всего, другие кошельки не смогут правильно реализовать это предупреждение <sarang> а решать, что делать дальше, будет прерогатива кошелька <rehrar> я думаю, что необходимо достичь консенсуса, поскольку подадреса являются частью нашей экосистемы и должны остаться <sarang> хочу напомнить, в CLSAG размер транзакций становятся намного меньше, чем есть сейчас <rehrar> Это довольно идиотское доказательство, разве нет? <sarang> даже с учетом этой надстройки время проверки станет меньше <UkoeHB_> идея консенсуса сомнительна, так как он не поддается проверке <sarang> UkoeHB_: Я имею в виду консенсус с точки зрения наличия ожидаемого количества публичных ключей <UkoeHB_> все, что вам может потребоваться, это несколько дополнительных байтов в транзакции <sarang> да <sarang> В любом случае, пожалуйста, внимательно рассмотрите эту идею, взвесьте все «за» и «против» <rehrar> мы можем дополнительно обсудить это на следующем собрании MRL. <rehrar> Давайте двигаться дальше. <UkoeHB_> Я думаю, что нормально требовать принятие этого решения, поскольку информация ECDH уже является прецедентом <rehrar> я собираюсь объединить пункты 4, 5 и 6 <rehrar> Замечания от разработчиков для обсуждения, D++ и/или CLSAG, Обсуждение v0.15.1.0 <rehrar> Давайте начнем с конца. v0.15.1.0. Когда? Как? Зачем? <selsta> vtnerd: supercop будет готов к объединению после аудита? <vtnerd> да <vtnerd> он может быть использован в Monero или любом другом проекте, или, как вариант, собран и установлен в качестве отдельной библиотеки <selsta> интеграция с кошельком уже готова? <selsta> или она не потребуется? <vtnerd> да, но его отметили тегом «не объединять», потому что сначала требуется добавление supercop, и только затем нужно будет добавлять проверку <selsta> отлично, я хотел бы увидеть Dandelion и supercop в v0.15.1.0 <selsta> ты думаешь, что это реально? <vtnerd> знаете, это, вероятно, еще никогда не упоминалось на встречах -dev, но я хотел бы затронуть одну тему <vtnerd> supercop потребует довольно досконального аудита, что может задержать его интеграцию <binaryFate> у вас есть ссылка на PR? <vtnerd> https://github.com/monero-project/monero/pull/6337 <vtnerd> https://www.github.com/monero-project/supercop <vtnerd> там всего один PR <binaryFate> так будет легче для общего понимания и того, что мы вообще сейчас обсуждаем <binaryFate> спасибо <selsta> Я на мобильном телефоне, поэтому не могу публиковать ссылки <vtnerd> он ускоряет сканирование кошелька на x86-64, используя код от Даниеля Бернштейна и др. <rbrunner> это что-то довольно старое? <vtnerd> код ed25519 нельзя было использовать напрямую, потребовались его модификация для работы со специфичными для monero вещами, в этом и заключается сложность обзора (возможность взлома и криптографическая реализация C) <vtnerd> да, весьма <selsta> у кого-то есть навыки ASM? <selsta> или мы должны пересмотреть ASM? <UkoeHB_> Кто-нибудь за пределами группы разработчиков monero проявил интерес к рассмотрению PR? <vtnerd> ASM очень похож на существующий код supercop. Единственное, что вы можете увидеть разницу между существующим "базовым" кодом и моими новыми дополнениями <selsta> отлично, думаю, мы сможем что-то придумать с рецензией <vtnerd> но вам все равно потребуется знать ASM, чтобы понять, что он делает, почему и зачем <vtnerd> да, если у вас уже есть опыт с supercop amd64 ASM, то это будет намного проще, особенно, чем полный аудит с нуля <vtnerd> мы с moo обсуждали файлы, на которые нужно уделить особое внимание ( журнал беседы есть в PR) <rbrunner> возможно, есть какой-то форк? Вы не интересовались этим? <rbrunner> и он поможет нам в планируемом обзоре <selsta> Я думаю, что Mooo был заинтересован в рассмотрении этого, но я не хочу говорить за него <fuwa> смысл C / C++ не в том, чтобы избежать ASM? <selsta> мы хотим, чтобы ASM ускорил сканирование кошелька <fuwa> почему бы не написать все в ASM? <vtnerd> проблемы с библиотеками <vtnerd> весьма трудно написать код perf + константа времени <rbrunner> думаю, что это хороший и разумный вариант использования ASM <fuwa> я не куплю это <binaryFate> Вы связались с Бернштейном и соавторами для обзора? <vtnerd> ASM, который я написал, сохраняет код постоянным к параметру времени, тогда как некоторые другие реализации отбросили эту функцию при форке кода supercop <fuwa> ведь это настоящее горлышко бутылки <fuwa> *кивает головой* <vtnerd> fuwa, писать код с постоянным параметром времени на C сложнее, чем вы думаете <fuwa> Я видел RP, но еще не прочитал его <rbrunner> это будет не только быстрее, но и лучше в отношении времени? <vtnerd> если вы отбросите постоянный параметр временем, криптографический код будет намного быстрее <fuwa> он очень быстро работает даже на моем телефоне <vtnerd> вероятно, что Саранг мог бы прокомментировать это в отношении переменной ECDH <vtnerd> Да, это так <vtnerd> посмотрите на значения perf - Shizlet8 подключился <sarang> Есть много мест, где мы используем скалярные операции vartime <vtnerd> это дополнительная функция кошелька, которую по умолчанию можно отключить <vtnerd> но как при этом изменится поведение кошелька при сканировании ключей <vtnerd> всё упирается во время проверки? <sarang> в основном, да <hyc> как насчет использования ctgrind? https://github.com/agl/ctgrind <vtnerd> не знаю, мы не рассматривали такой вариант <moneromooo> я совсем забыл об этом PR, постараюсь посмотреть его в ближайшее время <rehrar> итак, значит, мы рассматриваем возможность аудита в ближайшие пару месяцев? <selsta> думаю, что v0.15.1.0 будет готов в ближайший месяц <selsta> было бы лучше вначале реализовать только Dandelion, а затем supercop + CLSAG <rehrar> Давайте очень быстро обсудим CLSAG <rehrar> sarang: можете ли вы прокомментировать, насколько он готов к внедрению как на стороне реализации кода, так и на уровне предстоящего аудита? <vtnerd> что касается чисел перфорирования, то сканирование всего блокчейна заняло порядка ~ 46 минут на Mac mini 2014 года <binaryFate> кто-нибудь обращался к Бернштейну и / или соавторам за рецензией? * sarang ждёт скорейшего окончания этой темы <selsta> Вы имеете в виду возможность найма Бернштейна для обзора? <binaryFate> я имею в виду возможность попросить провести *дружескую* проверку у одного из авторов или, может быть, у их ученика, но вариант с наймом тоже стоит рассмотреть <binaryFate> год назад Д. Бернштейн выступал на семинаре Monero в ключе CCC, посвященной конфиденциальности и прочим вещам <selsta> это отличный вариант, кто-то может связаться с ним? <binaryFate> просто дайте им знать, над чем мы работаем, и что мы ищем аудиторов, посмотрим, к чему это приведет <selsta> vtnerd: вы видели, как moneromooo делает выборку транзакций для PR? <moneromooo> это все демон на стороне кошелька, vtnerd <selsta> должно ли это привести к дополнительному ускорению? <selsta> особенно если будет работать вместе? <moneromooo> Да, если вы запускаете их на одной машине. <selsta> ok <moneromooo> как минимум это уменьшит нагрузку. Но, скорее всего, один из них станет узким местом, поэтому другой будет вынужден ждать <moneromooo> вероятно, что узким местом будет кошелек <moneromooo> демон будет обрабатывать запрос, но в то же время он будет дольше ждать следующий запрос <selsta> rehrar: может быть, вам стоит добавить примечание в повестку дня для Бернштейна? Чтобы мы не забыли об этом <rehrar> Уже сделано. <rehrar> Хорошо. Готовы обсудить CLSAG? <sarang> конечно <sarang> я весьма долго ждал ответа от Шурэ <sarang> недавно он дал мне разрешение внести изменения и опубликовать документ без его дальнейшего участия <sarang> в ближайшие пару дней я закончу правки <sarang> оптимизированный код CLSAG был объединен с перебазированной веткой moneromooo `clsag` <sarang> в моей локальной копии этой ветки есть новые обновления с поддержкой Trezor / Ledger <sarang> сейчас я работаю над координацией, Trezor / Ledger будут готовы приступить к работе сразу после нашей отмашки <binaryFate> уменьшение на 600 байт уже включено в этой ветке, или еще предполагается ее дальнейшие изменение? <sarang> уменьшение на 600 байт (для 2-2 транзакций) не изменялось на протяжении всей разработки CLSAG <sarang> Так что да, транзакция, сгенерированная из этой ветви, будет содержать ожидаемое уменьшение размера по сравнению с MLSAG <sarang> следовательно, вы увидите увеличение скорости проверки <sarang> которая тоже претерпела изменения <binaryFate> это превосходно <sarang> текущее ускорение MLSAG-> CLSAG составляет порядка 16% <sarang> я не могу комментировать, как идут дела с разработкой у trezor/ledger, но препринт будет размещён в архиве IACR через несколько дней <sarang> изменения в конструкции минимальны и могут быть объединены с веткой `clsag` в любой момент <rehrar> я понимаю, что лучше не включать CLSAG в текущий релиз, пока Ledger / Trezor не закончат свои интеграции, да? Это может стать настоящей проблемой для всех пользователей Ledger / Trezor <selsta> да <sarang> все верно <sarang> тем не менее я активно веду с ними переговоры <sarang> они используют ветку `clsag` для своей текущей работы <rehrar> Так что если selsta хочет выпустить 0.15.1.0 в следующем месяце, то, может быть, нам действительно нужно перенести CLSAG? И еще, когда нужно начинать планировать хардфорк? Через два месяца? Три? <sarang> Да, нам не стоит спешить <sarang> я имею в виду обновление <selsta> CLSAG не будет включен в v0.15.1.0 <selsta> CLSAG будет добавлен в v0.16.0.0 с последующим хардфорком <rehrar> понял <rehrar> извините <sarang> обзор ветки `clsag` от moneromooo будет приветствоваться <sarang> и / или дополнительный коммит в моей ветке `clsag-device` (которая добавляет привязку к конкретному устройству) <rehrar> ориентировочные сроки для v0.16? Май или июнь? Что думаете? <selsta> думаю, что мы можем подумать о дате, когда узнаем, сколько времени займет аудит <sarang> если мы выберем Teserakt для аудита, они обещают закрыть этот вопрос в очень короткий срок <sarang> до начала работы других аудиторов <rehrar> уже есть потенциальные аудиторы? Возможно, их стоит включить в повестку дня <sarang> рецензентам потребуется препринт и готовый код <sarang> в данный момент sgp_ координирует работу в ключе аудита <rehrar> окей, спасибо <rehrar> что-нибудь еще на эту тему? <sarang> я буду рад оказать любую поддержку в качестве независимого эксперта <sarang> (думаю, что это хорошая практика) <binaryFate> Может быть, нам нужно задать временную шкалу или какие-то временные рамки для ledger/trezor? В любом случае они должны всё понимать и как-то распланировать своё время <sarang> binaryFate: я обратился к ним несколько дней назад, чтобы они рассмотрели ожидаемые изменения <sarang> они сказали, что изменения будут простыми и относительно минимальными <binaryFate> звучит обнадеживающе <sarang> я буду следить за их прогрессом в этом вопросе <selsta> Я думаю, что обзоры кода будут особенно полезны, и мы успеем хорошо поработать в ключе v0.15.1.0. Нам также потребуется немного времени для тестирования <sarang> есть ли какие-либо нерешенные проблемы с CI в текущей версией? <selsta> нет <sarang> отлично <selsta> вчера компиляция не удалась, но теперь я все исправил <rbrunner> ветки отстают в актуальности от текущего PR? <selsta> да <rbrunner> отлично <rehrar> великолепно! Мы немного задержались, и я предлагаю перейти к следующей теме <ErCiccione> я думаю о возможности организовать хакатон для 0.15.1 и, как вариант, позволить людям найти возможные ошибки. Как вариант, открыть CCS <rehrar> binaryFate: ваша остановка, вы просили добавить «узлы начальной загрузки». Поведайте нам, что скрывается под этим пунктом <binaryFate> Все весьма просто — у нас есть довольно непонятная ситуация с узлами начальной загрузки, я хотел бы поделиться ею с вами <selsta> mooo PRed узел <rbrunner> Что? уже в основной сети? <binaryFate> Та же самая ситуация произошла 2 месяца назад, мы зафиксировали проблему и развернули 2 узла (благодаря fluffypony), но в итоге мы снова вернулись к 1 узлу <binaryFate> да, уже в основной <binaryFate> вот такие дела <binaryFate> вы можете найти все узлы начальной загрузки здесь: https://community.xmr.to/xmr-seed-nodes <rbrunner> Я догадывался, что для testnet вообще не существует начальных узлов, только для mainnet .. <binaryFate> на самом деле в testnet / stagenet было по 3 узла, когда для mainnet был только один... <rbrunner> клёво <selsta> Меня интересуют требования к трафику <binaryFate> Я полагаю, что из 3-х узлов одним управляет Snipa, а 2 другими fluffypony. А вот откуда появился четвертый, мы не знаем - derpy_bridge вышел (Удаленный хост закрыл подключение) - derpy_bridge вход <binaryFate> в коде есть домены, которые будут использованы для подключения к начальным узлам, но почему-то ни у одного из них нет записи DNS <rbrunner> теперь всё понятно <binaryFate> мы очень долго откладывали эту проблему… как мы можем улучшить это в следующем выпуске? <binaryFate> я бы посоветовал добавить от 3 до 5 доверенных узлов и, возможно, еще десяток начальных узлов от доверенных лиц <binaryFate> и удалить все существующие узлы, о которых мы ничего не знаем <yugyug> Я был бы весьма заинтересован в запуске такого узла <moneromooo> кто-то в вопросе #3425 был заинтересован в запуске такого начального узла. Только это было год назад... <binaryFate> я ручаюсь за yugyug, он мой коллега <rehrar> тогда нам нужно найти этих добровольцев… Как вариант, выпустить PSA материал и отобрать откликнувшихся добровольцев? <yugyug> наверное, нужно определить ряд требований для таких узлов <moneromooo> fluffypony: как обстоят дела с этим вопросом? <rbrunner> думаю, что с ограничением не должно возникнуть проблем <selsta> да, думаю, что простая VPS за $10 (с трафиком ~2 ТБ) вполне подойдет, на таких условиях будет легко найти добровольцев <ErCiccione> selsta: хватит ли на таких VPS места для хранения блокчейна? <selsta> да, но только обрезанного блокчейна <binaryFate> сеть ожидает от таких узлов, что они смогут предоставить актуальный список пиров, не обязательно, что синхронизация будет выполнена напрямую через них <yugyug> основная роль начального узла заключается в распределении новых пиров по сети <kinghat[m]> за 6$ вы сможете арендовать VPS со 100ГБ SSD и 20ТБ трафика <kinghat[m]> на том же самом hetzner* <ErCiccione> В таком случае, да, это не должно быть большой проблемой <kinghat[m]> и я подтверждаю, что они не против работы i2p / xmr узлов <selsta> kinghat[m]: Hetzner очень хороший провайдер, но мы должны распределить узлы по всей сети <ErCiccione> они принимают к оплате btc или monero? <rbrunner> не уверен <kinghat[m]> я так не думаю <ErCiccione> эххх <rehrar> хорошо, binaryFate, что-нибудь еще по этому пункту? <selsta> каждый, кто хочет запустить такой узел, должен открыть PR и добавив свой узел <binaryFate> наши следующие шаги? Подготовить PSA документ и сделать соответствующий пост в сообществе * kinghat[m] загрузил изображение: image.png (14KB)<https://matrix.org/_matrix/media/r0/download/matrix.org/hfuCSSdvVEpwRWIFBJqEfzsf> <binaryFate> selsta, да, нужно будет отобрать порядка 50 таких узлов <rehrar> selsta: угу, как вариант, можно будет отобрать их прямо через PR <selsta> да <binaryFate> возможно, пометить их как WIP <selsta> все моменты и появившиеся вопросы можно будет обсудить прямо в PR <selsta> rehrar: Я хотел бы добавить еще один пункт встречи: возвращение всех репозиториев на Github <rehrar> да, продолжайте <rehrar> selsta: тогда сейчас ваша остановка <selsta> кто-нибудь против? <selsta> мы уже попробовали gitlab и столкнулись с некоторыми ограничениями <sarang> что насчет раздела CCS? <rbrunner> Все или только веб-сайт? <sarang> Разве это не потребует каких-то специфических для GitLab действий? <selsta> как вариант, оставить его в качестве резервной копии репозитория и вернуться на Github <selsta> sarang: xiphon обещал сделать правки для github <ErCiccione> ведь достаточно просто вытащить серверную часть css из github <sarang> комментарии от сообщества работают как коммиты <sarang> вероятно, что эта часть не будет работать <rehrar> sarang: Xiphon и я запустили ccs для Zcoin, и у них все работает на Github, но с небольшими доработками и патчами <rehrar> в теории переключение не должно быть проблемой <sarang> rehrar: какое преимущество от перемещения CCS на GitHub? <kinghat[m]> можно ли без проблем переключиться обратно на gitlab, работающий как зеркало, если с github будут проблемы? <sarang> CI не важен для репозитория CCS <selsta> как по мне, лучше, чтобы все было в одном месте <binaryFate> есть какие-то нерешенные проблемы или ограничения? <rehrar> согласен, но будет весьма странно, если ccs будет в другом месте <selsta> а прошлые комментарии будет доступны на старом адресе <sarang> был какой-то один нерешенный вопрос с github <selsta> https://github.com/monero-project/meta/issues/236 <sarang> rehrar: значит, вы хотите отказаться от зеркала на gitlab? <selsta> (2 последних комментария) <selsta> экземпляр gitlab останется как зеркало <ErCiccione> binaryfate: я попытался сделать резюме: https://github.com/monero-project/meta/issues/236#issuecomment-605023567 <moneromooo> зеркалирование работает немного по-другому <selsta> нужно просто сделать скрипт для зеркалирования репозиториев <moneromooo> (как вариант, переносить ручными скриптами необходимые изменения) <sarang> Было бы неплохо обзавестись такими вещи, как 2FA и доступ по SSH <sarang> (это огромный недостаток gitlab) <ErCiccione> и рабочий CI для PR <moneromooo> проблема с ssh - это не проблема Gitlab, а ошибка CloudFlare. <selsta> единственное, на что мы должны обратить внимание, это регулярное резервное копирование всех обсуждений <selsta> я не знаю, есть ли у Github такая возможность, или нам придется использовать сторонние службы <ErCiccione> это регулярное резервное копирование всех обсуждений <- да, мы должны рассмотреть все варианты, если нам придется вернуться обратно на gitlab <moneromooo> ручное зеркалирование? используйте git pull. <selsta> особенно вопросы / pr <sarang> moneromooo: в отношении SSH - да, но у нас его нет и на github :/ <moneromooo> Да, действительно - rottensox переименовался в rottenbrrrrrrr <sarang> GitHub также помогает устранить некоторые распространенные проблемы <sarang> связанные с форками, вашими коммитами и т.д. <binaryFate> можно попробовать https://github.com/marketplace/backhub - fuwa переименовался в fuwa-prpr <selsta> binaryFate: они предлагают бесплатный сервис для программного обеспечения с открытым исходным кодом <binaryFate> они используют github API и, похоже, могут получать доступ к метаданным репозиториев <selsta> да, и 12$ не такая большая сумма <moneromooo> да, в их api есть такой функционал <binaryFate> как насчет microsoft? <sarang> текущие комментарии к выпуску сосредоточены на обсуждении проблем с gitlab... <sarang> относительно учетных записей, CI и т. д. <rbrunner> у нас нет никого, кто бы высказывался против <sarang> MS проделал хорошую работу и старается не вмешиваться, насколько это возможно <selsta> не думаю, что Github стал хуже с момента приобретения их MS <sarang> ^ <moneromooo> это всегда так кажется, особенно до того момента пока они не начинают жестко тебя насиловать <ErCiccione> sarang: это все еще бомба замедленного действия... Нам нужно иметь собственную платформу, но gitlab, как оказалось, весьма специфичная среда <sarang> согласен <selsta> если в будущем будут проблемы, мы всегда можем вернуться назад <sarang> независимый хостинг всегда приведет к тому, что на этой платформе будет меньше разработчиков по сравнению с GitHub <sarang> это не проблема GitLab, а проблема людей <rbrunner> значит, что на данный момент никто не голосует за то, чтобы остаться на gitlab <ErCiccione> sarang: я думаю, проблема в том, что все основные репозитории уже и так находятся на github <sarang> не знаю, хорошо это или плохо, но GitHub имеет отличный CI <moneromooo> и, используя monero, а не bitcoin, linux, вместо windows, мы заставляем людей меняться <moneromooo> но я подозреваю, что некоторые здесь используют windows и bitcoin, несмотря ни на что <ErCiccione> я вижу проблему отсутствия людей на gitlab, больше похожую на проблему, вызванную расколом, чем на проблему с самой платформой <selsta> люди должны самостоятельно следить за изменениями в репозитории <selsta> Кто-нибудь здесь против миграции на Github? - gethh подключился <sarang> с сохранением существующего экземпляра? <rehrar> мне всё равно <sarang> (особенно в разрезе CCS ) <moneromooo> Я согласен с тем, что CCS, вероятно, лучше всего оставить на gitlab <binaryFate> способность привлекать новых участников на данный момент должна быть приоритетной задачей, особенно в эти неспокойные времена <kinghat[m]> не думаю, что были случаи, что кто-то способствовал развитию monero, когда случайно наткнулся на него во время серфинга github... <rehrar> Мне нравится, что людям приходится проходить *дополнительный отбор* перед созданием CCS <moneromooo> не уверен <rehrar> Это первый шаг для людей, запрашивающих финансирование <selsta> Меня не волнует CCS, только репозиторий веб-сайта <ErCiccione> Я думаю, что было бы лучше переместить все, но я понимаю, почему имеет смысл оставить CSS на Gitlab <rehrar> тогда начнем с сайта <rehrar> и как следующий шаг — рассмотреть возможность переноса CCS <selsta> звучит логично <sarang> +1 <rehrar> Отлично! Что-нибудь еще? <sarang> o_0 <rehrar> Меня устраивают эти условия <dEBRUYNE> Мы уже обсуждали аудит CLSAG? <rehrar> Всем спасибо! До скорых встреч! Источник: Monero Dev Meeting: March 29th, 2020, 17:00 UTC #449 Перевод: Unholy (@Unholy) Редактирование: Mr. Pickles (@v1docq47) Коррекция: Kukima (@Kukima)
