Журнал встречи Разработчиков Monero от 2018-01-14 Опубликовано: dEBRUYNE / fluffypony 14 Января 2018 Журнал <rehrar> https://github.com/monero-project/meta/issues/157 <rehrar> Повестка дня <rehrar> Мы вроде-бы всех поприветствовали, но, если кто-то присутствует ещё — просто напишите в чат «Привет» <gingeropolous> Привет <jtgrassie> Привет! <pigeons> Привет! <Maxithi> Привет <pebx> Привет <ferretinjapan> Привет <binaryFate> Привет <rehrar> отлично, давайте приступим <rehrar> 2. Быстро пройдёмся по тому, что было сделано с предыдущего собрания <rehrar> У кого-нибудь есть что-то интересное, чем он хочет поделится с нами после нашей последней встречи месяц назад? <rehrar> Может кто-то получил забавный подарок на праздники? <Maxithi> получил 24 коммита 4 дня назад. <Maxithi> В основном - ничего особенного. Можете немного поддержать cslashm и hist с первым Ledger PR. <endogenic> мы добились небольших успехов с apple, fyi …подтвердили, что на их стороне была просто путаница с человеком, и мы наконец всё выяснили. <rehrar> это довольно интересная информация Maxithi <endogenic> нужно будет представить ещё кое-какую часть документации <hyc> ничего выдающегося, что-бы это можно было сообщить прямо здесь <sgp> привет <rehrar> endogenic: мужик, мы уже хотели-бы каких то вестей, они должны быть захватывающими! <rehrar> ArticMine: хотите немного поговорить о встрече в Киеве? <endogenic> rehrar: неприменно, мне просто нужно немного сгруппировать всю информацию <ArticMine> Коненчо, но на самом деле это выбивается за рамки нашей встречи разработчиков <rehrar> endogenic: просто и кратко в паре предложений <vtnerd> после обсуждения с luigi1111, я должен предложить оптимизацию для сканирования кошелька mymonero, хотите протестировать реальные цифры по сравнению со стандартным кошельком? <vtnerd> Оу, извините, ArticMine <rehrar> нет, продолжайте, vtnerd не стесняйтесь, дайте нам знать даже о самом незначительном изменение! <vtnerd> хорошо, эта оптимизция отдельно от трудов в ASM monero-project/supercop, таким образом это работает со стандартным ref10 <vtnerd> это потребует частичных изменений в src/crypto.{h|c}, следите за обновлениями <gingeropolous> это затронет только стандартное обновление? Возможно удалённое? Или как? <vtnerd> Специально для сканирования получаемых выходов (outputs) по первичному адресу <vtnerd> от этого не будет особой пользы для субадрессов, но благоприятно для simplewallet / GUI / Viewkey scanning <medusa> как насчёт беседы о «Слоне в комнате»? Bulletproof в реалиях testnet <rehrar> Хорошо. Благодарю Кто-то ещё? Движемся дальше? <rehrar> Да, продолжим. <moneromooo> Немного мыслей за последнее время: зашита сборки (в настоящее время ломает статические сборки), DNSSEC патч для windows, БД и завивание при попытке синхронизации, полный сброс защищенной части памяти (wip), обзор и исправление кода, использование HTTPS для получения обновления и продолжение загрузки после проблем. <ArticMine> Я присутствовал на BTC awards CIS и участвовал в «панели монет». Там также присутствовали две другие монеты - Dash, ZenCash. В общем всё прошло просто отлично и обеспечило взаимодействие Monero среди CIS (Содружество независимых государств) крипто сообщества <endogenic> medusa: я слышал, что MRL ищет людей для обзора и аудита bulletproofs <endogenic> sarang, вы могли бы дать больше информации <ArticMine> Это моё краткое обновление <ArticMine> что касается bullteproof, он переносится на сентябрь <endogenic> moneromooo: режим зверя <rehrar> ArticMine, хотите уточнить? <moneromooo> Не всё из этого мной получено из проверенных источников <hyc> интересно ArticMine - CIS уже имеет Monero опыт в лице – Karbo, клона из Украины <medusa> GUI наконец получил subaddress, dsc успешно трудится над черной темой для GUI и мы надеемся жить с 2 прогресс-барами вместо 1 (синхронизация и обновления разделены). Ещё мы добавили функцию «изменить пароль» в GUI <ArticMine> FP поговорили с Pieter Wuille, и он рекомендует сентябрь <sarang> Постараюсь ответить на любые вопросы о Bps, на которые у меня есть ответ <ArticMine> Есть ли план дальнейшего пересмотра? <ArticMine> или «план Б» <sarang> Да <ferretinjapan> В случае чего есть весомые основания для переезда обратно? <sarang> Возможно подписание контракта с аудиторской группой, fluffypony хорошо знаком с ними <sarang> Это конечно не совсем понятно, но я в скором времени устраиваю телефонную беседу с ними <sarang> Их целью будет дополнительный сторонний обзор <hyc> ferretinjapan: Известных проблем нет, во избежание случайностей мы планируем провести дополнительную проверку <rehrar> Вот мы и перешли к третьему вопросу сегодняшней повестки дня, который заключается в заморозке кода — мартовский hard fork. Bulletproof является одной из них. Что скажите? <binaryFate> sarang, помимо обзора кода, каково ваше мнение о необходимости обзора самой математики? Я беспокоюсь, что у«бумажной» версии было мало времени пройти экспертную оценку. Но, возможно, там всё настолько очевидно, что не требует дополнительной проверки. <sarang> Математика железная. Дополнительная экспертная оценка всегда приветствуется. <binaryFate> (говорит о BP – не конкретные спецификации Monero) <sarang> Да <sarang> В тоже время, moneromooo, я работал над некоторыми дополнительными оптимизациями для проверки доказательств, которые не зависят от математической или конкретной реализации <ferretinjapan> вот в чем дело, насколько «прибавление стоимости» является дополнительной проверкой на данный момент? <binaryFate> отлично <sarang> мы имеем несколько неофициальных отзывов <sarang> но полноценного стороннего обзора мы пока не имеем <ArticMine> … всё же это гарантирует отсрочку BP до сентября <sarang> Чтобы иметь полноценный обзор? Скорее да, чем нет <sarang> Преимущество задержки в том, что мы могли бы полностью избавится от одноканального BP <sarang> определить структуру сборов с несколькими выходами и выпустить <medusa> не будет ли вариантом мульти-выход (multi output) для марта? <sarang> Верно <ferretinjapan> Со стороны выглядит ужасно расточительным :/ <sarang> Это потребует изменения способа расчёта сборов <hyc> Я за то, что-бы пропустить выход (single-output). Потребуется слишком много работы для недолговечной функции <sarang> Да, доказательства с одиночным выходом (single-output) проверят с помощью кода мульти-выхода (multi-output) без изменений <ferretinjapan> возможно, вам будет лучше убедиться, что есть какой-то запасной вариант BP вместо того, чтобы полностью отступить.. <rbrunner> ведь работа почти готова? <ferretinjapan> это классический случай - быть врагом добра. <endogenic> Действительно, мы не пинговали anonimal <sarang> Теперь мультикод работает <sarang> к сожалению, еще не в testnet <sarang> и у нас нет консенсуса по поводу структуры сборов (fee) <hyc> ^^ <binaryFate> Я склоняюсь к безопасности в общем. Ошибка ringct была достаточно близко. <Maxithi> hyc: ведь, лучше перебдеть, чем недобдеть <iDunk> Согласен <dEBRUYNE> sarang: рассматриваете ли вариант обращения к авторам статьи для подробно рецензирования? <gingeropolous> ferretinjapan: подвижки будут в сентябре для дополнительной проверки кода <dEBRUYNE> <binaryFate> Я склоняюсь к безопасности в целом. Ошибка ringct была достаточно близко <= Вероятно, я не смогу пережить ещё один мини-сердечный приступ <sarang> У нас был неофициальный обзор от одного автора, но другие авторы работают над другими реализациями, я не буду полагаться на них для получения быстрого обзора <hyc> Я предложил запросить обзоры через электронную почту <endogenic> отличная идея <hyc> можно запросить обзор в twitter <dEBRUYNE> по-видимому у них будет время до августа? <endogenic> Это тоже <dEBRUYNE> \^ sara <dEBRUYNE> sarang* <sarang> hyc: ты в порядке, с такими домогательствами в твой адрес? <sarang> Я конечно мог бы попробовать работы сторонних авторов на всякий случай <moneromooo> обход выхода (single-output) BPs не является преимущественным. <hyc> Да, нам нужно решить, представим ли мы оплату <sarang> она даст гораздо больше шансов <moneromooo> в обход <ferretinjapan> gingeropolous: да, но noones дал вескую причину задержки, за исключением большой предосторожности с его стороны, к тому времени это будет уже частично неактуально :/ <endogenic> есть призыв к отзыву(blurb/call-to-action about), которые можно переправлять в соответствующие списки? <hyc> moneromooo: время до сентября даст запас на сборы <sarang> hyc: fluffypony указал, что мы могли бы собрать средства для обзора <moneromooo> Не думаю, что на это потребуется много ресурсов <ArticMine> Мы только задержим выход(single output) <moneromooo> мульти выходы (multi output) bulletproofs написаны на C++, но не подключены к блокчейну <sarang> Любой, кто заинтересован в обзоре, может связаться со мной по электронной почте sarang.noether@protonmail.com <endogenic> какие-то указание где искать — в коде, репозитории, документах или где-то ещё? <hyc> endogenic: Я составлю список <sarang> Я свяжусь с другими авторами отдельно <sarang> всё равно нужно будет присмотреться к аудиторской группе, чтобы увидеть, какова их сфера охвата <luigi1111w> там не особо много работы, если пропустить выходы (single output) BP <moneromooo> ожидание до сентября ничего не изменит для сборов <luigi1111w> время на обзоры слишком мало <luigi1111w> В любом случае я думаю, что это общая цель <hyc> в качестве альтернативы, мы могли бы перенести мартовский релиз на апрель <sarang> fluffypony был против этой идеи <hyc> ок <ferretinjapan> всегда можно отталкиваться от мартовского hard fork, месяц или два как в случае с RCT. <sarang> Не говорю, что это главный решающий фактор <luigi1111w> rct был передвинут на передний план <rbrunner> что является главным аргументом? <ferretinjapan> ой <sarang> Он думал, что регулярные выпуски будут преимуществом <rehrar> он имеет ввиду, что люди привыкли к hard fork по расписанию <sarang> из-за предсказуемости <endogenic> rbrunner: для? <ferretinjapan> rbrunner: вероятно это его рассудок <rbrunner> против одно месяца задержки <luigi1111w> мой собственный чердак говорит: «в июле, 3 месяца» <endogenic> bitcoin - знамение периодичности hard fork <endogenic> предполагаю <rehrar> Я думаю, ожидание в шесть месяцев не так и много для bulletproofs. Небольшая потеря для обеспечения улучшения безопасности. <gingeropolous> ^^ <ferretinjapan> 6 месяцев - очень много для крипосообщества <luigi1111w> кто-то упоминал предстоящее сокращение <sarang> *вздыхает* <gingeropolous> будущее сокращение? Ты имеешь ввиду двойной пузырь (double blob)? <sarang> Люди хотят видеть понижение комиссии сейчас <sarang> (tm) <vtnerd> мы все хотим, sarang <sarang> по крайней мере голосовавшее меньшинство <dEBRUYNE> rehrar, ты сказал: «люди привыкли к hard fork по расписанию» <= я сомневаюсь, что большинство экономически чувствительных узлов знают о нашем расписании <ferretinjapan> endogenic, наступает момент, когда ты ожидаешь, но ничего не получаешь в замен <ErCiccione> Я думаю, что на этом этапе сохранение запланированных 6 месяцев не должно быть приоритетом. Я согласен с dEBRUYNE <rehrar> Если бы мы отступили на два месяца с марта по май, это был бы хороший компромисс? <luigi1111w> нет, но вот если 3 месяца, с марта по июнь….. <sarang> Если мы действительно хотим хорошую дополнительную проверку, график должен быть гибким для рецензентов <gingeropolous> не стоит спешить <Maxithi> Лучше 3 месяца, чем 6 <sarang> полный академический обзор может быть удручающе медленным и непредсказуемым процессом <rehrar> хорошо, тогда с марта по июнь <endogenic> я согласен с sarang, мы не имеем права для диктовки своих условий <iDunk> это навевает дежавю последней нашей встречи <sarang> в основном <luigi1111w> я пьян <rehrar> в основном <endogenic> у нас также нет достаточно информации, чтобы знать, сколько времени займет достаточное количество отзывов на данном этапе <endogenic> не уверен, что это хорошая идея для того, чтобы судить о чём то <ferretinjapan> rehrar, я думаю, что важно быть реалистом, торопиться - это плохо, (подчеркнули разработчики!), излишнее откладывание тоже не скажется положительно <dEBRUYNE> 8 месяцев, кажется, будет достаточно <rehrar> это емкая и трудная часть децентрализации без лидера <ArticMine> Почему бы не идти вперед с марта, если BP будет почти готова к сентябрю? <endogenic> что с повесткой этого дня встречи? <luigi1111w> ну там действительно ничего не осталось больше на март <sarang> Возможно, лучше немного подождать, чтобы услышать непосредственно о потенциальном интересе самого обозревателя? <sarang> в ином случае это всё спорно... <luigi1111w> нам в любом случае придётся раскошелиться для того, чтобы уложиться в график <sarang> точка <rehrar> как долго мы готовы ждать? код нужно будет заморозить <sgp> почему бы не спланировать hardfork через месяц после рецензии BP? <ArticMine> Мультиподписи в марте <luigi1111w> нет форку! <rehrar> мультиподписи не потребуют hard fork <dEBRUYNE> мультиподписи не потребуют hard fork, хотя... <luigi1111w> возможно в релизе <dEBRUYNE> lol <luigi1111w> ребята... <rehrar> lel, dEBRUYNE <endogenic> что <rehrar> к единому мышлению <gingeropolous> всё же это может быть ошибкой для сквоша (squash) <endogenic> если только у новичков <dEBRUYNE> да, ботов <pebx> получается, по большому счёту нам не нужен hard fork в марте без BP? <ferretinjapan> sgp, я считаю, что это отличная идея, но "согласованность" может стать решающим фактором. <luigi1111w> pebx, часть планов ориентирована на расписание hard fork, мы должны придерживаться их <rehrar> давайте вернёмся к теме собрания, у нас ещё будет время на обсуждение этой темы <sgp> Я считаю, что награды настолько велики, что стоит рассмотреть возможность нарушения последовательности <rehrar> чтобы удостовериться, что всё остальное будет готово? <rehrar> у нас ещё будет время для обсуждения, в конце <luigi1111w> час времени - довольно мало <endogenic> rehrar: ты какой-то прагматик? <ferretinjapan> luigi1111w, никто ничего не говорил о каком-то фиксированном расписании <gingeropolous> sgp, на самом деле логика была придумана заранее, чем спланировали ringct fork <rehrar> мы не держим никого, желающие могут покинуть встречу <luigi1111w> lol <dEBRUYNE> что еще нужно будет обсудить? <endogenic> dEBRUYNE: как насчет того, какую именно газировку предпочитает rehrar? <iDunk> Субадреса(Subaddresses) и сборы (fees) для следующего форка (fork). <rehrar> “просто разводит руками в стороны” мы не обязаны делать всё правильно просто порой ставлю себя на место людей, которые заходят обсудить код или какие-то проблемы <ArticMine> я не вижу смысла изменения сборов( fees) без BP <pebx> я не математик, просто предпочёл бы один выход(single output) в марте / апреле / мае, чем ждать данные с ещё более спорными изменениями в структуре сборов(fee) <iDunk> даже если значение пошло вверх ~40x с момента последней корректировки? <endogenic> rehrar: не будь таким глупым, никто не хочет обсуждать этот вопрос… <rehrar> хорошо <sarang> pebx: изменение сборов(fee) не должно выглядеть так противоречиво <luigi1111w> ArticMine, аргументы должны быть бесшовными для снижения сборов(fee) <sarang> альтернативой будет DOS <rehrar> как скоро мы должны принять решение? На этом или следующем собрании? <rbrunner> Что такое DOS? <endogenic> rbrunner: отказ в обслуживание? <rbrunner> что в итоге о сборах(fee)? <ArticMine> Мы можем понизить минимальный сбор, но люди не будут использовать его в любом случае <endogenic> т. е. спам? <serhack> привет! <dEBRUYNE> Для текущих доказательств диапазона вам нужно будет настроить штраф <luigi1111w> такого не должно случится <luigi1111w> к марту <ArticMine> спам в txpool является большим риском для минимальных сборов (fee) <dEBRUYNE> чего не должно случится к марту, luigi1111w? <luigi1111w> настройка штрафов (penalty) <pebx> @ArticMine, для большинства пользователей будет в новинку снижение сборов(fee) <luigi1111w> штраф <pebx> я читаю это постоянно во всех группах Telegram "почему сборы(fee) такие большие?" <ArticMine> Один из способов сделать минимальный сбор(fee) для кошельков по умолчанию <dEBRUYNE> сборы(fee) за kB информации не так уж и высоки <pebx> Большинство сервисов использует параметры сборов(fee) по умолчанию, как и mymonero <dEBRUYNE> сделки просто нецелесообразно больших объемов <endogenic> pebx: не стоит волноваться, я работаю как раз над настройкой приоритета для новых приложений <pebx> dEBURNE, разве не именно по этому bp так важен? <dEBRUYNE> правильно, просто не стоит торопится <Maxithi> @ArticMine: Один из способов сделать минимальный сбор(fee) для кошельков по умолчанию <= я считаю что это на самом деле отличная идея, просто сбором(fee) по умолчанию не пользуются <ErCiccione> ^^ <dEBRUYNE> это приведёт к засорению mempool <luigi1111w> я использую сборы(fee) <moneromooo> тогда не будет использовать сборы(fee) по умолчанию как они есть <iDunk> так что <luigi1111w> я использую оба способа в зависимости от ситуации <jtgrassie> с BP определённо не стоит спешить, но и отставать от расписания не стоит <luigi1111w> dEBRUYNE, что-то из этого будет неизбежно <Maxithi> Да, просто не думаю, что из присутствующих кто-то не использовал его <luigi1111w> две противоборствующие стороны за работой <rbrunner> Уровень сборов(fee) должен быть на очень низком уровне, чтобы сказать «я готов подождать» <dEBRUYNE> luigi1111w: по мнению майнеров, просто будут ставить стандартные иди более высокие сборы для обхода mempool <dEBRUYNE> всё из-за того, что они могут использовать только последнюю транзакцию для сборов <luigi1111w> не уверен <dEBRUYNE> у вас не может быть 23 минутных сборов, а затем со стандартным значением <binaryFate> <ArticMine> один из вариантов просто изменить в кошельке по умолчанию на минимальный сбор (fee) <– +1 <endogenic> разве это не плохая идея? \^ <moneromooo> эта. <luigi1111w> эта идея <luigi1111w> Не уверен, хорошо это или плохо <moneromooo> Если только не увеличится количество транзакций в течении полугода <endogenic> было бы здорово это обыграть <Maxithi> нужно уходить, до встречи <endogenic> Maxithi, так и не получил откровений <luigi1111w> извините, у меня закончился обед, нужно работать * luigi1111w ворчит о встрече снова и снова <ArticMine> менталитет человеческого стада <Maxithi> endogenic, не важно, хотел попросить людей задавать и выделять больше вопросов * Maxithi соглашусь с luigi1111w <dEBRUYNE> что если кошелёк будет менять приоритет от количества транзакций в mempool? <endogenic> Maxithi: возможно вы могли сделать это? <dEBRUYNE> таким образом минимальный сбор(fee) если < 1000 kB и стандартный если > 1000 kB? <dEBRUYNE> \^ ссылаясь на произвольные числа <rbrunner> разве это не станет фактором появления гневных людей? «почему я столько, а он столько?» <rbrunner> Нужно делать всё предельно прозрачно <ArticMine> dEBRUYNE, что если кошелёк будет менять приоритет от количества транзакций в mempool? <— Это должно сработать <hyc> endogenic, sarang: email проект https://pastebin.mozilla.org/9075994 <dEBRUYNE> Вы можете сделать заметку в кошельке <pebx> разве это не смутит пользователей ещё больше? <dEBRUYNE> «изменение уровня платы из-за очереди» <rbrunner> Боюсь люди просто не поймут механизм <rbrunner> сравните сборы (fee), они будут разными для всех <rbrunner> или в разные промежутки <rbrunner> и кричать «афера» или что-то в таком духе <ArticMine> Этим обычно занимается Bitcoin <endogenic> hyc: термин "output" используется перед определением <dEBRUYNE> Это кажется слишком растянутым <rbrunner> люди теперь даже не поймут, что они могут поставить комиссию на один уровень ниже , не так ли? <sarang> hyc: Я не видел никакого кода Java от авторов <rbrunner> Так или иначе <DaveyJones> rbunner, большинство людей не знает, что можно менять стандартные на 0.25x <sarang> hyc: я бы предпочел сказать, что они это знают <hyc> sarang: окей <rbrunner> они просто не смогут понять всё это, если это станет ещё сложнее <rbrunner> это мои опасения <endogenic> ой <rehrar> я вижу обе стороны медали <pebx> @ArticMine, это является одной из основных причин, почему люди смотрят в сторону Monero ... сборы - это одна вещь, которая смущает обычного пользователя Bitcoin <DaveyJones> в основном нужно понимать, что большинство людей, стонущих о налоговых сборах - это люди, которые просто считают свои деньги <endogenic> выглядит здорово! <DaveyJones> они не заботятся о механизме, только о вопросе цены <DaveyJones> автоматическое повышение сборов(fee) должно помочь при переполнение mempool? Или я что-то не так понял <ArticMine> Bitcoin имеет фундаментальные проблемы со сборами(fee), которые не имеют ничего общего с выбором какого либо кошелька. <sarang> hyc: может стоит заявить, что «мы будем рады любому стороннему обзору» и это привлечёт простых читателей? <binaryFate> Bitcoin - это кластеризация плавающих сборов(fee) и сборов(fee) за фиксированный размер блока. Здесь речь идет только о выборе значения по умолчанию среди 4 различных уровней. Тогда flex BL cap позаботится обо всём остальном, чтобы у вас не было зависших транзакции в mempool в течение 14 дней <sarang> Я не хочу, чтобы какие-то глупые СМИ сообщили, что мы не доверяем нашему собственному коду <jtgrassie> ихмо, сборы по умолчанию должны быть получены из размера mempool и быть полностью прозрачными для обычного пользователя <endogenic> Но боюсь, СМИ выборочно ничего не сообщают <sarang> -_- <endogenic> это не настоящая журналистика! <ArticMine> Это можно сделать на уровне кошелька <binaryFate> Это просто неразумно, что, когда фактически нет отставания в mempool, плата будет по умолчанию высокой <rbrunner> Может ли кошелёк работать с размером tx pool? <endogenic> binaryFate: simplewallet может предупредить по крайней мере <rbrunner> технически, если к этому ниточки? <endogenic> "n блок, отставание по умолчанию возьмёт такой сбор(fee)" <endogenic> ох, следующая встреча через 2 недели? <sarang> endogenic: я хочу дать понять, что мы принимаем осторожный, но уверенный подход, который использует экспертную оценку, как и любая другая хорошая академическая работа <endogenic> sarang: я полностью согласен <jtgrassie> 13:02 <endogenic> ох, следующая встреча через 2 недели? <rehrar> Да, прости. Если кто-то хочет уйти. Следующая встреча через две недели. <rehrar> 28 числа <binaryFate> Предупреждение заставляет людей думать что-то вроде "я должен использовать более высокий сбор (fee)", а не наоборот. Кто при использовании стандартных сборов(fee) и видя 0/1 блока неподтверждённой работы берёт и всё отменяет, и вернёться к использованию низких сборов? Думаю, это не должно быть автоматическим решением, возможно, только с подтверждением Y/N <sarang> hyc, endogenic: перенесём разговор об обзоре BP в #monero-research-lab после встречи? <endogenic> да, отличная идея <endogenic> binaryFate <hyc> ок <endogenic> я не совсем понимаю автоматическую систему, с точки зрения ux <rbrunner> автоматизация всегда лишает нас какого-то выбора <endogenic> необязательно <endogenic> если результат отображается, чтобы пользователь мог подтвердить, прежде чем негласно соглашаться <endogenic> тогда должно быть всё в порядке <endogenic> вопрос <endogenic> как это будет выглядеть в CLI? <binaryFate> это просто выбор по умолчанию, а не принуждение пользователя <endogenic> в конечном итоге может потребоваться какое-то уведомление или действия от пользователя <endogenic> да <endogenic> выбор <endogenic> o/ <rehrar> Можем ли мы запланировать срочную встречу на этой неделе или на следующих выходных? <rehrar> Просто для обсуждения и принятия решения по ВР <endogenic> rehrar, я готов присутствовать на любых встречах <rehrar> или это не очень хорошая идея? <sarang> rehrar: Мы будем ждать отзыва? <rbrunner> Похоже, на специальном совещании <sarang> Чтобы хотя бы увидеть, кто и что планирует рассматривать? <endogenic> sarang: лично я бы <rehrar> Sarang, у нас есть ETA? <DaveyJones> BP + fee? <ArticMine> я готов на следующих выходных <DaveyJones> довольно немного для этой встречи <endogenic> или я бы провел встречу с основной целью решения того, как мы можем запросить и завершить, наконец, обзор <DaveyJones> нужно немного больше размышления <sarang> rehrar: У меня телефонная встреча с аудиторской группой во вторник <rehrar> отлично. <sarang> Я предполагаю, что hyc может оставить отзывов после того, как мы закончим корректуру <rehrar> Я могу сделать запрос в зависимости от этого. <sarang> я свяжусь с другими авторами сегодня <rehrar> Я поставлю «предварительное» собрание на следующее воскресенье <sarang> принято <rbrunner> звучит отлично <rehrar> И если что-то изменится, я откорректирую его <sarang> Я буду публиковать любые обновления в IRC <rehrar> Ты можешь прокоментировать это на GitHub, пожалуйста? <sarang> почему нет <rbrunner> Я уверен, что организовывать большую встречу на весь день нужно для чего-то важного, вроде BP <rbrunner> просто говорю <rbrunner> идея для достижения консенсуса <rehrar> Хорошая идея rbrunner. Запланирована 4-часовая встреча, затем небольшой перекус. Потом еще четыре часа. <rbrunner> <ErCiccione> мы говорим о кодовой заморозке? Мне действительно нужно знать дату как для команды локализации, так и для руководства GUI, которое будет идти в двоичных файлах <rehrar> многие люди ушли, к сожалению, трудно сейчас обсудить этот вопрос :/ <rehrar> BPs заняло большую часть сил. <rbrunner> С прорывом еще немного труднее, если вы спросите меня … <rbrunner> Но, с другой стороны, это, наверное, хорошо <ErCiccione> rehrar: да… это все немного испугало меня, еще где-то в середине февраля, верно? <rehrar> rbrunner, это показывает, что мы действительно децентрализованы? <rehrar> Dunno, erciccione, я думаю, это был январь <rbrunner> rehrar: Да. <sgp> iirc, это должно продлиться пару месяцев <sgp> перед hf <rbrunner> Был одним из важных моментов выступления fp в Цюрихе, на котором я как раз присутствовал <ErCiccione> rerhrar: я просто подожду, чтобы располагать большей информацией <binaryFate> rbrunner, какая точка? <sgp> думаю это хорошая идея <rbrunner> Хорошая децентрализация Monero <binaryFate> ErCiccione, пока время hard fork все еще туманно и обсуждается, я думаю, что справедливо предположить, что замораживание кода не произойдет в ближайшее время. Это, пожалуй, всё на данный момент <sgp> Я думаю, что некоторые локализационные материалы с низким приоритетом могут быть объединены немного позже <Billy> Я думаю, что нам нужно решить проблему BP как можно скорее. Эти собрания не помогают этого сделать <rbrunner> Можно сказать по результату двух последний заседаний <rbrunner> 1 час это чертовски мало для таких встреч <ErCiccione> ок, спасибо, binaryfate. Проблема в том, что переводчики все время спрашивают об этом, потому что они должны организовать свое время, они не хотят, чтобы их работы не имели официального релиза Источник: Logs for the Dev Meeting Held on 2018-01-14 Перевод: Unholy (@Unholy) Редактирование: Mr. Pickles (@v1docq47) Коррекция: Kukima (@Kukima)
