Перевод Журнал встречи разработчиков Monero от 2020-03-29

Тема в разделе "Журналы о Monero", создана пользователем Unholy, 11 апр 2020.

  1. Unholy

    Unholy Well-Known Monerano

    Регистрация:
    6 мар 2018
    Сообщения:
    179
    Симпатии:
    13
    Место встречи:

    Freenode | OFTC | Slack | Irc2P | Mattermost
    • #monero-dev
    Время встречи:

    Используйте этот конвертер часового пояса, чтобы преобразовать UTC в ваш часовой пояс.

    Предлагаемые пункты встречи:
    1. Приветствия
    2. Краткий обзор того, что было сделано со времени предыдущей встречи
    3. Предметы текущих исследований для обсуждения
    4. Замечания от разработчиков для обсуждения
    5. D++ и/или CLSAG
    6. Обсуждение v0.15.1.0
    7. Узлы начальной загрузки
    8. Дополнительные пункты встречи
    9. Подтвердите дату / время следующей встречи
    Журнал встречи:

    <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, но еще не прочитал его :p
    <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)
     
  • О нас

    Наш сайт является одним из уникальных мест, где русскоязычное сообщество Monero может свободно общаться на темы, связанные с этой криптовалютой. Мы стараемся публиковать полезные мануалы и статьи (как собственные, так и переводы с английского) о криптовалюте Monero. Если вы хорошо владеете английским (или можете писать собственные статьи/мануалы) и хотите помочь в переводах и общем развитии Monero для русскоязычной аудитории - свяжитесь с одним из администраторов.