The main issue is the conflict with contribution guide stating that tob cant merge his own prs

contributing (probably) the highers # of commits, this would likely be a roadblock

Currently* the highest* frequency* of commits

Also, tob also reviews prs which would mean that we essentially lose a reviewer (would need 2 approvals aside from himself)

I'm all for tob having merge pwr, but we should probably maintain the divide between who writes/reviews(approves) the code, who creates the merge list, and who merges it. imo the latter should be uninvolved in the former 2

In the past, fluffy used to yolo merge a lot of stuff that was "approved" (even stuff with unaddressed review comments or blatant errors). I think the 3 tier system where "devs write and review code -> selsta triages -> luigi merges" is ideal. mixing the tiers sound like a step in the wrong direction imo

<0​xfffc:monero.social> luigi1111 I fully support giving tobtoht writer permission.

<0​xfffc:monero.social> s/writer/write/

hi

Is there a guide for windows developers to get them on board?

I need to set up the environment.

<j​effro256:monero.social> Good, we need windows developers! I assume you've looked at this: github.com/monero-project/monero?tab=readme-ov-file#on-windows

Guest* ask any question you have.

I see ofrnxmr concern as valid. I personally fully support tobtoht_ to have write access, but that by definition means we are going to lose him on dev/review side.

That is the dilemma

i am certainly not going to stop writing or reviewing code, that would be counter-productive

i'm fine with sticking to the merge queue for anything that isn't trivial or is outside of my area of expertise

i'm okay with a trial period if there is any doubt in my ability to discern what is and isn't a good merge

<r​brunner7:monero.social> I think if we trust them to handle merges properly, we can also trust them to not reviewing some code just to get it merged. And if we insist, more strictly than until now, on *two* reviews before merging, they can't just "march through" with some code anyway.

"Handle merges properly" means sticking to merge queue. His last 2 comments imply that he wants to bypass the queue and directly merge what he feels qualifies. I think this is in good faith, but not a good idea.

i will look to selsta to decide what to merge in areas of the codebase i'm not intimately familiar with

that's precisely the issue. all prs should go through selsta-approved merge list, not only the ones that youre unfamiliar with. And you shouldnt cant merge code that youre involved with the dev or review steps. This leaves you handicapped and doesnt solve the issue if luigi being mia.

Any and all things need to be added to merge queue, they need to be submit / suggested to selsta

Then someone else uninvolved with the selection or development should be merging said list

<r​brunner7:monero.social> Like it's the case so often, clean and simple fundamental positions seem to clash violently with the messy real world. Maybe right and sensible *in theory*, but good luck handling and enforcing it.

i don't see why it would make sense to block a maintainer from _maintaining_ parts of the codebase they are most familiar with

in my area, i know by know which changes are likely to be controversial and require additional input (beyond 2 approvals)

i don't necessarily know who the stakeholders are in parts of the codebase i'm less familiar with, so i can't use the same amount of rigor there and would look to selsta to decide what to merge.