05:19:47 <0​xfffc:monero.social> s/IDE/texteditor/ 12:08:38 selsta: no opinion on https://github.com/monero-project/monero/issues/9912 ? 12:17:47 "Vulnerability fixes were blend into important feature additions, they have caused regressions or delays" i feel this is a bit misleading 12:18:13 unless i misunderstand what you mean with this 12:19:30 none of these were features 12:23:29 I consider "Option to HTTP servers" and "reduce writes from 2 to 1" to be in the range of features but I can take another wording. Main point was that these weren't direct bug fixes but improvements. 12:23:58 having to review 2 PRs for the different branches was not a significant bottleneck with this release 12:24:17 "were only merged for proper testing just before the targeted release timeline" <-- they simply were not reviewed before that 12:24:43 syntheticbird let's clarify the definition of "backport". merge direction primarily being one directional, "backport" is when the direction is the other way. primary direction = feature branch --> master & release branch. opposite direction = release branch "back" to dev & feature branches. 12:24:45 both http server and 2 to 1 were solely written for a vulnerability fix 12:28:42 i will add a comment to the issue but I don't feel anything of what is proposed touches the root issues (not enough reviewers, a release requires the coordination of various people making it cumbersome) 12:32:11 last paragraph under "Branch roles", s/minor/patch/g 12:33:49 "Cherry-pick required commits from master and make a PR for" <-- there is no guarantee that such cherry-picking would be cleanly possible due to diverging master and release branch 12:34:20 you also don't want a maintainer to try to fix conflicts in code they have not written 12:34:28 Re: not enough reviewers, any takers for anyone willing to lead group review walk-throughs or lightning talk about different parts of the codebase? (basically help on-board new reviewers / developers) 12:35:17 NorrinRadd edited 12:35:25 selsta: will answer in issue 12:35:41 1,$s/minor/patch/g 12:36:01 syntheticbird, correction ^ 12:39:01 NorrinRadd I edited, do you see another minor somewhere? 12:41:03 all fixed 13:39:50 A patch is significantly less likely to cause conflicts if we branched from master more often. If a patch doesn't apply cleanly, a maintainer could simply ask the author to PR against release. 13:40:14 Even if we don't bundle backports, I hold that we would greatly benefit from branching from master more often and limiting submissions to the release branch to bugfixes only. 13:52:43 I'm not against branching from master more often 13:56:49 suggestions on how we shall name the branches? 13:58:03 and when to move from 19->20->21 14:00:00 If we want to reserve the major version number for hardforks, the next release branch could be called "release-v0.18.5" or shortened in some way. 14:03:16 Imo we should consider dropping the "0." and moving to strict semantic versioning. I understand its significance as , but I don't think it's useful. When would we ever reach "1."? 14:03:30 Imo we should consider dropping the "0." and moving to strict semantic versioning. I understand its significance as 'the project isn't finished', but I don't think it's useful. When would we ever reach "1."? 14:05:34 1.* should be the next hard fork 14:05:57 hf.sf.patch 14:06:09 s/sf/feature 14:06:48 NorrinRadd: Currently we have: 0.pseudo-hf.feature.patch 14:06:52 hf="hard forks"+"major, potentially breaking, features" 14:09:01 Can't tell if you agree we should drop the 4 number version scheme. 14:11:17 Maybe should be hardfork.branch(feature).patch 14:13:34 So, we could name the next release branch "release-v18.5" or simply "v18.5". 14:15:17 drop it to hf.sf.patch 14:15:27 (down to 3) 14:15:35 I like `release-v18.5` even if only to keep the branch names consistent. Also probabky like 19, since this is a 2 year branch and the start id the "new" scheme 14:18:59 should probably bump the major version number anytime there are breaking changes as well, even if not a HF 14:19:36 I'm also fine with `release-v19.0`. tho we did add most of the features to the current release branch, so end users might expect more from a major version bump. 14:30:38 there are (imo) quite a few "invisible" changes 14:32:26 Before 18.4, one of them was making wallets incompatible 😅 14:33:28 and guix builds 17:50:10 https://github.com/monero-project/monero/pull/9856 17:51:09 > This is still marked as draft as this changes consensus code to use a different library depending on build. We could, as a matter of safety, use this only when "expanding" transactions in cryptonote_format_utils.cpp (leaving the curve order check to always use the "safer" ref10 code). 17:51:36 > Syncing current blockchain works w/ this patch (and appears to increase sync speed 40%, from ~100k blocks/hr to ~140k blocks/hr between blocks 2.25m and 2.8m) 18:14:54 https://github.com/monero-project/monero/pull/9494 18:14:56 targets a block sync size of (max of) 100 blocks or 10mb. 18:14:58 (100 block max was introduced as a ddos mitigation, and there is a serialization limit of ~30mb as well) 18:15:00 https://github.com/monero-project/monero/pull/8867 fixes the serialization limitation (as a result, block syncing wont be halted @ 30mb blocks or batches) 18:47:22 selsta any suggestions on ways to get more reviewers? 18:48:24 NorrinRadd: it's not easy, many of the vulnerability PRs require deep knowledge of the specific parts of the codebase to review properly 18:49:57 .merge+ 9875 18:50:07 .merges 18:50:07 -xmr-pr- 9875 18:51:08 right, you can't just plop people directly into that. but perhaps there can be a pipeline or incentives selsta 19:02:40 I can give a thumbs up / down based on vibes 19:16:36 different question, which should happen next, if any: v19 branched from master & release testing started, or prior to that, remove HFs from master, & begin the former. 19:22:12 branch from master. Hard fork branch is already separate on seraphis-migration org 19:22:34 ofrnxmr: there are a lot of Carrot related PRs opened against master 19:22:51 And staged in PRs 19:24:52 👍 19:25:04 let's make it happen. otherwise it will never happen. 19:28:12 the first 2 prs i posted (9494 and 9856) are ones i'd like to consider for the branching. Also 9847 (req 9838). 19:28:12 8867 is important as well, but is a big pr. 19:28:14 9443 (socks5) as well. 19:31:03 `git checkout master; git checkout -b release/v19.0;` `begin testing`. no choosing necessary, if nothing is being taken out. 19:31:46 https://media1.tenor.com/m/6spYha10OAgAAAAC/shipit-revert.gif 19:35:05 `release-v.19.0` * but i'd like 9443, 9494, 9838, 9847 in before branching 19:35:27 It's wish list time 19:35:30 Theyre all ready, (9443 almost), pending reviews 19:39:16 oh i misunderstood. disregard my 2nd to last comment 19:39:26 still true, but out of context 20:00:30 why are the stagenet fees out of wack? 20:01:23 Fee/byte being reported as `36000` instead of `20000` 20:03:07 A 1/2 tx has a fee of 0.000054290000 instead of 0.00003x 20:03:52 http://stagenet.xmrchain.net/tx/b37666ef99c2b8dad4e99ea9243491ce75af4ea2e415911e752ae59e102b0cbf 20:04:42 Stage and main should, afaik, be "identical" aside from block contents 20:34:13 (testnet is 200p 20:34:36 20000* btw. Only stagenet is differnet) 20:39:51 Does anyone recognize the email ric⊙to? They are cc’d on oss-fuzz vulnerability reports but I haven’t heard that handle before. It looks like binary fate added the email address so it’s likely fine. Just wanted to check 20:39:52 https://github.com/google/oss-fuzz/blob/master/projects/monero/project.yaml 20:43:57 https://bugs.chromium.org/p/oss-fuzz/issues/list?sort=-opened&can=1&q=proj:monero 20:44:27 seems like oss-fuzz for monero is down since a relatively long time 20:44:51 The Spagnis (ts) 20:46:55 Ahh its fluffypony, that makes sense 20:50:01 SyntheticBird: oss-fuzz was down from November to January IIRC. It should be actively fuzzing right now 20:50:02 https://introspector.oss-fuzz.com/project-profile?project=monero 20:52:24 thx 20:52:34 I took the link from the README 20:53:50 Although we should consider adding emails of more active maintainers 20:57:59 moneromooo hasn't abandoned afaik but the rest yeah 21:02:05 same with the VRP btw, remove luigi's email