04:23:24 hi 04:23:27 I need help 04:23:35 someone awake? 04:53:12 How may i be of assistance? 04:56:39 Hi, I need support for onboarding as a Windows developer to the project. 04:58:36 I followed the guide to install the MinGW toolchain as monero-github required. 05:02:19 However vscode finds errors that are incorrect, because it does not look for the dependencies correctly. 05:02:19 Even though I created the compile_commands.json file with the paths. 05:03:17 ofrnxmr can you assist me on this? 05:04:36 I don't run win but checking 05:06:45 When are the errors thrown, and what are they? upload to paste if necessary www.zerobin.net 05:08:32 <0​xfffc:monero.social> Guest20 what you want to do? Monero only supports cross compiling to windows 05:08:38 <0​xfffc:monero.social> Not active development on windows 05:09:37 for example: tests/crypto/crypto.cpp: "crypto::ge_cached temp_cache;" - ERROR: name followed by '::' must be class or namespace name 05:11:28 even though the dependency crypto.cpp is found correctly and go-to to the source file works it does not respect the symbols. 05:14:58 i am still here 05:15:10 (I am guest20) 05:19:42 I'll come back later 05:19:52 <0​xfffc:monero.social> From now on I am going to call you Guest* 05:20:49 <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? 05:20:50 <0​xfffc:monero.social> Compiling monero to run on Windows? 05:30:11 <0​xfffc:monero.social> When you say clangd, I assume you are developing on windows. I expect that would not work. 05:31:17 <0​xfffc:monero.social> For example in crypto:: you mentioned. Looks like a parsing flag issue. It doesn’t recognize it is C++ code 07:04:28 > However vscode finds errors that are incorrect, because it does not look for the dependencies correctly. 07:04:30 I think the Guest is experiencing an IDE problem with VSCode 19:54:04 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. 19:58:54 not a maintainer but no objection 19:59:05 he is active and helpful 20:27:34 Who else currently has those write permissions for the repo? 20:27:52 Except you, luigi1111, I mean 20:29:18 binaryFate is all 20:36:55 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? 20:38:58 yes, that is my motivation. i believe the project can benefit greatly from more frequent merges 20:39:08 i want make sure approved prs get merged promptly, so that long and conflict-prone backlogs don't materialize 20:41:07 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. 20:42:05 Have my upvote :) 20:42:22 thanks :) 20:44:54 <3​21bob321:monero.social> Cons to this ? 20:45:14 <3​21bob321:monero.social> Being devils advocate here 20:46:01 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. 20:46:33 for reference, bitcoin core seems to manage just fine with 5 active maintainers 20:46:55 And not that much more code, I guess? 20:47:16 <3​21bob321:monero.social> Core we can drone strike tho cause there known 20:47:45 <3​21bob321:monero.social> Btc core 20:48:02 luigi can always revoke and revert if my account is compromised or i step out of line 20:48:28 I guess you won't get rights to throw out luigi and binaryfate? 20:48:38 <3​21bob321:monero.social> Be like plowsof with website 20:48:39 branch protection rules will not allow me to 'rewrite history' or anything of the sort 20:48:46 r​brunner7: correct 20:49:12 Sounds good to me. 20:49:35 <3​21bob321:monero.social> If that means new multi Sig +2 20:50:20 We may have quite a deluge of PRs if we get nearer and nearer to the FCMP++ hardfork ready software release 20:50:45 yes, i would expect so too 20:51:41 And for good measure you can throw in some of your not-yet-upstreamed core code improvements accumulated over the years for Feather :) 20:53:04 the big upstreamening 2025 20:58:14 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. 20:58:28 org owner* 20:59:16 I think write should be fine for this, but we can change to maintain if needed for something 21:03:03 here's what I'm looking at for the ruleset right now... https://usercontent.irccloud-cdn.com/file/5CmaeHwu/image.png 21:05:13 Allowed merge methods should just be "merge" IMO. Not "rebase". Makes it more verifiable to compare master history to PRs 21:05:31 We always make the PR author perform the rebase themselves anyways 21:05:53 ^ agree 21:06:36 +1 from a feather fan 21:06:43 Pure merge is guaranteed to always work? With a corresponding rebase of the PR first? 21:07:36 Yes and should be deterministic 21:07:52 Well, if once every full moon it doesn't, I guess luigi could still intervene with more rights? 21:09:29 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 21:11:15 Yeah. Even with "abandoned" PRs, somebody can take over, rebase and make ready for merge that way. 21:11:28 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 21:12:30 I remember this happening for perfect-daemon's connection fix PR 21:13:58 require approval from N of N group of people might be this https://github.com/orgs/community/discussions/23765#discussioncomment-3241652 21:14:44 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 21:15:04 codeowners is a bit invasive. it notifies every codeowner when a pr is opened and requires that all codeowners have write access. 21:15:25 selsta generally approves every commit that is added to the .merges so it would not be any change there 21:17:22 ah thanks, ignoring codeowners option 21:17:55 i will not merge prs that do not have at least 2 approvals from contributors, if i do my access should be revoked 21:18:05 i guess the required approvals settings mitigates against a fat fingering incident 21:26:17 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 21:26:18 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 21:30:31 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 21:33:22 And cryptographically verifiable 21:43:21 i reckon this would slow merges down considerably, rather than speed things up 21:43:28 requiring cryptographically verifiable approvals that is 21:43:39 i'm not opposed to a linter that checks merge commits 23:02:26 Just my two piconeros as not-a-real-programmer: Merging code has seemed to be a bottleneck slowing down development and discouraging new contributors to the codebase. I have been impressed with tobtoht's meticulous work on code- and build-safety (again, as not-a-real-programmer). I give this proposal +1 23:03:48 thanks ruck :) 23:24:31 +1 for tobtoht 23:25:05 :D 23:27:44 .merges 23:27:44 -xmr-pr- 9389