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

 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

(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

wrong anywhere, I'd really appreciate that. - In a good faith, from Humza.

<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

<s​yntheticbird:monero.social> some of them have simply not been closed

<s​yntheticbird:monero.social> or are not updated to current branch

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.

What do you mean by "some of them have simply not been closed"? It is possible to forcefully close older PRs right?

<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

<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

<s​yntheticbird:monero.social> yeah ofrnxmr is right i forgot some PRs just are stalled in discussion

<s​yntheticbird:monero.social> as for PRs "not closed", there are some PRs that were relevant in the past but not anymore

Makes sense, If that's the case, then why doesn't anyone close them?

<s​yntheticbird:monero.social> because we forget they exist

<s​yntheticbird:monero.social> as you may imagine, it's not fun to go check the 400 PRs individually

<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

<s​yntheticbird:monero.social> s/chat someone/chat

<s​yntheticbird:monero.social> s/he/they

Fair, it's really cumbersome.

<s​yntheticbird:monero.social> indeed

<s​yntheticbird:monero.social> You can always check the 200 PRs and make an issue about cleaning some of them

<s​yntheticbird:monero.social> if you make an issue maintainers will see it and do the job

<o​frnxmr:xmr.mx> having them open isnt a bad thing, unless the prs are universally agreed to be no-good

<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

Frankly speaking, the code base is kinda complex :^)

<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

<s​yntheticbird:monero.social> which part are you currently reviewing

Additionally the code progress is relative small since developers are underpaid (are they? I dunno)

<s​yntheticbird:monero.social> LMAO

<o​frnxmr:xmr.mx> In monero, devs have to pay to contribute /s

I'm not reviewing anything, I just came here after getting overwhelmed by the code :)))

<s​yntheticbird:monero.social> yeah i mean what part of the codebase got you overwhelmed with

All, I started with checking the wallet code and it was already over when I saw that it's 666kB.

<s​yntheticbird:monero.social> lmfao

<s​yntheticbird:monero.social> rule 1: Never look at wallet2.cpp

Ehh, I'm not really experienced developer. I'm just an amateur who barely knows stuff about cryptography n' shit.

<s​yntheticbird:monero.social> thats fine everyone start somewhere

<m​onero.arbo:matrix.org> real answer: it's all volunteer / donation based

<s​yntheticbird:monero.social> real answer: nuh uh

<s​bt:nope.chat> What is it then?

<s​yntheticbird:monero.social> nuh uh

<b​asses:matrix.org> some issues should've been closed and I already mentioned some few days ago

<b​asses:matrix.org> .

<o​frnxmr:monero.social> You said "think". Need confirmations

<b​asses:matrix.org> win7 is no longer getting security updates

<b​asses:matrix.org> and the debian issue already solved according to Erc

<o​frnxmr:monero.social> Debian _testing_ has 18.4xx, debian stable does not. Tails uses stable iiuc

<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)

<o​frnxmr:monero.social> [@tritonn:matrix.org](https://matrix.to/#/@tritonn:matrix.org) "no"

<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?

<k​ayabanerve:matrix.org> BoboListo: Every block produces a new Merkle tree and your FCMP is only valid for a specific tree.

<k​ayabanerve:matrix.org> We don't require your FCMP be valid against the most recent tree however, solely any on-chain tree.

<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.

<k​ayabanerve:matrix.org> > If I change one output then the FCMP becomes invalid even though my output is still there?

<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.

<b​obolisto:matrix.org> Ok I get the basics of it now. Thanks

<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"