14:40:27 <Humza> Hello people. I hope everyone is doing good here. Just wanted to have a little discussion about the amount of issues and pull requests pending in the Monero repository. Over 200 PRs and more than 400 issues are pending and most of them seem to be very old, dating a few months to couple years ago (estimation based
14:40:28 <Humza>  on a peek). Solving them and decreasing their count is better in my opinion as it increases the ease of contribution and decreases the burden on the developer (you as a developer know better here). It will be fairly quicker for new people to contribute to monero's repository and not having wait forever to get their PRs approved and merged
14:40:28 <Humza> (frankly, there aren't new people contributing, only the familiar faces). Honestly speaking, these numbers are comparatively lower than other repositories that you see which are the same size as Monero. I'd like to hear from developers what they think about this. Remember that I'm speaking from perspective of a neophyte, please correct me if I'm
14:40:29 <Humza> wrong anywhere, I'd really appreciate that. - In a good faith, from Humza.
14:45:07 <m-relay> <s​yntheticbird:monero.social> Humza almost all of the open PRs are stalled because they lack review. Monero repo enforce 3 (weighted)approval before merging
14:45:25 <m-relay> <s​yntheticbird:monero.social> some of them have simply not been closed
14:45:35 <m-relay> <s​yntheticbird:monero.social> or are not updated to current branch
14:52:04 <Humza> syntheticbird So the issue is probably because they are not enough code reviewers? Can't really comment on that as I do not hold much knowledge about the dev team itself.
14:53:05 <Humza> What do you mean by "some of them have simply not been closed"? It is possible to forcefully close older PRs right?
14:54:05 <m-relay> <o​frnxmr:xmr.mx> For some prs, particularly larger ones, yes, need more reviewers. For a majority of others, no, they are just incomplete or changes that arent agreed upon
14:54:10 <m-relay> <s​yntheticbird:monero.social> Humza, yeah unfortunately not all capable reviewers have time or dedication to review all the PRs. Most of the time they only review what is interesting to them
14:54:47 <m-relay> <s​yntheticbird:monero.social> yeah ofrnxmr is right i forgot some PRs just are stalled in discussion
14:55:39 <m-relay> <s​yntheticbird:monero.social> as for PRs "not closed", there are some PRs that were relevant in the past but not anymore
14:57:22 <Humza> Makes sense, If that's the case, then why doesn't anyone close them?
14:57:36 <m-relay> <s​yntheticbird:monero.social> because we forget they exist
14:57:55 <m-relay> <s​yntheticbird:monero.social> as you may imagine, it's not fun to go check the 400 PRs individually
14:58:34 <m-relay> <s​yntheticbird:monero.social> sometimes, somewhere, somehow, someone drops in chat someone remind the status of some PR and if some maintainer pass by he will execute to the task
14:58:52 <m-relay> <s​yntheticbird:monero.social> s/chat someone/chat
14:59:07 <m-relay> <s​yntheticbird:monero.social> s/he/they
14:59:47 <Humza> Fair, it's really cumbersome.
14:59:55 <m-relay> <s​yntheticbird:monero.social> indeed
15:00:22 <m-relay> <s​yntheticbird:monero.social> You can always check the 200 PRs and make an issue about cleaning some of them
15:00:31 <m-relay> <s​yntheticbird:monero.social> if you make an issue maintainers will see it and do the job
15:00:41 <m-relay> <o​frnxmr:xmr.mx> having them open isnt a bad thing, unless the prs are universally agreed to be no-good
15:01:26 <m-relay> <o​frnxmr:xmr.mx> The focus / place we can do better, is with prs that _are_ agreed to be good, but dont have enough eyes on them
15:01:54 <Humza> Frankly speaking, the code base is kinda complex :^)
15:02:31 <m-relay> <o​frnxmr:xmr.mx> reviewers are often devs too, workin on their own prs. So reviewing means they have to stop working on their code to take time to review someone elses. This is the usual bottleneck
15:02:40 <m-relay> <s​yntheticbird:monero.social> which part are you currently reviewing
15:02:45 <Humza> Additionally the code progress is relative small since developers are underpaid (are they? I dunno)
15:02:53 <m-relay> <s​yntheticbird:monero.social> LMAO
15:03:18 <m-relay> <o​frnxmr:xmr.mx> In monero, devs have to pay to contribute /s
15:03:31 <Humza> I'm not reviewing anything, I just came here after getting overwhelmed by the code :)))
15:03:53 <m-relay> <s​yntheticbird:monero.social> yeah i mean what part of the codebase got you overwhelmed with
15:09:18 <Humza> All, I started with checking the wallet code and it was already over when I saw that it's 666kB.
15:09:44 <m-relay> <s​yntheticbird:monero.social> lmfao
15:09:53 <m-relay> <s​yntheticbird:monero.social> rule 1: Never look at wallet2.cpp
15:09:54 <Humza> Ehh, I'm not really experienced developer. I'm just an amateur who barely knows stuff about cryptography n' shit.
15:10:33 <m-relay> <s​yntheticbird:monero.social> thats fine everyone start somewhere
15:36:59 <m-relay> <m​onero.arbo:matrix.org> real answer: it's all volunteer / donation based
15:41:01 <m-relay> <s​yntheticbird:monero.social> real answer: nuh uh
17:15:01 <m-relay> <s​bt:nope.chat> What is it then?
17:18:02 <m-relay> <s​yntheticbird:monero.social> nuh uh
18:51:01 <m-relay> <b​asses:matrix.org> some issues should've been closed and I already mentioned some few days ago
18:51:13 <m-relay> <b​asses:matrix.org> .
19:00:29 <m-relay> <o​frnxmr:monero.social> You said "think". Need confirmations
19:02:28 <m-relay> <b​asses:matrix.org> win7 is no longer getting security updates
19:02:29 <m-relay> <b​asses:matrix.org> and the debian issue already solved according to Erc
19:04:24 <m-relay> <o​frnxmr:monero.social> Debian _testing_ has 18.4xx, debian stable does not. Tails uses stable iiuc
19:05:23 <m-relay> <o​frnxmr:monero.social> The issue resolved is a separate issue - that debian testing removed monero because of some issue. Monero was readded to testing (and seems to be maintained), but tails doesnt ship testing, it ships stable (iiuc)
21:26:28 <m-relay> <o​frnxmr:monero.social> [@tritonn:matrix.org](https://matrix.to/#/@tritonn:matrix.org)  "no"
22:06:40 <m-relay> <b​obolisto:matrix.org> Thanks for the explanation. I don't really understand how it works but I can follow it. So the FCMP is only valid for that specific merkle tree. If I change one output then the FCMP becomes invalid even though my output is still there?
22:14:21 <m-relay> <k​ayabanerve:matrix.org> BoboListo: Every block produces a new Merkle tree and your FCMP is only valid for a specific tree.
22:14:37 <m-relay> <k​ayabanerve:matrix.org> We don't require your FCMP be valid against the most recent tree however, solely any on-chain tree.
22:15:12 <m-relay> <k​ayabanerve:matrix.org> So if a new block is mined, and a new tree is defined, your existing FCMP remains valid so long as the old tree's block isn't reorganized out.
22:16:19 <m-relay> <k​ayabanerve:matrix.org> > If I change one output then the FCMP becomes invalid even though my output is still there?
22:16:21 <m-relay> <k​ayabanerve:matrix.org> If your FCMP remained valid, it'd reveal it _wasn't_ the removed output (making it not private) OR it'd be a broken proof.
22:30:19 <m-relay> <b​obolisto:matrix.org> Ok I get the basics of it now. Thanks
22:50:47 <m-relay> <j​effro256:monero.social> We can do this efficiently since the verifier only needs the *root* of the tree once it has calculated the FCMP tree for that set of outputs, which is 32 bytes. So the blockchain database expands an extra 32 bytes per block to store this root value. Transaction proofs reference the FCMP tree root by pointing to a "reference block"