<0​xfffc:monero.social> s/IDE/texteditor/

<s​yntheticbird:monero.social> selsta: no opinion on monero-project/monero #9912 ?

"Vulnerability fixes were blend into important feature additions, they have caused regressions or delays" i feel this is a bit misleading

unless i misunderstand what you mean with this

none of these were features

<s​yntheticbird:monero.social> 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.

having to review 2 PRs for the different branches was not a significant bottleneck with this release

"were only merged for proper testing just before the targeted release timeline" <-- they simply were not reviewed before that

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.

both http server and 2 to 1 were solely written for a vulnerability fix

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)

last paragraph under "Branch roles", s/minor/patch/g

"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

you also don't want a maintainer to try to fix conflicts in code they have not written

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)

<s​yntheticbird:monero.social> NorrinRadd edited

<s​yntheticbird:monero.social> selsta: will answer in issue

1,$s/minor/patch/g

syntheticbird, correction ^

<s​yntheticbird:monero.social> NorrinRadd I edited, do you see another minor somewhere?

all fixed

<t​obtoht:monero.social> 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.

<t​obtoht:monero.social> 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.

I'm not against branching from master more often

<o​frnxmr:xmr.mx> suggestions on how we shall name the branches?

<o​frnxmr:xmr.mx> and when to move from 19->20->21

<t​obtoht:monero.social> 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.

<t​obtoht:monero.social> 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."?

<t​obtoht:monero.social> 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."?

1.* should be the next hard fork

hf.sf.patch

s/sf/feature

<t​obtoht:monero.social> NorrinRadd: Currently we have: 0.pseudo-hf.feature.patch

hf="hard forks"+"major, potentially breaking, features"

<t​obtoht:monero.social> Can't tell if you agree we should drop the 4 number version scheme.

<o​frnxmr:xmr.mx> Maybe should be hardfork.branch(feature).patch

<t​obtoht:monero.social> So, we could name the next release branch "release-v18.5" or simply "v18.5".

drop it to hf.sf.patch

(down to 3)

<o​frnxmr:xmr.mx> 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

<o​frnxmr:xmr.mx> should probably bump the major version number anytime there are breaking changes as well, even if not a HF

<t​obtoht:monero.social> 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.

<o​frnxmr:xmr.mx> there are (imo) quite a few "invisible" changes

<o​frnxmr:xmr.mx> Before 18.4, one of them was making wallets incompatible 😅

<o​frnxmr:xmr.mx> and guix builds

<o​frnxmr:xmr.mx> monero-project/monero #9856

<o​frnxmr:xmr.mx> > 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).

<o​frnxmr:xmr.mx> > 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)

<o​frnxmr:xmr.mx> monero-project/monero #9494

<o​frnxmr:xmr.mx> targets a block sync size of (max of) 100 blocks or 10mb.

<o​frnxmr:xmr.mx> (100 block max was introduced as a ddos mitigation, and there is a serialization limit of ~30mb as well)

<o​frnxmr:xmr.mx> monero-project/monero #8867 fixes the serialization limitation (as a result, block syncing wont be halted @ 30mb blocks or batches)

selsta any suggestions on ways to get more reviewers?

NorrinRadd: it's not easy, many of the vulnerability PRs require deep knowledge of the specific parts of the codebase to review properly

.merge+ 9875

.merges

right, you can't just plop people directly into that. but perhaps there can be a pipeline or incentives selsta

<m​onero.arbo:matrix.org> I can give a thumbs up / down based on vibes

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.

<o​frnxmr:xmr.mx> branch from master. Hard fork branch is already separate on seraphis-migration org

<s​yntheticbird:monero.social> ofrnxmr: there are a lot of Carrot related PRs opened against master

<o​frnxmr:xmr.mx> And staged in PRs

👍

let's make it happen. otherwise it will never happen.

<o​frnxmr:xmr.mx> the first 2 prs i posted (9494 and 9856) are ones i'd like to consider for the branching. Also 9847 (req 9838).

<o​frnxmr:xmr.mx> 8867 is important as well, but is a big pr.

<o​frnxmr:xmr.mx> 9443 (socks5) as well.

`git checkout master; git checkout -b release/v19.0;` `begin testing`. no choosing necessary, if nothing is being taken out.

<o​frnxmr:xmr.mx> `release-v.19.0` * but i'd like 9443, 9494, 9838, 9847 in before branching

<s​yntheticbird:monero.social> It's wish list time

<o​frnxmr:xmr.mx> Theyre all ready, (9443 almost), pending reviews

oh i misunderstood. disregard my 2nd to last comment

still true, but out of context

<o​frnxmr:xmr.mx> why are the stagenet fees out of wack?

<o​frnxmr:xmr.mx> Fee/byte being reported as `36000` instead of `20000`

<o​frnxmr:xmr.mx> A 1/2 tx has a fee of 0.000054290000 instead of 0.00003x

<o​frnxmr:xmr.mx> stagenet.xmrchain.net/tx/b37666ef99…1ce75af4ea2e415911e752ae59e102b0cbf

<o​frnxmr:xmr.mx> Stage and main should, afaik, be "identical" aside from block contents

<o​frnxmr:xmr.mx> (testnet is 200p

<o​frnxmr:xmr.mx> 20000* btw. Only stagenet is differnet)

<a​ck-j:matrix.org> 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

<a​ck-j:matrix.org> github.com/google/oss-fuzz/blob/master/projects/monero/project.yaml

<s​yntheticbird:monero.social> bugs.chromium.org/p/oss-fuzz/issues…st?sort=-opened&can=1&q=proj:monero

<s​yntheticbird:monero.social> seems like oss-fuzz for monero is down since a relatively long time

The Spagnis (ts)

<a​ck-j:matrix.org> Ahh its fluffypony, that makes sense

<a​ck-j:matrix.org> SyntheticBird: oss-fuzz was down from November to January IIRC. It should be actively fuzzing right now

<a​ck-j:matrix.org> introspector.oss-fuzz.com/project-profile?project=monero

<s​yntheticbird:monero.social> thx

<s​yntheticbird:monero.social> I took the link from the README

<a​ck-j:matrix.org> Although we should consider adding emails of more active maintainers

<s​yntheticbird:monero.social> moneromooo hasn't abandoned afaik but the rest yeah

<s​yntheticbird:monero.social> same with the VRP btw, remove luigi's email