02:15:17 <ofrnxmr> The main issue is the conflict with contribution guide stating that tob cant merge his own prs
02:15:55 <ofrnxmr> contributing (probably) the highers # of commits, this would likely be a roadblock 
02:16:27 <ofrnxmr> Currently* the highest* frequency* of commits
02:19:01 <ofrnxmr> Also, tob also reviews prs which would mean that we essentially lose a reviewer (would need 2 approvals aside from himself)
02:23:24 <ofrnxmr> 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
02:32:28 <ofrnxmr> 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
03:11:03 <m-relay> <0​xfffc:monero.social> luigi1111 I fully support giving tobtoht writer permission.
03:15:07 <m-relay> <0​xfffc:monero.social> s/writer/write/
03:45:10 <Guest20> hi
03:51:50 <Guest20> Is there a guide for windows developers to get them on board?
03:52:08 <Guest20> I need to set up the environment.
06:02:43 <m-relay> <j​effro256:monero.social> Good, we need windows developers! I assume you've looked at this: https://github.com/monero-project/monero?tab=readme-ov-file#on-windows
06:16:13 <xFFFC0000> Guest* ask any question you have. 
06:17:41 <xFFFC0000> 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. 
06:18:21 <xFFFC0000> That is the dilemma
08:40:59 <tobtoht_> i am certainly not going to stop writing or reviewing code, that would be counter-productive
08:41:51 <tobtoht_> i'm fine with sticking to the merge queue for anything that isn't trivial or is outside of my area of expertise
08:42:38 <tobtoht_> 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
09:17:55 <m-relay> <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.
11:07:06 <ofrnxmr> "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.
11:11:36 <tobtoht_> i will look to selsta to decide what to merge in areas of the codebase i'm not intimately familiar with
11:14:53 <ofrnxmr> 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. 
11:15:46 <ofrnxmr> Any and all things need to be added to merge queue, they need to be submit / suggested to selsta
11:16:25 <ofrnxmr> Then someone else uninvolved with the selection or development should be merging said list
11:16:56 <m-relay> <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.
11:27:37 <tobtoht_> i don't see why it would make sense to block a maintainer from _maintaining_ parts of the codebase they are most familiar with
11:27:46 <tobtoht_> in my area, i know by know which changes are likely to be controversial and require additional input (beyond 2 approvals)
11:28:33 <tobtoht_> 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.
12:05:09 <m-relay> <m​onero.arbo:matrix.org> I don't have much opinion on the specifics of how to implement/rules but fwiw I basically trust tobtoht_ with my life
12:05:33 <m-relay> <m​onero.arbo:matrix.org> (slight exaggeration)
12:06:59 <m-relay> <m​onero.arbo:matrix.org> If we had someone trustworthy who could *just* do merges without losing a reviewer etc I can see how the separation is useful tho
12:07:49 <ofrnxmr> This isnt abt tob as a person. I trust him too. But as a project, we shouldn't be making such extreme exceptions
12:08:19 <ofrnxmr> "who could *just* do merges" Currently this is luigi
12:09:05 <m-relay> <m​onero.arbo:matrix.org> well, *another* person since there seems to be agreement that there's currently a bottleneck
12:09:28 <m-relay> <3​21bob321:monero.social> What about if Luigi appears more often
12:09:34 <m-relay> <m​onero.arbo:matrix.org> but yes I see your point of course. I'm not familiar with the contribution guidelines will see if I can find them
12:09:36 <ofrnxmr> Thats an assumption that is misplaced
12:12:21 <ofrnxmr> most people fairly assumed that this was about luigi being on the yacht an letting merge queue grow. But the issue that tob wants to solve is that things miss the queue. People making suggestions to the queue, should not be the same people merging them
12:12:42 <tobtoht_> if it's conditional on your approval of the proposal, then i'm ok with doing everything through the merge queue
12:13:10 <ofrnxmr> https://github.com/monero-project/monero/blob/master/docs%2FCONTRIBUTING.md its old but here @lyza 
12:13:22 <m-relay> <m​onero.arbo:matrix.org> yep currently peeping it ty
12:19:37 <tobtoht_> i disagree that maintainers should not merge their own prs. if it's added to the queue, i see no benefit in waiting on luigi for that. merging is taking responsibility, which will promote careful consideration and a degree of conservatism.
12:20:19 <ofrnxmr> 1. Need to submit/suggest/defer to selsta regarding anything that should be in queue. 2. Person making submissions, suggestions to merge list, or authoring and reviewing the code, should not be merging the code 
12:20:56 <m-relay> <m​onero.arbo:matrix.org> so if I'm reading correctly merging ones own commits is a no-no but reviewing your own is fine if one is a "core code developer" which seems... not to be defined in this document but is maybe a reference to the so-called "core team"?
12:21:13 <ofrnxmr> no, not core team
12:21:50 <m-relay> <m​onero.arbo:matrix.org> what is considered a core code developer then
12:22:04 <ofrnxmr> Developers working on monero-project/monero
12:22:07 <m-relay> <3​21bob321:monero.social> FYI the year needs to be updated
12:22:20 <ofrnxmr> Plowsof has a pr for that 😆😆😆😆😆😆  #irony
12:22:32 <m-relay> <m​onero.arbo:matrix.org> I guess my contribution here is that the contribution guide should be respected and the prospect of changing it should be a separate discussion
12:25:35 <m-relay> <m​onero.arbo:matrix.org> on the surface this seems logical tho
12:25:53 <tobtoht_> i'm not interested in the role if i'm unable to maintain effectively
12:43:19 <tobtoht_> i'm highly motivated, and i think i can do a good job at making life easier for other developers by promptly merging prs, and making sure development builds work, devs aren't faced with failing ci, and the build system does not fall into ruin.
12:43:31 <tobtoht_> demonstrated by https://github.com/monero-project/monero/issues/9669, https://github.com/monero-project/monero/issues/9631 and four years of experience maintaining feather
12:46:01 <ofrnxmr> 💢 irc failed to send my msg and its gone
12:52:33 <ofrnxmr> i said.. i think there are 2 things that can be done to increase efficiency without removing the balances (re checks and balances). 2. Someone (devs) helping by submitting items to selsta for consideration in merge queue 2. Regular flushes of queue (like.. weekly) << re the former, there was discussion about dev meetings and a suggestion of mine
12:52:33 <ofrnxmr> was for them to focus on unaddressed issues, prs needing review, items missing from queue (or from release branch), and assignments. For the he latter, it would be as simple as luigi being available on a regular and reliable basis, barring that, we'd have to find someone who is disconnected from the development side to fill in. This a slippery
12:52:33 <ofrnxmr> slope though, because a lot of people fit that definition
12:53:32 <tobtoht_> what value does a person who is disconnected from the development side add?
13:00:09 <tobtoht_> i honestly don't get this line of reasoning. surely, it can't be their ability to assess whether a change is a net-positive? how the disconnect help in any way?
13:00:52 <ofrnxmr> That they only ship the package. It avoids value assessments if the person merging the code isnt involved in the selection or creation of which code to merge. Also, the 3 tier system (currently) in place works and would be efficient if not for unreliable merges. I still think dev meetings are a good idea to avoid stuff like this being missed
13:00:52 <ofrnxmr> https://github.com/monero-project/monero/issues/9631
13:02:22 <ofrnxmr> There are 11 prs there that need reviews, and we should have meetings to make sure people volunteer/self assigned to do so
13:03:32 <tobtoht_> it's the slow merges, not the lack of reviews that is the problem
13:04:11 <tobtoht_> i mean meetings would also be beneficial for speeding up reviews, sure
13:10:17 <tobtoht_> if all prs that are added to the merge queue are merged, what benefit is there to waiting longer?
13:12:02 <tobtoht_> and why is selsta uniquely qualified to make executive decisions on what to merge?
13:16:39 <ofrnxmr> they arent all merged, people test the queue, which occasionally leads to finding issues and problematic prs are removed
13:17:19 <tobtoht_> if the pr wasn't properly tested, then it shouldn't have been to added to the queue
13:17:53 <ofrnxmr> if it has multiple approvals, it was clearly missed by reviewers 
13:18:05 <tobtoht_> and what harm is there in reverting if a bad commit does inadvertently get merged?
13:18:32 <ofrnxmr> We had broken code on master for like 8 months and didnt notice until reports came in after releasing it
13:23:21 <m-relay> <m​onero.arbo:matrix.org> damn would be nice if it was easier for people to test development builds huh (:
13:23:31 <tobtoht_> the master branch receiving insufficient testing seems like a separate issue
13:23:40 <tobtoht_> bugs will always get caught after a release when it's not just testers running builds
13:24:36 <tobtoht_> issues are more likely to get noticed sooner if development builds weren't broken on rolling release distros
13:24:37 <ofrnxmr> my point is that, yes, we revert bad commits all the time. And they get added to the queue all the time, due to bad testing or inadequate reviews 
13:24:39 <tobtoht_> which they currently are
13:25:12 <tobtoht_> and for which prs are ready and reviewed
13:25:17 <tobtoht_> waiting to be merged
13:25:20 <ofrnxmr> rolling release distros like debian?
13:25:28 <tobtoht_> debian is not a rolling release distro
13:26:19 <tobtoht_> ok, sounds like we should further improve the review process then, not kneecap merges
13:27:40 <ofrnxmr> I didnt say we should kneecap merges. I said we should improve the review process, the queue process, and the merge process 
13:28:14 <ofrnxmr> but luigi wants to enjoy his yacht time 🤷‍♂️
13:32:31 <tobtoht_> do you think my proposal is a net negative for the project? do the cons outweigh the potential benefits so much so that we must strictly adhere to an ancient contributor document? and will you give me the benefit of the doubt, if only for some predefined trial period?
13:32:53 <tobtoht_> if you think prs could benefit from some time in the queue, why don't we institute 'merge tuesdays' or whatever?
13:56:40 <m-relay> <r​brunner7:monero.social> ... and already time was wasted discussing to exhaustion details that probably will never ever play a real role in anything that would be enough to either merge 10 PRs, review 1 small PR, or write 30 lines of useful C++ code.
13:57:09 <m-relay> <r​brunner7:monero.social> tobtoht_, ofrnxmr won't stop arguing first :)
14:05:13 <ofrnxmr> "details that probably will never ever play a real role in anything" these details are what is is _today_. Id *argue* that these very much play a real role _today_ (not "never ever")
14:08:59 <ofrnxmr> Re merge tuesdays, im on board. But i'd rather have tob (so someone) help with the merge list than do merges. as much as i personally trust tob, I don't think it its a good idea to make exceptions based on trust
14:09:02 <ofrnxmr> .merges
14:09:02 -xmr-pr- 9389
14:10:01 <ofrnxmr> https://github.com/monero-project/monero/issues/9631 there are a few prs here that seem to he adequately reviewed but arent on the merge list. This isn't a luigi issue, its a communication one
14:12:16 <ofrnxmr> Thats not to say that there isnt a luigi issue.. just that the swath of prs that are unattended isnt a luigi issue (nor a selsta one). Its a communication issue that could likely be solved with short dev meetings where issues and prs are addresses 
14:21:20 <m-relay> <s​yntheticbird:monero.social> I have the last word
14:21:40 <m-relay> <s​yntheticbird:monero.social> hehehehehehe
14:28:28 <ofrnxmr> https://github.com/monero-project/monero/issues/9446 this too needs ack/nacks 
14:28:55 <ofrnxmr> Is a precursor to a lot of other work
14:29:31 <tobtoht_> please do leave a comment if you have an opinion
15:43:28 <luigi1111> ofrnxmr> Also, tob also reviews prs which would mean that we essentially lose a reviewer (would need 2 approvals aside from himself) <= tob is a valid reviewer for PRs not made by himself, even if he merges them, IMO
15:46:01 <luigi1111> tobtoht_> if it's conditional on your approval of the proposal, then i'm ok with doing everything through the merge queue <= I think this is the best current workflow. The bot is accessible to everyone I think and history easily viewable being IRC
15:52:14 <luigi1111> even if I still have to merge at least tob's PRs, that's still much very helpful. It takes actual time to go through a merge queue, not just "oh luigi is online, done".
15:55:30 <ofrnxmr> The major issue being solved here is that tob has important prs that he needs merged in short order. Sure there are other works that it helps with, but the main point is tob's work 
15:57:40 <ofrnxmr> "> i don't see why it would make sense to block a maintainer from _maintaining_ parts of the codebase they are most familiar with" i take this to mean that a major part of the goal is to merge his own prs "i'm not interested in the role if i'm unable to maintain effectively"
16:03:07 <tobtoht_> yes, of particular interest are any prs labeled "build system" and "ci", not just my prs. i care about fixing problems that affect other developers, so i'm usually the one fixing them. maintenance work. the role of a maintainer.
16:03:21 <tobtoht_> jeffro's pr's getting blocked because we target an ancient version of macos? i don't like seeing that and it needs fixing.
16:05:57 <m-relay> <s​yntheticbird:monero.social> Tobtoht_
16:06:02 <m-relay> <s​yntheticbird:monero.social> CEO
16:06:13 <m-relay> <s​yntheticbird:monero.social> i failed my matrix formatting i hate my life
16:06:33 <m-relay> <s​yntheticbird:monero.social> anyway a maintainer is obviously in conflict of interest with itself, since he is a maintainer
16:07:04 <ofrnxmr> https://github.com/monero-project/monero/pull/9523 right but it has 2 reviews and hasn't been added to queue. This is a communication issue, not a Luigi one
16:07:50 <m-relay> <s​yntheticbird:monero.social> alright then what about best of both world, toboht_ have write access and we try to organize dev meetings?
16:08:08 <ofrnxmr> we need someone to chair the meetings
16:08:33 <ofrnxmr> Luigi1111 also, what do you think about "merge tuesdays" ?
16:09:12 <ofrnxmr> Are you available on a scheduled basis to flush the cache 
16:20:38 <tobtoht_> ofrnxmr: fwiw, i would ask selsta to sign-off on 9523 first, because i know he cares about platform support. in general, changing runtime requirements should be substantiated and require more approvals.
17:07:45 <Guest20> hi
17:10:26 <m-relay> <o​frnxmr:monero.social> Hi. Still having trouble with your build env?
17:12:07 <Guest20> yea
17:13:34 <Guest20> I wonder what is the recommended way to create a dev env for monero?
17:16:51 <selsta> if another maintainer is added i would prefer if everything still goes through the merge queue
17:18:00 <tobtoht_> alright
17:18:21 <selsta> i'm available daily so if something needs to be added it should not cause any delays
17:19:14 <selsta> having the merge queue for some things and direct merges for others is just going to cause confusion IMO
17:19:45 <tobtoht_> that's fair
17:33:26 <tobtoht_> if i could merge my own pathes that were added to the queue under the condition that they {provide immediate relief to other devs, or have many dependants, or are trivial} that would be great. i'm ok with asking for approval first. for my other stuff i'm ok with waiting on luigi.
17:35:20 <m-relay> <j​effro256:monero.social> Guest20: download the source code, setup msys2 and mingw, install dependencies, boot up IDE of choice, and start tinkering. Are you running into any specific issues?
17:36:56 <tobtoht_> failing ci drives me up a wall, and if have the power to fix it i want to be able to - again, provided it is added to the merge queue
18:05:47 <Guest20>     CMake Warning at tests/functional_tests/CMakeLists.txt:79 (message):
18:05:47 <Guest20>       functional_tests_rpc and check_missing_rpc_methods skipped, needs the
18:05:48 <Guest20>       'requests', 'psutil', 'monotonic', 'zmq', and 'deepdiff' python modules
18:05:48 <Guest20> I installed Python and I also pip installed all these modules. I even added the path to pip...
18:22:10 <moneromooo> Make sure you installed the modules for the version of python which gets used.
18:22:28 <moneromooo> (python 2 and python3 are not so compatible)
18:39:22 <Guest20> the source code seems to have many errors for my compiler, I am using clang, am I supposed to use gcc?
18:42:56 <moneromooo> Both GCC and CLANG build monero. Very new versions might not though, but that can typically be fixed.
18:43:27 <moneromooo> Make sure to follow directions from the README.
18:47:26 <Guest20> Yea building works, however clangd finds errors that are not really errors. E.g. "bool" not defined lmao
18:48:28 <Guest20> I could include <stdbool.h> of cause... But I think the code should not contain errors in every source code of this kind
18:49:13 <Guest20> then we have this: BYTE_ORDER not defined, it should be defined though
18:50:27 <Guest20> or: variable has incomplete type: "union hash_state"
18:51:31 <Juliu> Hi
18:52:25 <Juliu> Don't tell me it's written in pure C
19:09:46 <Guest20> Juliu - you are right, for some reason the compiler wants to treat all files ending with .c or .h as pure C, it does not want to check if the errors are solved by interpreting it as cpp/hpp
19:09:58 <luigi1111> tobtoht_> if i could merge my own pathes that were added to the queue under the condition that they {provide immediate relief to other devs, or have many dependants, or are trivial} that would be great. i'm ok with asking for approval first. for my other stuff i'm ok with waiting on luigi. <= if it has 2 approvals and selsta adds to merge queue that's fine by me. I would also merge my own PRs if I regularly made any
19:11:40 <Juliu> Guest20, if should not matter what the files are named. I was referring to stdbool.h, which isn't needed in C++ since C++ has bool by default
19:11:51 <Juliu> *IT should not ...
19:13:12 <Guest20> If I rename the extention from .c to .cpp or h. to .hpp the errors disappear
19:13:48 <Guest20> Yea it should not matter, I don't know why it does
19:13:59 <Juliu> Ask your compiler
19:18:28 <ofrnxmr> "if it has 2 approvals and selsta adds to merge queue that's fine by me. I would also merge my own PRs if I regularly made any" thats counter to the contrib guidelines 
19:19:35 <selsta> though the guidelines were written before we had a merge queue where an external person is in the loop before it gets merged
19:20:29 <ofrnxmr> yes but how does it get on the merge queue efficiently, if not by request by the same person who wrote the code 
19:23:32 <Guest20> can I clone the dev environment for monero?
20:02:17 <CTRL_FAILURE> Good {greeting_time},
20:02:18 <CTRL_FAILURE> are the algorithms in src/crypto up to date? Or are low level impl from external superior?
20:03:37 <luigi1111> ok. I think I'm going to invite him with the expectation that PRs go through the merge queue as now and non "duh" (like CI etc) PRs from tob won't be merged by him (the simple ones would still need approval obviously). If the contrib guidelines disagree, well whatever we can change them if needed? They should exist to be reasonable
20:03:59 <luigi1111> as for merge tuesdays, I probably can't make every tuesday, but 1-2x per month should be feasible.
20:04:03 <CTRL_FAILURE> e.g.: external/supercop/crypto_sign/ed25519 is probably a better impl
20:06:02 <ofrnxmr> The contrib guidelines are reasonable. Maintainers should not merge their own patches, except for exceptional circumstances 
20:07:49 <ofrnxmr> Its not shall/will not. Its should not, and has exceptions built in. Sounds very reasonable to me. 1x/mth is not enough imo.
20:12:50 <ofrnxmr> "Maintainers SHOULD NOT merge their own patches except in exceptional cases, such as non-responsiveness from other Maintainers for an extended period (more than 30 days) or unless urgent as defined by the Monero Maintainers Team."
20:14:22 <ofrnxmr> Ci prs are not always the same thing as build system. Ci is, in some bases, closer to documentation. Documentation has no such restriction 
20:15:03 <ofrnxmr> "Maintainers MAY commit changes to non-source documentation directly to the project."
20:58:07 <luigi1111> I think doc changes should still be PRs
20:59:15 <luigi1111> it could be narrowed to "builds failing" or whatever
20:59:32 <luigi1111> (would still need 2 approvals as per the github rules that are now live)
21:02:11 <ofrnxmr> Of course agree that absolutely nothing should be commit w/o a pr, but i dont have the same issue with "own prs" if the content doesnt touch the codesource. (ofc still with approvals)