From 7a7ce8274b6b61d0ee930459fd71d08ba69cf138 Mon Sep 17 00:00:00 2001 From: el00ruobuob Date: Mon, 23 Sep 2019 10:06:40 +0200 Subject: [PATCH] Dev meeting logs from 2019-09-22 --- ...-for-the-dev-meeting-held-on-2019-09-22.md | 328 ++++++++++++++++++ 1 file changed, 328 insertions(+) create mode 100644 _posts/2019-09-22-logs-for-the-dev-meeting-held-on-2019-09-22.md diff --git a/_posts/2019-09-22-logs-for-the-dev-meeting-held-on-2019-09-22.md b/_posts/2019-09-22-logs-for-the-dev-meeting-held-on-2019-09-22.md new file mode 100644 index 00000000..84d53d70 --- /dev/null +++ b/_posts/2019-09-22-logs-for-the-dev-meeting-held-on-2019-09-22.md @@ -0,0 +1,328 @@ +--- +layout: post +title: Overview and Logs for the Dev Meeting Held on 2019-09-22 +summary: Development status, 0.15 release discussion, Network upgrade planning, and miscellaneous +tags: [dev diaries, core, crypto] +author: el00ruobuob / rehrar +--- + +# Logs + +**\** ok +**\** it's time +**\** 1. Greetings +**\** who all is here? +**\** hello :) +**\** Hi +**\** Hey hey hey +**\** Hi +**\** hey +**\** \\o/ +**\** Hi +**\** so everyone except the people rehrar pinged are here, nice. +**\** it would seem so +**\** moneromooo: do we have you at least? :P +**\** Yes. +**\** one last round for fluffypony luigi1111 ArticMine binaryFate +**\** please join us ASAP +**\** in the meantime, we can move on to 2. What's been completed since last meeting? +**\** here +**\** I've finished RandomX JIT compiler for ARM CPUs. Verification time is even better than CN/R on ARM. +**\** Pretty good stuff here. +**\** Nice +**\** Hi +**\** I am here +**\** Hi +**\** so I guess we are including the ARM JIT in the release? +**\** probably no reason not to +**\** It can be disabled with an env var AFAIK so sure. +**\** just it hasn't been heavily tested as the x86 JIT +**\** Sirs! ferretinjapan asked moi to join. +**\** since it's easily toggled off, I'd say we run with it +**\** hi +**\** o7 I will keep still :) +**\** monerod can now synced from pruned blocks (optional). I'd like this to go in before release if reviewed. +**\** Honest question to everyone, now that CLI has reproducible builds, can we as a community decide on a date without input from Core? +**\** GUI? +**\** that's next selsta :P +**\** yes but it would be nice to release both the CLI and GUI at the same time and that depends on core +**\** Pony still controls the website (for binaries to be uploaded), and the DNS records (for the hashes of the binaries). +**\** ok so there's distribution and GUI to consider +**\** Pony said he'd be around for the CLI & GUI release +**\** I mean, ultimately we want to go along this road at some point to reduce centralization anyways, no? +**\** Also needs people to build for random OSes. Does Windows have repro builds too ? +**\** Do we have a release date in mind? +**\** moneromooo: Yes +**\** At least for the CLI +**\** ArticMine: i think the idea was to set a date today +**\** so let's set one +**\** ArticMine can represent the core team here +**\** October 26? +**\** Are we thinking mid-October? End of October? +**\** I would personally prefer a bit more towards the end of October, as that gives us a bit more leeway +**\** I do not ave an issue with setting a release date at this meeting +**\** i agree +**\** Let's go with October 31, Halloween +**\** is this the release date of the fork date? +**\** or\* +**\** it'll be scary +**\** I have some reservations about the stability of randomx-in-monerod. Bugs are still coming in fast. +**\** Monero's spoopy fork +**\** tevador: fork date +**\** tevador: fork date +**\** October 31 is a bit too late +**\** So pushing back would be good in my view :) +**\** and code freeze? +**\** if mooo has reservations then maybe 31 is a decent date? +**\** sech1: what's your reasoning? +**\** so better to not do it in the middle of the week +**\** I'm sorta here +**\** October 31 is kind of an edge of publicly promised "fork in October" +**\** October 26 sounds better +**\** I don't anyone (who counts) ever promised. +**\** assuming it's actually ready by then +**\** Welcome to decentralization sech1. +**\** I am fine with 26th +**\** yeah, 26 October would be better if it's doable +**\** Community won't be too mad if we don't hit deadlines +**\** Go with the date of the next UK election +**\** testnet has been disturbingly unstable the past few weeks. +**\** but most of the problems were unrelated to randomX +**\** Better a safe launch than an october launch. +**\** One key point is the time between release and fork date +**\** Normal testnet or the RandomX testnet? +**\** randomX testnet +**\** but the issues with peers being disconnected and banned would have happened on public testnet too if anyone bothered to exercise that +**\** basically current git master is unstable, recent changes to the networking code broke a lot. +**\** if fork is October 26 (4 weeks), would 2 weeks be enough to fix all that? +**\** and would additional 5 days help? +**\** i'm starting to think would be better to posticipate to after october +**\** so it looks more like November +**\** Release and fork date ware very different +**\** hyc: Those recent changes will be reverted by 5905 right? +**\** Yes. +**\** We need to give people time to update +**\** if there are so many doubts i would just wait. No reason to rush it, this is a big fork +**\** agreed, safer to wait +**\** so really all of this should have been discussed two weeks to a month ago +**\** I don't think the optics of a "late" Oct 31 date will be terrible. We can get ahead of it with the Halloween marketing. If people prefer November, then I think we should still pick a date +**\** will this release discontinue legacy payment IDs? +**\** so for next time we really need to start seriously discussing the fork two months prior to "planned" date +**\** Yes. +**\** Though currently not banned, just code removed. +**\** rehrar: I don't think we could have foreseen the issues arosen on testnet +**\** Are any large exchanges still using them ? +**\** I suggest an October 31 release date with a fork date 4 weeks later +**\** late is far better than broken +**\** I can try to compile a list +**\** We still need to decide fork date and release schedule today +**\** dEBRUYNE: literally every single fork there is a "I don't think we could have foreseen" situation? +**\** What happened to move fast and break things? This is tech! +**\** Yes because there will simply be things that cannot be foreseen +**\** You cannot perfectly plan such a thing +**\** I too enjoy breaking money when possible +**\** ok, ArticMine has made a concrete suggestion +**\** 31st release date, one month later fork date +**\** one month? why one month? +**\** I think its reasonable. +**\** No objection here. +**\** luigi1111, I agree, late and working is far better than on time and buggy... +**\** is that the same offset we used in previous releases? +**\** moneromooo: i have about 330 miners still mining to payment\_id addresses. that's 5 % +**\** no, closer to two weeks I think +**\** To give people proper notice to upgrade +**\** that's what it ended up being +**\** We were pushing to the wire last time +**\** To be fair +**\** we never targeted two weeks that's simply not ideal +**\** Two weeks was cutting it close +**\** This has been an issue many times before +**\** yeah, one month seems fair +**\** October 31st release and November 30th fork then? +**\** yes we've always pushed releases to late but doesn't mean we shouldn't try to do better +**\** sounds fine to me +**\** So what specific fork date? +**\** 30th Nov +**\** November 30 is again Saturday, which is nice +**\** let's hope CN/R holds without ASICs until then :) +**\** So when is code freeze? +**\** Whenever we don't have anything left we want to merge :) +**\** now with reproducible build releases should be much faster, at least for CLI. We rarely managed to release at the time we decided +**\** October 31st makes sense imo +**\** I think having a release in October will help with optics. And a 31st update is easy to brand +**\** alright, it looks like we have a loose consensus, unless anyone would like to speak now +**\** Sure but how much time is needed between code freeze and release? +**\** in opposition +**\** like a week +**\** but fluffy fluffy fluffy +**\** +1 +**\** long code freezes never work +**\** luigi1111: did not show +**\** We only need fluffy to upload the bins though for the CLI release +**\** (and do the website) +**\** I know but if he's building he has to be able to commit to a schedule +**\** so Thanksgiving weekend hardfork (Nov 30) +**\** yes, better safe than sorry +**\** since we have reproducible builds we don't need him to build +**\** rehrar: He said he'd be available for the release (he'd prefer to have a timeline a bit in advance though) +**\** luigi1111: if he's unable to commit to a schedule, then we can do the deterministic builds thing, and just make sure they get uploaded +**\** ok cool +**\** then just gooey +**\** which is you +**\** The time between code freeze and release need to be set buy those closest to the code +**\** can you commit to this schedule? +**\** GUI gets build by pony +**\** oof +**\** Speaking of build privs, I would like to formally propose that some of the GUI repo privileges be transferred to dsc (the non deterministic build part at the very least) +**\** how can fluffy still be the only person able to do some vital things? +**\** I'm the one going to be doing all the merges in both projects so heh +**\** rehrar: Third time and last time I will say -> He said he'd be available for the release +**\** M5M400: that's why deterministic builds is top priority +**\** dEBRUYNE: ok +**\** M5M400, mainly because reproducible builds were never a thing before now. +**\** luigi1111: we really should move some of those responsibilities to dsc. +**\** needmonero90: I disagree, then we would have coders merging their own stuff +**\** He would be the new maintainer/lead of gui +**\** Or something +**\** ok, any other questions in regards to the set dates? October 31st release, November 30th fork. +**\** So what do we need for the release ? readline fixes for repro builds, randomx. The pay-for-service stuff. Payment ID changes. Hopefully the sync-pruned-blocks. Anything else that's large or really needed ? +**\** freeze date? +**\** needmonero90: that would be the first time a non-core team member will have done this. Not impossible, but certainly unprecedented and worthy of a bigger discussion which we don't have time for here in this meeting +**\** Once we branch the code is basically frozen right? Because then only fixes go in +**\** one week code freeze would be appreciated. Let's remember that there are the translation to deal with (and i beg for a code freeze since ever :D) +**\** Okay, tabled for now rehrar +**\** vtnerd\_\_: are you planning to have some more network stuff ready for the release ? +**\** I guess the #monero-pow guys would have a better idea when to freeze... +**\** Oct 24th as per luigi1111 selsta? +**\** he's not the only one with access to a couple things but the only one that actively used his access +**\** moneromooo: The readline fix is 5892 right? +**\** ArticMine: yes +**\** until recently where him and pigeons have both not been to active +**\** Could be. Depends on what people who have the problem say after testing it :) +**\** ArticMine: I think we can branch earlier, but moneromooo probably has a better view on that +**\** moneromooo does Oct 24 work for code freeze? +**\** pigeons is active. I asked him to update the server of getmonero last time +**\** That sounds plausible to me. +**\** moneromooo: it appears bittrex and binance still use payment\_id's +**\** and he also gave me a hand with weblate +**\** Thanks. +**\** moneromooo : yes, the split mempool is jst about done (finishing core tests nows) +**\** wow +**\** M5M400: Binance is working on upgrading their system, needmonero90 is in touch with them +**\** vtnerd\_\_: so your stuff will make it in this one? +**\** and the dandelion++ remnants \_shouldn't\_ be too painful - although I always say that :/ +**\** dEBRUYNE: saifu. great. +**\** Binance indicated they should be ready by fork in October. Pushing the date back shouldnt hurt the timeline. +**\** anyone in touch with bittrex? +**\** They are aware as far as I know +**\** I can't say whether it will "make it in", because theres always a chance something comes up during review, etc +**\** but the split mempool for the i2p/tor is close to ready. my concern is that its kind of tough the way it got shoved in +**\** You mean in a technical sense? +**\** I took hyc's approach of adding a tag to the metadata, but I had to inspect a bunch of code paths to make sure stuff didn't leak +**\** hi all, sorry got late to the party +**\** ultimately a true "physical" or "logical" split would be ideal, but it seemed kind of tough at the momnent when I tried to think about hwo to do it +**\** Oh so it's a single txpool, just txes have a flag ? +**\** yeah, unfortunately +**\** are we aware of any GPU miner in the works for randX that will be ready in time for spork? +**\** That's what I did for the sync-from-pruned :) +**\** M5M400: xmrig is ready +**\** 24th and 31st targets are good with me for 30th fork +**\** M5M400 xmrig 4.0 is combined CPU + OpenCL miner +**\** if thats worth a reject, then I can go back and try again, but its a little dicey otherwise (it requires a slightly larger refactor and possibly a second lmdb database) +**\** mostly afk now +**\** vtnerd\_\_: if this does make it in this time, it can be iterated on in the future no? +**\** hyc: sech1: nice +**\** It's not IMHO. I'd have done that too. +**\** But then I tend to shove things in :) +**\** yes, I don't think the patch makes it harder to refactor, its probably neutral from that perspective +**\** I don't really see other approaches to that as being a good idea +**\** btw, fork height could be 1978433, which is exactly the start of a RandomX epoch and should be in the afternoon CET on Nov 30th +**\** as an example of what I mean - one of the weird cases is that fluffy blocks request can leak the anonymity channel, etc, so yeah +**\** tevador: Afternoon CET would allow most people to be online, because it would basically be late evening for Asia and morning for US +**\** And let's reset testnet to fork on an epoch boundary too ? +**\** dEBRUYNE: yeah, nice coincidence +**\** i guess we have a fork height. Nice +**\** With a testnet fork around release, end of October? +**\** sounds good +**\** To summarize the timeline, this is approximately correct right? Branch within 2-3 weeks, freeze October 24, release October 31, fork November 30 +**\** I think we have everything we need for v12 now, apart from randomx, so we can fork the real testnet as soon as it gets merged. +**\** Even better then +**\** that looks like a sensible schedule +**\** yes, plenty of time to iron out all issues +**\** Famous last words :) +**\** It at least feels we are better prepared now than last time :-P +**\** someone should strictly enforce code freeze this time +**\** penalty of death +**\** tevador: i strongly agree +**\** moneromooo: Do we need pony around to fork the real testnet? +**\** can we reset stagenet too? it is getting quite huge +**\** Yes, the miner's one of his nodes, and seed nodes need updating too. +**\** The former's not a big problem, but the latter kinda is. +**\** Don't reset stagenet :( +**\** Ok, I will send him a message then +**\** Telegram tipbot uses it +**\** "Reset" means here dropping a few hundreds of blocks probably, no new genesis block +**\** It'll wipe all our balances ;\_; +**\** Back to the latest epoc date, that is +**\** (yes, I know, it's stagenet) +**\** Or a few thousands ... +**\** are we in any way concerned about the probably 10x hashrate post fork and the amount of blocks being spit out quickly? might it be a good idea to set a ballpark initial diff? +**\** I'm guessing that will be offset by the typical hashrate drop due to not everyone updating +**\** I am not. +**\** I don't think so. It'll rather grow slowly. +**\** I think to remember from earlier forks that "doctoring" the diff is not trivial +**\** Even with higher hashrate from CPUs, hard fork drop in hashrate will make initial diff roughly the same as now +**\** I wouldn't be worried un less ASICs were currently saturating the network, but by the sounds of it, theres been no indication of that being the case... +**\** I've seen a few big miners on the pool that are most likely CPU based. one instance of 17MH cn/r. these operations don't miss forks, as opposed to casual miners +**\** No signs of ASICs +**\** thats good. +**\** alright, is there anything else of note to discuss? +**\** minor: is it fine for everybody if we take down the current warning on getmonero, it's there since last fork +**\** We need to talk about extending the Monero Foundation's Dev tax, and the Monero name trademark issue +**\** i want to avoid people not reading it because they are used to it when we put up the new one +**\** Oh wait wrong coin +**\** We good +**\** ErCiccione[m]: good idea +**\** Yeah, take it down before it gets a running gag or something +**\** "Monero mixes up its hardforks" +**\** alright +**\** alright, will open a PR tomorrow +**\** alright friends, it would seem we're all good +**\** Is Gui considered core? +**\** Or is it it's own thing +**\** dEBRUYNE: now that randomx has quieted down I'll get to rebasing that gitian PR of mine +**\** needmonero90: that's actually a good question. See https://github.com/monero-project/meta/issues/384 +**\** Please no renaming discussion. +**\** The github issue is a better place for that. +**\** alright everyone, we'll officially break for today +**\** thanks for coming. Good discussion, and got a lot done. +**\** who's posting meeting logs? +**\** We can continue on a two weeks schedule for now? Or want to go to one week mini-check in on off weeks? +**\** hyc: el00ruobuob, usually +**\** ok. +**\** I think next mtg in 2 weeks is fine. after that, we can decide again +**\** ok +**\** unles you didn't mean on getmonero +**\** sounds good +**\** hyc: Thanks +**\** ErCiccione[m]: I'd prefer to update it with a general information thread regarding the upcoming fork +**\** I can have that ready next week +**\** dEBRUYNE: sure! will you PR it on repo.getmonero? +**\** guys sorry for the question , but i missed the begining of the discussion... Have you already choosen a block height for the fork? +**\** tevador> btw, fork height could be 1978433, which is exactly the start of a RandomX epoch and should be in the afternoon CET on Nov 30th +**\** ErCiccione[m]: Sure +**\** there seemed to be rough consensus on that +**\** thank you +**\** dEBRUYNE: great, thank you. Ping el00ruobuob\_ so he remembers to not PR it +**\** I don't mind if he PRs it +**\** he usally PR them after more than one week, should be fine +**\** Are we talking about the same thing? :P +**\** I was referring to the new information thread regarding the fork +**\** I was talking about the logs :P i understood you wanted to include them in the thread. +**\** but anyway, we should really make a blog post about it. +**\** So will the schedule be officially announced soon? +**\** sgp\_ was fast: https://old.reddit.com/r/Monero/comments/d7twle/tentative\_monero\_015\_release\_schedule/ +**\** sgp already announced it +**\** sgp\_: Perhaps worthwhile to mention in the comments why there is a bit of a delay +**\** I don't know what happened with testnet +**\** el00ruobuob\_ ignore what i said earlier, we need the logs :P