hi

I need help

someone awake?

<o​frnxmr:monero.social> How may i be of assistance?

Hi, I need support for onboarding as a Windows developer to the project.

I followed the guide to install the MinGW toolchain as monero-github required.

However vscode finds errors that are incorrect, because it does not look for the dependencies correctly.

Even though I created the compile_commands.json file with the paths.

ofrnxmr can you assist me on this?

<o​frnxmr:monero.social> I don't run win but checking

<o​frnxmr:monero.social> When are the errors thrown, and what are they? upload to paste if necessary www.zerobin.net

<0​xfffc:monero.social> Guest20 what you want to do? Monero only supports cross compiling to windows

<0​xfffc:monero.social> Not active development on windows

for example: tests/crypto/crypto.cpp: "crypto::ge_cached temp_cache;" - ERROR: name followed by '::' must be class or namespace name

even though the dependency crypto.cpp is found correctly and go-to to the source file works it does not respect the symbols.

i am still here

(I am guest20)

I'll come back later

<0​xfffc:monero.social> From now on I am going to call you Guest*

<0​xfffc:monero.social> Let’s clarify first, and take a step back. What do you want to do? Or what goal you are trying to achieve?

<0​xfffc:monero.social> Compiling monero to run on Windows?

<0​xfffc:monero.social> When you say clangd, I assume you are developing on windows. I expect that would not work.

<0​xfffc:monero.social> For example in crypto:: you mentioned. Looks like a parsing flag issue. It doesn’t recognize it is C++ code

<j​effro256:monero.social> > However vscode finds errors that are incorrect, because it does not look for the dependencies correctly.

<j​effro256:monero.social> I think the Guest is experiencing an IDE problem with VSCode

any opinions on giving tobtoht_ write permissions for monero repo? He expressed interest. I believe separate from any ongoing CCS prop. Will probably set up rules requiring 1-2 approvals and maybe other things if desired.

<s​yntheticbird:monero.social> not a maintainer but no objection

<s​yntheticbird:monero.social> he is active and helpful

<r​brunner7:monero.social> Who else currently has those write permissions for the repo?

<r​brunner7:monero.social> Except you, luigi1111, I mean

binaryFate is all

<r​brunner7:monero.social> Could that mean that over time they could help with merges, so we could arrive at some faster reaction / processing times there, because not everything has to go through a single needle eye with you?

yes, that is my motivation. i believe the project can benefit greatly from more frequent merges

i want make sure approved prs get merged promptly, so that long and conflict-prone backlogs don't materialize

<r​brunner7:monero.social> True. I think we will have more and more cases with inter-dependencies between PRs: "This must go in first, then only I can rebase this, to go in as well afterwards, finally this PR will become ready" and so on.

<r​brunner7:monero.social> Have my upvote :)

thanks :)

<3​21bob321:monero.social> Cons to this ?

<3​21bob321:monero.social> Being devils advocate here

<r​brunner7:monero.social> 3 people with access are more risky than 2 people, quite in general. In this case probably only a little bit more risky, but still.

for reference, bitcoin core seems to manage just fine with 5 active maintainers

<r​brunner7:monero.social> And not that much more code, I guess?

<3​21bob321:monero.social> Core we can drone strike tho cause there known

<3​21bob321:monero.social> Btc core

luigi can always revoke and revert if my account is compromised or i step out of line

<r​brunner7:monero.social> I guess you won't get rights to throw out luigi and binaryfate?

<3​21bob321:monero.social> Be like plowsof with website

branch protection rules will not allow me to 'rewrite history' or anything of the sort

r​brunner7: correct

<r​brunner7:monero.social> Sounds good to me.

<3​21bob321:monero.social> If that means new multi Sig +2

<r​brunner7:monero.social> We may have quite a deluge of PRs if we get nearer and nearer to the FCMP++ hardfork ready software release

yes, i would expect so too

<r​brunner7:monero.social> And for good measure you can throw in some of your not-yet-upstreamed core code improvements accumulated over the years for Feather :)

the big upstreamening 2025

<r​brunner7:monero.social> I guess you won't get rights to throw out luigi and binaryfate? <= correct. There exists read/triage/write/maintain/admin and then owner separately.

org owner*

I think write should be fine for this, but we can change to maintain if needed for something

here's what I'm looking at for the ruleset right now... usercontent.irccloud-cdn.com/file/5CmaeHwu/image.png

<j​effro256:monero.social> Allowed merge methods should just be "merge" IMO. Not "rebase". Makes it more verifiable to compare master history to PRs

<j​effro256:monero.social> We always make the PR author perform the rebase themselves anyways

^ agree

+1 from a feather fan

<r​brunner7:monero.social> Pure merge is guaranteed to always work? With a corresponding rebase of the PR first?

<j​effro256:monero.social> Yes and should be deterministic

<r​brunner7:monero.social> Well, if once every full moon it doesn't, I guess luigi could still intervene with more rights?

<j​effro256:monero.social> I don't like the idea of changing the policy to get one commit to go through. If it becomes a recurring problem, we could definitely discuss it again here

<r​brunner7:monero.social> Yeah. Even with "abandoned" PRs, somebody can take over, rebase and make ready for merge that way.

<j​effro256:monero.social> Is there a way to make a whitelist of accounts whose approval counts towards the approval threshold? Otherwise, I can spin up 2 bot accounts and get approved, and the policy it pointless

<j​effro256:monero.social> I remember this happening for perfect-daemon's connection fix PR

require approval from N of N group of people might be this github.com/orgs/community/discussions/23765#discussioncomment-3241652

5 years ago " it’s not possible to require that more than one member of the team in the codeowners file approves the change." perhaps things are different now

codeowners is a bit invasive. it notifies every codeowner when a pr is opened and requires that all codeowners have write access.

selsta generally approves every commit that is added to the .merges so it would not be any change there

ah thanks, ignoring codeowners option

i will not merge prs that do not have at least 2 approvals from contributors, if i do my access should be revoked

i guess the required approvals settings mitigates against a fat fingering incident

<j​effro256:monero.social> Just spitballing here, this idea is a bit unwieldy, but we could have a separate repository named "pr-approvals", for which any number of white listed contributors have *linear* write access. Then anyone can push a commit which contains a PGP signature signing an approval message for a specific commit. Then a Python script can be run retroactively to audit the approval history of <clipped message>

<j​effro256:monero.social> the master/release branches of Monero Core. It would check that merge commits are empty and solely contain references to the previous HEAD as well as a commit message which has N approvals on it from the pr-approvals history

<j​effro256:monero.social> You can code in any arbitrary ruleset to the script. Github wouldn't be to enforce it at time of push, but it would be immediately apparent if something went wrong

<j​effro256:monero.social> And cryptographically verifiable

i reckon this would slow merges down considerably, rather than speed things up

requiring cryptographically verifiable approvals that is

i'm not opposed to a linter that checks merge commits